Click here to Skip to main content
13,192,207 members (36,597 online)

Comments by Orjan Westin (Top 39 by date)

Orjan Westin 2-Jul-15 6:42am View
   
You can put your class template function definition in a CPP file if you:
a) declare one or more instances of the class in the same file, and
b) you will only need those specific types.

In this case, any use of those specific types, in any other source file, will be found by the linker, so you won't get any complaints. This is quite useful for traits-based design.
Orjan Westin 21-Jan-15 5:35am View
   
Thank you. :)
Orjan Westin 12-Dec-14 4:49am View
   
No, a short is never bigger than an int and never smaller than a char, and a long is never smaller than an int. That's all the language specifies. On 16-bit architectures (showing my age here) short was often 8 bits.
Orjan Westin 12-Dec-14 4:43am View
   
Looks like you are trying to import a .NET DLL into an unmanaged C++ project. That won't work. Why do you need System.dll?
Orjan Westin 4-Nov-14 4:28am View
   
If you follow the link, you'll see it's a C function in the MSI system API. Do your homework, read up, try to solve the problem using what you have learned, and if you still have problems, post your code and say how it is not working. Nobody will write you a complete solution.
Orjan Westin 31-Oct-14 11:32am View
   
Could possibly mean "pass back to command prompt", which would mean using std::out or printf.
Orjan Westin 22-Sep-14 8:30am View
   
I think there's a missing "cbbbbc" line before "cccccc" in the first output. More importantly, though, why aren't you doing your homework yourself? Have a go at writing code to solve the problem, and if you encounter a specific problem you can ask about that.
Orjan Westin 5-Mar-14 11:07am View
   
Sorry, I have my own deadlines to meet.
Orjan Westin 28-Feb-14 17:14pm View
   
Yes, they can, but you didn't show that the streaming operator was a friend. If it is a friend, you still need to use the name of the actual member variable, as in the second example.
Orjan Westin 31-Oct-13 12:15pm View
   
Yes, like I did in the example, by using a cast to "lie" to the compiler. But you can't use the char pointer to get to the int variable, only one byte of it. And which byte you get depends on the CPU architecture.



Orjan Westin 31-Oct-13 11:58am View
   
You are correct, it is not an error to give the pointer a different address to point to (although you probably need to make a cast to make the compiler accept the assignment of a pointer to a different type).

If the abandoned data was created on the heap (with new or malloc), and you don't have another pointer to it which you can use to release the memory, it will be lost (= a memory leak). But that isn't an error, as such, just unwanted behavior.
Orjan Westin 18-Feb-13 6:01am View
   
//Calculate number of spaces to print out.
int space = ...
while (col++ < spaces)
cout " ";
// Calculate number of stars to print
int stars = ...
while (col++ < (spaces+stars))
cout "*";
cout "\n";

cout "*";
Orjan Westin 15-Feb-13 6:26am View
   
Try http://csharp-station.com/Tutorial/CSharp/Lesson20
Orjan Westin 16-Nov-12 11:56am View
   
In that case, can you please mark the question answered? :-)
Orjan Westin 15-Nov-12 9:24am View
   
Yes, when you have a const input parameter. When it's a mixed in/out or an output parameter, you have to provide a buffer, and in some cases a pointer to a char* that the function creates a buffer for.

In most cases std::string and std::vector<char> can be used for these occasions, but there are times, when calling a number of C functions in sequence, when it's most efficient to use C style code throughout that section.

That's not even considering all the C++ code that predates the standard library, and which is still maintained.

So while I agree that new code usually have no use for the C lib functions, most C++ programmers would benefit from learning them.
Orjan Westin 15-Nov-12 8:23am View
   
Except when calling 3rd-party library and OS functions with C interfaces. Without an ABI for std::string and the rest of the standard library, C-style char* strings will be in common use in C++.
Orjan Westin 15-Nov-12 8:14am View
   
