Any tips on migrating from C# to C++?

Started by
12 comments, last by ToohrVyk 15 years, 5 months ago
Hi there, I'm a professional C# developer, by trade, looking to get into the games industry by training in C++. I've previously used C++ for making rather trivial applications and games but that was quite a few years ago now. But I do have plenty of development experience with C# so I'm familiar with polymorphism, inheritance, etc, etc,... i.e the basics of OO programming. A couple of things I'm looking for are: Firstly like a "Top 5 tips for moving to C++ from other languages" as so many guides i've googled either assume your going from C++ to C# or are for the total newcomer to programing.... Something like a list of the most common pit falls/gotcha's or most useful C++ tricks/libraries/API's/etc for the more experienced programmer. Secondly is just clearing up a few things I've stumbled across: * There are so many ways to represent a string of text/characters (std::string, LPCSTR,LPSTR, char[], etc) how do I know when to use which? (In C# I always used string or, very rarely, char[]) * Many C++ example methods/functions I have read return an int; normally 1 or 0, I'm guessing to signify: success=1 OR failure = 0, when no other kind of return value is needed... Where as in C# the same functions/methods, from what i was taught, would return void and throw an exception if any thing went wrong... Is this good C++ practice to always return something (1 or 0 when no other return values are needed) to signify success or failure? *In C#; every programmer I have worked with, my self included, returns values from a method/function to populate some other value/object like so: "This = That(Foo,Bar);" and tends to avoid passing by reference or using the "out" parameter as a way of assigning values ie: "That(Foo, Bar, out This);" But in almost all C++ examples I've read, regarding C++ for games programing, it seems the norm to pass pointers or references into methods like so: "That(Foo,Bar &This);"... Is this just one of those things people do or is there a solid reason for it (like it being faster? or more efficient? or allowing for that 1/0/HRESULT to be the returned value instead?) Thanks in advance.
Advertisement
My single biggest recommendation: Learn to use the C++ standard library.

The standard list of books to read are:

# "Accelerated C++" Andrew Koenig and Barabara Moo
# "The C++ Standard Library" Nicolai Josuttis
# "Effective C++" Scott Meyers
# "More Effective C++" Scott Meyers
# "Effective STL" Scott Meyers
# "Exceptional C++" Herb Sutter
# "More Exceptional C++" Herb Sutter

Read them mostly in the order listed.

If you already know C# well, Accelerated C++ should be a very quick read, just a few hours at most. All the others will be very meaty for a C# programmer, especially if you are trying to discover the nuances.

If you are already a good programmer and also a fast technical reader you could probably read those in a week -- but you won't get everything out of them. To really get to know them in depth would take several weeks and require multiple re-readings.
Quote:Original post by Guns Akimbo* There are so many ways to represent a string of text/characters (std::string, LPCSTR,LPSTR, char[], etc) how do I know when to use which? (In C# I always used string or, very rarely, char[])


Use std::string unless you have a compelling reason not to. Then use char[].
LPCSTR, LPSTR and CString are Windows API specific. Never use them unless you have to.

Quote:Original post by Guns Akimbo* Many C++ example methods/functions I have read return an int; normally 1 or 0, I'm guessing to signify: success=1 OR failure = 0, when no other kind of return value is needed...
Where as in C# the same functions/methods, from what i was taught, would return void and throw an exception if any thing went wrong...
Is this good C++ practice to always return something (1 or 0 when no other return values are needed) to signify success or failure?


Only throw an exception for something unexpected. That goes for C++ and C#. Methods that are expected to fail should indicate that otherwise. Using the return value is a really good idea.

C++ has a built in 'bool' type. Use that instead of an int with 1 or 0.

Quote:Original post by Guns Akimbo*In C#; every programmer I have worked with, my self included, returns values from a method/function to populate some other value/object like so: "This = That(Foo,Bar);"
and tends to avoid passing by reference or using the "out" parameter as a way of assigning values ie: "That(Foo, Bar, out This);"
But in almost all C++ examples I've read, regarding C++ for games programing, it seems the norm to pass pointers or references into methods like so: "That(Foo,Bar &This);"... Is this just one of those things people do or is there a solid reason for it (like it being faster? or more efficient? or allowing for that 1/0/HRESULT to be the returned value instead?)


Normally, the return value will suffice for returning the result of a method/function. It's a different matter, if the object that will hold the result is expensive to create and/or copy.

You might see 'That(const Type& foo)' a lot. Using a const reference is the most efficient way to pass compound types (== not simple) as parameters.

I hope that helps!
So you're going to be changing two major paradigms at the same time. Since game development is much different from application development you may want to build a few games with C# and XNA first to get a feel for game architecture. Plus, you can use things created with C# and XNA for your portfolio and it would be easier to prototype and create the demos. I guess this advice just depends on how comfortable you are with varying quantities of change.

You should become intimately familiar with the standard library and use the constructs in there as much as possible. So, for string use std::string as much as possible. Also look at boost for things the standard library doesn't provide.

In C++ you can do either. It is really a matter of preference. I think the methods used in C# are much cleaner so whenever I use C++ I try to use exceptions for exceptional situations, pass by reference for objects already created, and return values for new data. The old methods of returning an integer and handling all objects by passing tends to be an artifact of not having exceptions to explain why something failed. There are other reasons, but just take a look through the Windows API.

However it always depends on the situation. Just be ready to change what you thought was best as soon as you find a job with a preexisting code base. I'm sure you're familiar with that one :)

