I would do as S1CA suggests and learn exactly what the processor is doing in each case your worried about. Sometimes the fast code is not necessarily what the advantage is, although if you do it right, you will always have code just as fast as C.

You have to remeber, like Cybertron said in a very simple way, both C and C++ get compiled into the exact same code. If you know exactly what the machine code looks like for what you are writing, you can avoid the pitfalls of, say, virtual functions. They have an advantage, and a disadvantage. Are you willing to pay for the virtual function table lookup, which is just a few machine instructions, three I think, to get the advantage of propagating to the corrent function?

Correctly architected C++ is just as fast as good C. And it has the advantages of being faster to code and more easier to do more complex architectures. Memory management is the main performance hit in programming. Learn that and the rest is pretty insignificant. Memory management is no harder in C++ than it is for C, Carmack just knows C so well, it's second nature to him. If you know C++ well enough, you can write an engine just as good as any other Carmack game.

One more thing, don't use exceptions to return common error codes like "File not found". Exceptions are just that, exceptional cases, used for terminal errors and worst case scenarios. I know not everyone agrees with this, but exceptions make modular coding a nightmare and are a huge performance hit compared to just returning an integer error code on the stack.

Stephen Manchester
Senior Technical Lead
Virtual Media Vision, Inc.
stephen@virtualmediavision.com
(310) 930-7349

[edited by - smanches on July 25, 2002 2:42:15 PM]

Just to give you an example of how fast processors are, I did a little test the other day. What I did was put a loop that executes 20k times inside my render() function, and inside the loop, I placed about 10 asm instructions. After all that punishment, my example was running at 120fps, which, if you do that math ends up being 24 million instructions/sec. This was all going on with about 5 programs running in the background, and running on an athlon xp 1700+ (which will shortly become obsolete). Not to mention the cost of using DirectX 8.1, with app wizard code, and the fact that the loop itself uses several instructions.

Code executes fast, the only problem is with cache misses, and the dreaded page miss. If you are really that concerned about cpu overhead, I suggest you download "Code Analyser" (free - courtesy of AMD), and use it to find exactly what line of code is causing the largest performance footprint.