C# to C++ 'Gotchas'

Garbage collection!

Remember that everytime you new an object, you must be responsible for calling delete.

There are a lot of differences, but the biggest one I can think of that programmers coming from Java/C# always get wrong, and which they never realize they've got wrong, is C++'s value semantics.

In C#, you're used to using new any time you wish to create an object. And whenever we talk about a class instance, we really mean "a reference to the class instance". Foo x = y doesn't copy the object y, it simply creates another reference to whatever object y references.

In C++, there's a clear distinction between local objects, allocated without new (Foo f or Foo f(x, y), and dynamically allocated ones (Foo* f = new Foo() or Foo* f = new Foo(x, y)). And in C# terms, everything is a value type. Foo x = y actually creates a copy of the Foo object itself.

If you want reference semantics, you can use pointers or references: Foo& x = y creates a reference to the object y. Foo* x = &y creates a pointer to the address at which y is located. And copying a pointer does just that: it creates another pointer, which points to whatever the original pointer pointed to. So this is similar to C#'s reference semantics.

Local objects have automatic storage duration -- that is, a local object is automatically destroyed when it goes out of scope. If it is a class member, then it is destroyed when the owning object is destroyed. If it is a local variable inside a function, it is destroyed when execution leaves the scope in which it was declared.

Dynamically allocated objects are not destroyed until you call delete.

So far, you're probably with me. Newcomers to C++ are taught this pretty soon. The tricky part is in what this means, how it affects your programming style:

In C++, the default should be to create local objects. Don't allocate with new unless you absolutely have to.

If you do need dynamically allocated data, make it the responsibility of a class. A (very) simplified example:

