I've been using C# for a while now, and for the sake of furthering my career and extending my knowledge of programming, I want to get into C++. C# is very useful, and fast to work with, but since my team and I will be making large scale projects I need to consider working at a lower level language for several reasons. Most commercial companies use C/C++ due high performance and portability. Of course, C# isn't necessarily bad compared to C or C++, but I just prefer to have a different tool for each job.

So I read C++ is harder because it is a low level language, machine code, and doesn't have memory management. But the fact that it is machine code also reduces the amount of memory consumed. The language is hard to work with, but in a way difficulty makes it a powerful language. It was made to be fast and efficient, machine code, but this makes it harder to understand and learn "since it is closer the the machine".

I've made up my mind, and I want to learn C++, so what are some tips to keep in mind while learning? It's best to avoid getting into bad habits rather than to try and break them later, safe than sorry.

I plan to use the resources stated here, but I would prefer any personal recommendations, books or online guides, possibly those that can be easily understood by someone who has fair knowledge of C#.

  • 1
    Others might object but in my humblest of opinions it might be advantageous to start with C and work into C++.
    – BeardedO
    Commented Sep 6, 2013 at 15:18
  • What are some advantages? C isn't superior to C++, is it?
    – Dave
    Commented Sep 6, 2013 at 15:21
  • That's a dangerous question to ask... There is an advantage to learning C and progressing to C++ because you already likely have a firm grasp of abstraction, and C is more about working with the metal.
    – BeardedO
    Commented Sep 6, 2013 at 15:23
  • What kind of projects are you talking about?
    – Fede
    Commented Sep 6, 2013 at 15:27
  • @HighCore Game making, indie games to be exact.
    – Dave
    Commented Sep 6, 2013 at 16:18

3 Answers 3


I actually went the opposite way, from C++ to C#. I really cut my teeth on good OO design in a C++ context, so I feel I can talk about this okay.


  • Unlike C#, C++ has been around for a long time. Since the 70s. As such, what constitutes 'good C++' depends on who you ask and when they got involved writing C++ and what books they've read. Bjarne Stroustrup's The C++ Programming Language has been revised four times, and went from a 300 page book in the first edition, to a 1500 page book in the fourth. Simply put, a lot has changed over the life of the language, and so there is a lot of history and opinions on how to solve problems. C++ 11 still does more of the same.
  • Learn about how to use pointers, and what they are useful for. If you can, try using pointers to work with hardware directly.
  • Memory management in C++ is often managed using a good practice called RAII. jalf of StackOverflow fame has an excellent article on this: The Meaning of RAII. Also, learn about using shared_ptr, auto_ptr, and the other pointers from the "smart pointer" family. Using these techniques will prevent you from running into memory management issues.
  • Even with the above techniques, you still might run into some memory management issues, in which case valgrind is super-useful to know how to use (especially massif - massif and I got to be good buddies when we were using weak_ptrs in a funky way in some code).
  • C++ has a number of confusing syntax rules (which the C# designers tried to avoid in their language design), many of which if you do not follow carefully will cause you to have confusing results. For example, you may commonly see const className& as the input type of function parameters - there are very good, extremely detailed reasons for this. Marshall Cline's C++ FAQ is invaluable for this.
  • C++ has a lot of features and flexibility and power, which is a good thing, but it doesn't often make the garden-path choices the best for new users. This means, if you aren't careful, your code will be horrible. It took me a good 18 months to figure this out and realize how crappy my code was and why I was getting bad code reviews. Learning to write an interface in C++ (hint: lookup what an abstract-base-class is) is crucial to making great code. Don't be afraid to replicate good concepts and programming constructs you learned in C# land back into C++ land, when you are able.
  • Do learn about template-based programming. Learn what its strengths and weaknesses are, and how it differs from C# generics.
  • 7
    The first bullet is extremely important. There is a lot of C++ code out there that was written like it was written because it was the best way to do it at the time, not because it is the best way to do it now. It means that "learn by example" has many minefields.
    – user53141
    Commented Sep 6, 2013 at 15:47

This is likely to get closed due to open-ended-ness, but hopefully this tip is important enough and un-controversial enough to help:

Be aware of ownership.

In C# (and other languages with automatic memory management), what object owns a variable can be a bit fuzzy. Does the event own the handler, or does the "catcher" of the event? In C#, it doesn't really matter. In C++, your program will die a horrible, horrible (and often subtle) death if you don't know who owns that handler.

This is the key difference in how you need to design programs, and will manifest itself in subtle ways if you're not very careful with it. Learning to design around who owns what is the most important transition you'll need to make, so focus on it early.


I think that you need to be a little careful with the language that you are using to describe C++ (low level language), and also with some of the technical description (machine code) as it reads as inaccurate.

Then you need to work out why you really want to learn a new language. Many companies are using C/C++ and many are using Java and many are using Perl and Python and Scala and ... (some are even using Fortran). Maybe you have a specific company, sector or project in mind? If it is purely for employment reasons I'd caution against it unless you have a way of getting provable experience (I never managed to use my spare time projects as experience in an interview). Pick something that you are interested in, maybe it won't be OO at all; you'll be better at it in the long term through being genuinely interested. Then code in public and see how it goes, asking questions as you go, if it is C++ it's going to take a little while especially if you want to get into memory management!


Not the answer you're looking for? Browse other questions tagged or ask your own question.