Was C++ designed for speed, and is it better to not use high level features when teaming with inexperienced programmers?

Question

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.

Answer 1

Okay:

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.

Answer 2

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.