class IntArrayWrapper { explicit IntArrayWrapper(int size) : arr(new int[size]) {} // allocate memory in the constructor, and set arr to point to it ~IntArrayWrapper() {delete[] arr; } // deallocate memory in the destructor int* arr; // hold the pointer to the dynamically allocated array }; 

this class can now be created as a local variable, and it will internally do the necessary dynamic allocations. And when it goes out of scope, it'll automatically delete the allocated array again.

So say we needed an array of x integers, instead of doing this:

void foo(int x){ int* arr = new int[x]; ... use the array ... delete[] arr; // if the middle of the function throws an exception, delete will never be called, so technically, we should add a try/catch as well, and also call delete there. Messy and error-prone. } 

you can do this:

void foo(int x){ IntArrayWrapper arr(x); ... use the array ... // no delete necessary } 

Of course, this use of local variables instead of pointers or references means that objects are copied around quite a bit:

Bar Foo(){ Bar bar; ... do something with bar ... return bar; } 

in the above, what we return is a copy of the bar object. We could return a pointer or a reference, but as the instance created inside the function goes out of scope and is destroyed the moment the function returns, we couldn't point to that. We could use new to allocate an instance that outlives the function, and return a function to that -- and then we get all the memory management headaches of figuring out whose responsibility it is to delete the object, and when that should happen. That's not a good idea.

Instead, the Bar class should simply be designed so that copying it does what we need. Perhaps it should internally call new to allocate an object that can live as long as we need it to. We could then make copying or assignment "steal" that pointer. Or we could implement some kind of reference-counting scheme where copying the object simply increments a reference counter and copies the pointer -- which should then be deleted not when the individual object is destroyed, but when the last object is destroyed and the reference counter reaches 0.

But often, we can just perform a deep copy, and clone the object in its entirety. If the object includes dynamically allocated memory, we allocate more memory for the copy. It may sound expensive, but the C++ compiler is good at eliminating unnecessary copies (and is in fact in most cases allowed to eliminate copy operations even if they have side effects).

If you want to avoid copying even more, and you're prepared to put up with a little more clunky usage, you can enable "move semantics" in your classes as well as (or instead of) "copy semantics". It's worth getting into this habit because (a) some objects can't easily be copied, but they can be moved (e.g. a Socket class), (b) it's a pattern established in the standard library and (c) it's getting language support in the next version.

With move semantics, you can use objects as a kind of "transferable" container. It's the contents that move. In the current approach, it's done by calling swap, which swaps the contents of two objects of the same type. When an object goes out of scope, it is destructed, but if you swap its contents into a reference parameter first, the contents escape being destroyed when the scope ends. Therefore, you don't necessarily need to go all the way and use reference counted smart pointers just to allow complex objects to be returned from functions. The clunkiness comes from the fact that you can't really return them - you have to swap them into a reference parameter (somewhat similar to a ref parameter in C#). But the language support in the next version of C++ will address that.

So the biggest C# to C++ gotcha I can think of: don't make pointers the default. Use value semantics, and instead tailor your classes to behave the way you want when they're copied, created and destroyed.

A few months ago, I attempted to write a series of blog posts for people in your situation:
Part 1
Part 2
Part 3

I'm not 100% happy with how they turned out, but you may still find them useful.

And when you feel that you're never going to get a grip on pointers, this post may help.

No run-time checks

One C++ pitfall is the behaviour when you try to do something that might be invalid, but which can only be checked at runtime - for example, dereferencing a pointer that could be null, or accessing an array with an index that might be out of range.

The C# philosophy emphasises correctness; all behaviour should be well-defined and, in cases like this, it performs a run-time check of the preconditions and throws well-defined exceptions if they fail.

The C++ philosophy emphasises efficiency, and the idea that you shouldn't pay for anything you might not need. In cases like this, nothing will be checked for you, so you must either check the preconditions yourself or design your logic so that they must be true. Otherwise, the code will have undefined behaviour, which means it might (more or less) do what you want, it might crash, or it might corrupt completely unrelated data and cause errors that are horrendously difficult to track down.

Just to throw in some others that haven't been mentioned yet by other answers:

const: C# has a limited idea of const. In C++ 'const-correctness' is important. Methods that don't modify their reference parameters should take const-references, eg.

void func(const MyClass& x) { // x cannot be modified, and you can't call non-const methods on x } 

Member functions that don't modify the object should be marked const, ie.

int MyClass::GetSomething() const // <-- here { // Doesn't modify the instance of the class return some_member; } 

This might seem unnecessary, but is actually very useful (see the next point on temporaries), and sometimes required, since libraries like the STL are fully const-correct, and you can't cast const things to non-const things (don't use const_cast! Ever!). It's also useful for callers to know something won't be changed. It is best to think about it in this way: if you omit const, you are saying the object will be modified.

Temporary objects: As another answer mentioned, C++ is much more about value-semantics. Temporary objects can be created and destroyed in expressions, for example:

std::string str = std::string("hello") + " world" + "!"; 

Here, the first + creates a temporary string with "hello world". The second + combines the temporary with "!", giving a temporary containing "hello world!", which is then copied to str. After the statement is complete, the temporaries are immediately destroyed. To further complicate things, C++0x adds rvalue references to solve this, but that's way out of the scope of this answer!

You can also bind temporary objects to const references (another useful part of const). Consider the previous function again:

void func(const MyClass& x) 

This can be called explicitly with a temporary MyClass:

func(MyClass()); // create temporary MyClass - NOT the same as 'new MyClass()'! 

A MyClass instance is created, on the stack, func2 accesses it, and then the temporary MyClass is destroyed automatically after func returns. This is convenient and also usually very fast, since the heap is not involved. Note 'new' returns a pointer - not a reference - and requires a corresponding 'delete'. You can also directly assign temporaries to const references:

const int& blah = 5; // 5 is a temporary const MyClass& myClass = MyClass(); // creating temporary MyClass instance // The temporary MyClass is destroyed when the const reference goes out of scope 

Const references and temporaries are frequent in good C++ style, and the way these work is very different to C#.

RAII, exception safety, and deterministic destructors. This is actually a useful feature of C++, possibly even an advantage over C#, and it's worth reading up on since it's also good C++ style. I won't cover it here.

Finally, I'll just throw in this is a pointer, not a reference :)

The traditional stumbling blocks for people coming to C++ from C# or Java are memory management and polymorphic behavior:

• While objects always live on the heap and are garbage collected in C#/Java, you can have objects in static storage, stack or the heap ('free store' in standard speak) in C++. You have to cleanup the stuff you allocate from the heap (new/delete). An invaluable technique for dealing with that is RAII.
• Inheritance/polymorphism work only through pointer or reference in C++.

There are many others, but these will probably get you first.

Virtual destructors.

Header files! You'll find yourself asking, "so why do I need to write method declarations twice every time?"

Pointers and Memory Allocation

...I'm a C# guy too and I'm still trying to wrap my head around proper memory practices in C/C++.

Here is a brief overview of Managed C++ here. An article about writing an Unmanaged wrapper using the Managed C++ here. There is another article here about mixing Unmanaged with Managed C++ code here.

Using Managed C++ would IMHO make it easier to use as a bridge to the C# world and vice versa.

Hope this helps, Best regards, Tom.

The biggest difference is C#'s reference semantics (for most types) vs. C++'s value semantics. This means that objects are copied far more often than they are in C#, so it's important to ensure that objects are copied correctly. This means implementing a copy constructor and operator= for any class that has a destructor.

Raw memory twiddling. Unions, memsets, and other direct memory writes. Anytime someone writes to memory as a sequence of bytes (as opposed to as objects), you lose much of the ability to reason about the code.

Linking

Linking with external libraries is not as forgiving as it is in .Net, $DEITY help you if you mix something compiled with different flavors of the same msvcrt (debug, multithread, unicode...)

Strings

And you'll have to deal with Unicode vs Ansi strings, these are not exactly the same.

Have fun :)