Using strncpy as a safe strcpy is very likely to lead to other buffer problems, since a null terminator is not given. If you were to do a strlen on the destination string later on, there's no telling what it might be, but you could easily take it at face value and assume that's the length of it. If you take this as a maximum length of that buffer and copy another string to it, you have your buffer overflow.
Orjan Westin 15-Nov-12 8:13am View
   
Deleted
Using strncpy as a safe strcpy is very likely to lead to other buffer problems, since a null terminator is not given. If you were to do a strlen on the destination string later on, there's no telling what it might be, but you could easily take it at face value and assume that's the length of it. If you take this as a maximum length of that buffer and copy another string to it, you have your buffer overflow.
Orjan Westin 15-Nov-12 6:08am View
   
No, strncpy isn't equivalent, as it doesn't stop at /0 like strcpy and strcpy_s does.

It's intended to solve a different problem, namely copying to fixed-length data fields.

strcpy_s is a standard C library function as of C11. It replaces the common compiler-vendor extension strcpy_r.
Orjan Westin 15-Nov-12 5:03am View
   
C++03 incorporates almost all of C99, and it's a stated aim of the C++ standard committee (ISO/IEC JTC1/SC22/WG21) to maintain C compatibility.

strcpy_s is a C11 addition, and as such hasn't been incorporated into C++11. In other words, it's C, at the moment, but likely to become C++ in the next revision to the standard.
Orjan Westin 13-Nov-12 14:51pm View
   
If you have a pointer to something else, say int* or something, it will print the address. But there's a special handling of char* to print all the characters from that address and forward until a byte containing zero (0) is encountered. This is to maintain how strings are handled in C.
Orjan Westin 13-Nov-12 8:19am View
   
In your print function, you dereference the char pointer "name", by using the dereferencing operator *. If you want to print the string the char pointer is pointing to, you should use it without modification:

void yup::print()
{
cout << name;
cout << endl;
}
Orjan Westin 12-Nov-12 4:51am View
   
It depends on what field you want to work in. C++ is not the preferred language for iOS - Objective C is. While this shares the C ancestry of C++, it is a quite different language with different principles and idioms. While it is possible to use C and C++ for iOS, Objective C is a better fit. However, once you move into Objective C, you are effectively dedicated to the Apple platform.

So if you would like to work on Apple platforms, and are interested in learning a different language, by all means, go for iOS. It's unlikely to become an obsolete skill in the next five years. However, I suspect a lot of the kind of iOS apps currently written in Objective C will come to be written in HTML5 in the future, with Objective C becoming more of a niche for advanced and speed-critical applications.

Sticking with C++ is, I suspect, a safer long-term choice, as it's not tied to a specific platform.
Orjan Westin 31-Oct-12 8:51am View
   
Standard C++ have slightly different exception concerns than Managed C++/.NET does, in particular when it comes to resource management.
Orjan Westin 31-Oct-12 5:27am View
   
Deleted
As others have said, predicting the future is notoriously hard. However, one can look at existing trends. These indicate, in my opinion, that:

* C++ will remain relevant and useful
* MFC will keep fading in relevance
* iOS will remain a popular OS
* The programming landscape will increase in diversity (more spread of languages and frameworks, more flexibility required)
Orjan Westin 25-Oct-12 14:05pm View
   
No, because both the buffer and reference counter are shared. Like this, for instance:

class BufferManager
{
char* buffer;
int reference_counter;
public:
...
void Increase()
{
++reference_counter;
}
void Decrease()
{
--reference_counter;
if (0 == reference_counter)
{
delete this;
}
}
};

When a string is created, it creates a BufferManager dynamically. Then, if it is assigned to another string, that string copies the pointer to the BufferManager and increases the count.

So s1, s2, and s3 all point to the same BufferManager, with the reference_counter being 3. When s3 is modified, it decreases the count on that BufferManager before creating a new one for itself (or using the pointer from an assigned string).
Orjan Westin 25-Oct-12 12:36pm View
   
