Comments by Orjan Westin (Top 41 by date)

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?

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.

Could possibly mean "pass back to command prompt", which would mean using std::out or printf.

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.

Sorry, I have my own deadlines to meet.

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.

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.

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.

//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 "*";

Try http://csharp-station.com/Tutorial/CSharp/Lesson20

In that case, can you please mark the question answered? :-)

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.

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++.

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.

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.

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.

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.

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;
}

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.

Standard C++ have slightly different exception concerns than Managed C++/.NET does, in particular when it comes to resource management.

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).

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.

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).

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.

In particular, follow the links to Herb Sutter's articles: GotW 43, GotW 44, and GotW 45

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.

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.

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.

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.

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.

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

Glad to hear you got it sorted, these problems can be endlessly frustrating. :-)