Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I have read some optimisation guide for C++, and it seems it requires more knowledge to have a fast C++ code, than using C++ without the high level features of C++ (classes, templates, inheritance, etc.).

C++ is a powerful language, and will be the one used in game programming for a long time, and is still fast because it is a C subset, but as John Carmack said, it has to be used correctly: when dealing with programmers who can't guess alone how to make fast C++ code, isn't it a good idea to force them not to use high level features which can me more delicate to optimise ?

I know compilers do a very good job at optimizing the code they are being given, but they can't change it, or do they compilers that feature some sort of warnings that encourages a good use of OOP, or can compilers automatically optimize OOP code even if it is a slow one ?

EDIT: I'm not bashing C++ high level features bere, I'm just talking about some of the very high level stuff like multiple inheritance and abstract classes. Classes are awesome when just compared to struct's, but multiple inheritance is not that much a universal solution to all software problems.

share|improve this question
-1, I don't see a real question here. Maybe "How good are compilers?" (too vague, depends on the compiler) or "Should I force bad programmers to use fewer C++ features?" (take that crap to programmers SE). –  user744 Dec 11 '10 at 13:46
I would alter the title. 'isn't better to not use' is confusing. –  The Communist Duck Dec 11 '10 at 14:49
"Classes are awesome when just compared to struct's" In C++, the only difference between structs and classes is the default visibility (public for structs, private for classes). In every other aspect, they behave identically. –  Michael Madsen May 11 '11 at 12:44
add comment

2 Answers

up vote 18 down vote accepted


  1. C++ is a C superset, not a C subset
  2. If you're teaming with inexperienced programmers that don't understand inheritance, then it doesn't really matter what language you choose, they're still going to have problems.
  3. Compilers can do an amazing job with optimisation. Chances are, apart from a few edge cases, you'll have a hard job writing faster assembly language versions of your functions. And even if you do, it'll take you far longer than writing it in C/C++. Trust that the compiler writers know what they are doing, and worry more about whether or not your team knows what it is doing.

I feel that you are mistaking use of the extended feature set of C++ (inheritance, classes, templates) with a) writing slow code, and b) writing hard to understand code.

You can write hard to understand and slow code in C as well. You can write it in any language. Your choice of language does not automatically lead to good or bad code. C++ simply gives you more language features that might cause problems (i.e. enough rope to hang yourself with). It is a mistake to think that if you simply avoid using the features that make C++ different from C, that you will not encounter those problems.

All that said, there are complex structures (multiple inheritance, complicated template code, and various other anti-patterns) which you absolutely should avoid using unless everyone on your team understands them. While they are possible, they are certainly not advised, both for performance and maintainability reasons. But you can write some incredibly clean, structured, and above all fast code using C++'s features, even when you are a programmer of only medium skill. The language is not what causes the problem.

With any language, you should be aware of the consequences of using particular language features, both in terms of performance, and in terms of maintainability and readability.

share|improve this answer
I mostly agree with you, except that C++ tends to produce bad data layouts more easily than C, even when not using inheritance, since people first group by public/protected/private rather than field size or cache relation. I'll also often find people passing things by reference when they could by value much faster, because the thing is only 32-64 bits in size. These are all avoidable, but as a result "idiomatic C++" (especially idioms learned outside game development) is often slower than idiomatic C. –  user744 Dec 11 '10 at 13:44
add comment

isn't it a good idea to force them not to use high level features which can me more delicate to optimise ?

Let me preface this entire answer with the fact that this is my personal philosophy on coding practices and how I run my teams, and that there are different people with different priorities.

My answer to this is absolutely not, but that's because speed of code execution isn't as important as shipping the game.

The reason those higher level features exist is so that you can write code a little more abstractly. And by doing that you can theoretically get more done in less time (or fewer lines of code). Usually there is a speed tradeoff. For example, virtual functions and RTTI have a speed hit. Is it worth the speed hit? In my eyes, the answer is yes.

Anyway, for all the computationally heavy stuff (i.e. pathfinding), it's more about the algorithm anyway.

If you have sections of code that are speed critical (not all code is speed critical), then maybe you want to take one of your more advanced guys and optimize that carefully. Each individual particle structure probably shouldn't have a vtable, for example. But part of being a good technical director is realizing where those heavy bottlenecks are and paying special attention to them.

Besides, in my experience, your real performance gains come from things like how your code manages the GPU. Draw calls, occlusion, that kind of thing.

Specifically speaking of your Carmack reference, read the section on "code lineage" from this article (it's at the bottom). The Doom Resurrection code base I worked on went heavy on boost/stl/delgates/etc, the levels themselves used LUA as a scripting language, and there were a bunch of things that were not ideal at all in terms of performance. I'm not going to say the code was perfect at all. Even with my lax feeling about code performance there were things I didn't like. But we shipped the game quickly with a few number of people. And you can read Carmack's own impressions on it there.

share|improve this answer
Remembers me Strousup saying "you can't teach new trick to an old dog" while speaking about Torvalds's C++ name-calling :) Being a control freak surely has its advantages when you code a lot, but for people who want to get it done it's not always the way it can be done. –  jokoon Dec 11 '10 at 17:58
Stroustrup is 20 years older than Linus or Carmack and both have had ample experience working in C++ and dozens of other languages - Who's the "old dog" in this case? –  user744 Dec 12 '10 at 15:25
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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