Your last question ties in with your second. If you have an aversion to or simply don't have exceptions then the easiest way to find the outcome of a function is to return a value and check what it is. And since you can only return one value, toss the object in as a pass-by-reference argument and you're set.

Couple more important things to learn or pay specific attention to:
  • Where to use pointers or references and what the differences are

  • Manual memory management

  • Template syntax

  • Header/source file management and inclusion gotchas


There's probably a ton more stuff but I haven't used C++ lately in favor of C#. Also I have no idea how much experience you have with C++ so hopefully this isn't too basic. Also, keep the C++ FAQ Lite handy. It is a fairly useful compilation of things you will likely run in to or have questions about.

Have fun.
Quote:Original post by Guns Akimbo
* Many C++ example methods/functions I have read return an int; normally 1 or 0, I'm guessing to signify: success=1 OR failure = 0, when no other kind of return value is needed...
Where as in C# the same functions/methods, from what i was taught, would return void and throw an exception if any thing went wrong...
Is this good C++ practice to always return something (1 or 0 when no other return values are needed) to signify success or failure?


If you're using a DLL, you never want to throw an exception from the DLL without catching it in the DLL. You shouldn't throw an exception across DLL boundaries (i.e. throw it from the DLL and try to catch it in the EXE); it's A Bad Thing. This is one reason people sometimes use return values. Since they can't throw an exception from the DLL (or at least they shouldn't), but they can return a value, they use a return value to specify an error. This is just one example of why return values are sometimes used instead of exceptions.

Quote:Original post by Guns Akimbo
*In C#; every programmer I have worked with, my self included, returns values from a method/function to populate some other value/object like so: "This = That(Foo,Bar);"
and tends to avoid passing by reference or using the "out" parameter as a way of assigning values ie: "That(Foo, Bar, out This);"
But in almost all C++ examples I've read, regarding C++ for games programing, it seems the norm to pass pointers or references into methods like so: "That(Foo,Bar &This);"... Is this just one of those things people do or is there a solid reason for it (like it being faster? or more efficient? or allowing for that 1/0/HRESULT to be the returned value instead?)


Yes, things are sometimes passed by reference to allow the function to return a value indicating success or failure. Rattenhirn also makes a good point on this.
[size=2][ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]
One more thing on exception:
They are not widely used in gamedev, especially on consoles.
Exceptions are often poorly supported and also not really useful.
You have to do your own memory management in C++. Do yourself a favor and use RAII as much as you can (i.e. use std::vector<int> instead of an *int pointing to new'ed memory). Use pointers only when absolutely necessary. Read "Effective C++" by Scott Meyers.
Awesome stuff guys!

Thanks frob, I now have a copy of Accelerated C++ and am about 5 chapter deep in it :) .. All good stuff (and a fast read, as you suggested), I will be ordering the next couple of books you suggested by tomorrow evening, hopefully.

binchawpz, I already have C#/XNA partial game demo's that I'm converting to C++ as portfolio pieces.
At a recent careers fair the guys from Rare where the only ones who suggested using XNA stuff as portfolio work... every one else took a very "Non-C++ languages are evil (except for tools development)" stance ... Sega being radicaly "Anti-C#" even for tools.
So i've decided to move my C# games over to C++, keeping level editors and tools in C# and scripting in Lua (as everyone [but Sega, again], seemed to like Lua or Python for scripting).

Thanks to every one else for addressing those specific points so well... though please keep that advice coming :) As it's great to get direct advice from people who know what their talking about. Its so common on forums to get a response like "go google it" but googling just assaults you with a million conflicting opinions from everyone with a few lines of code under their belt and a blog.
Modern C++ Design by Andrei Alexandrescu is another great book. It's more advance and mainly involves using templates, so I'd save it for after you've read a few of the books frob suggested.

Besides that, I don't have much more to add. Definitely be aware of memory management, and learn the STL in and out :-)

There's two books I can recommend:

1) Scott Meyers' Effective C++. Anybody who has learned the use of the language should read this book to understand *how* to use it.
2) C++ FAQs (2nd Edition) by Marshall Cline et al. should also answer plenty of questions.

These should keep you busy for a while. :-)

Alex

This topic is closed to new replies.

Advertisement