Just adding a note to explain that this question was (unfairly, IMO) given the Homework/NoEffort tags, and downvoted, by a respondent who did not read it properly, or did not know about the concept of COW, and took it to be about string copying.

In case anyone wonders why those tags are there.
Orjan Westin 25-Oct-12 10:39am View
   
No, because before you create a new reference and buffer, you let go of the old in an orderly fashion, which includes deleting the old buffer, if nobody else was using it (actually, in that case you probably wouldn't delete the old buffer and create a new, but re-use the old if it was big enough, but that's an optimisation you can worry about later).
Orjan Westin 25-Oct-12 10:24am View
   
When a string is to be modified, you always decrease the reference count of the old. What you do next depends on whether it is an assignment of an existing string (adopt the data pointer of the new, and increase its reference count) or a modification or the old (make your own copy of the old string, and your own reference counter).

Generally, you'd have a few private helper functions to handle the copying, assignment, releasing and reference counting, and call those from all places they're needed. In other words, yes, all three non-const member methods would call the same private function.
Orjan Westin 25-Oct-12 10:04am View
   
In particular, follow the links to Herb Sutter's articles: GotW 43, GotW 44, and GotW 45
Orjan Westin 19-Oct-12 11:46am View
   
The use of volatile isn't restricted to multi-threading, though. It was introduced as a way to allow direct mapping to registers or memory areas tied to other hardware. In this case, it's probably there to prevent the compiler from doing unwanted optimisations, as CPallini suggests. So nothing to do with multi-threading.
Orjan Westin 19-Oct-12 11:46am View
   
Deleted
The use of volatile isn't restricted to multi-threading, though. It was introduced as a way to allow direct mapping to registers or memory areas tied to other hardware.

In this case, it's probably there to prevent the compiler from doing unwanted optimisations, as CPallini suggests. So nothing to do with multi-threading.
Orjan Westin 19-Oct-12 10:44am View
   
If the me class has member data, or another function which is virtual, the example would still work, as fun() is not trying to access any member data.

If fun() was virtual, or tried to access member data, you would have undefined behaviour, likely a application crash caused by memory access violation.
Orjan Westin 19-Oct-12 4:44am View
   
The InterlockedExchange and related functions are platform-specific for Windows, though, so not much use if the target is MacOS, Linux, Solaris, or any of a number of real-time OSs.
Cool Cow Orjan 20-Jan-12 8:29am View
   
While ms is the unit of measurement, the default precision is 5ms (for NT family kernels, on Win 95 family it was 15ms). It is sometimes possible to improve this with calls to time[Begin/End]Period - it will tell you how precise it can be.

There is support for a high precision counter. It's just not guaranteed to be installed.
Cool Cow Orjan 20-Jan-12 8:28am View
   
Deleted
While ms is the unit of measurement, the default precision is 5ms (for NT family kernels, on Win 95 family it was 15ms).

It is sometimes possible to improve this with calls to time[Begin/End]Period, but there is support for a high precision counter. It's just not guaranteed to be installed.
Cool Cow Orjan 9-Jan-12 5:08am View
   
The second example, I take it, only shows the modified func() with the rest being equal. So it's not a case of the linker not being able to resolve x, but two x in the same scope.
Cool Cow Orjan 16-Nov-11 5:30am View
   
Almost - you need to increment with 1 to get past the \0 terminator, otherwise the second call will always return 0, since the first character is \0
Cool Cow Orjan 17-Aug-11 12:14pm View
   
Glad to hear you got it sorted, these problems can be endlessly frustrating. :-)

Advertise | Privacy |
Web01 | 2.8.171017.2 | Last Updated 1 Jan 1900
Copyright © CodeProject, 1999-2017
All Rights Reserved. Terms of Service
Layout: fixed | fluid