It''s slower... if used badly and in bad designs.

For example going overboard and having a CPixel class, a CVertex class and a CPolygon class all inherited from some CObject class, all with virtual accessor functions is going to get you hideous performance. But that is due to inappropriate use of the language rather than the language being slow.

If on the other hand the lowest level you get is CMesh, CMatrix etc, then it''s *extremely* unlikely it would be slower than plain C unless you''d made some bad coding/design mistake.

In fact in some circumstances you''d actually get faster code due to the compiler knowing more about the constraints on data (const correctness, aliasing etc).


Having said that, exceptions and RTTI are often best avoided since many *implementations* of them tend to add a whole bunch of extra code to make them work. The features themselves aren''t a problem though - it''s just I''ve never seen a good compiler implementation of them. STL should be fine on most platforms, though some of its memory allocation patterns in certain implementations might not suit you, particularly on some fixed memory platforms like games consoles.


[I''m only using the Cxxx naming convention to emphasise that I''m talking classes - personally I tend not to use it]


In our engine we make use of C++ features in most of the higher level code, and a few lower level parts such as:

- Maths functions (being able to do vector1+=vector2 type things is so much nicer than directly calling a C function to do it).

- Management lists/containers (lists of buffers, textures, etc). Templates and a few choice base classes can greatly simplify much code.

- Device, view, display command handling. We had a single D3D adapter encapsulated in it''s own "Adapter", making multiple Adapter classes allowed us to add multimonitor support in less than a day. (Though it was one thing thought of at the design stage)


I suppose it depends how heavy you mean. In some places for example we pass "command" structures where in a more OO world we may say use a Command pattern.

Learn the costs of each OO feature, then decide at each stage of your engine *design* "is this being called at such a high frequency that the 2 cycle overhead for XX virtual function call is going to have a negative impact". Careful design is the key to good OO/C++ and optimal use of it.

--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com

It's not a question of OO being faster or slower. Your implementation will be the deciding factor.

Virtual functions in OO are probably faster than trying to "virtualize" your code written in C or Pascal, i.e. heavy use of switch-case, and can be easier to write and maintain.

Member functions are really no slower than passing in a pointer to a struct, and the code of your member function can be quite clean.

And with C++, you can step out of the OO realm when necessary to write time-critical, optimized code.

C++ often grabs lots of stack memory in certain circumstances involving copy operations. It's best to learn how that can happen and learn the ways to avoid it if such stack use isn't really necessary.

It's sloppy, careless use that can give C++ a bad rap, but it can be blazing fast if you use it smartly.

Value of good ideas: 10 cents per dozen.
Implementation of the good ideas: Priceless.
Proxima Rebellion - A 3D action sim with a hint of strategy

[edited by - BS-er on July 24, 2002 9:56:49 PM]

The finishing touches of DooM III was writen in C++
(I don''t think Carmack will touch it with a ten-foot pole yet, but we may be surprised with Quake 4).

The finishing touches of DooM III were writen in C++
(I don''t think Carmack will touch it with a ten-foot pole yet, but we may be surprised with Quake 4).

Where the Quake III engine has an advantage over a design like ORGE, is in cache coherency. With the OO scene-graph, you can jump all-over the memory space of the CPU each step the rendering. With Quake''s deterministic BSP trees, and flat player & projectile list, everything that the uses the same code is garuanteed to be rendered sequentially (there by minimizing CPU cache misses).
ORGE''s advantage is that it''s vastly more flexible.

Carmack also manages his memory efficently, whereas ORGE manages it''s memory automatically.

Carmack also performs extensive empirical studies to determin the optimal batching order for the rendering (seeing how grx card companies give him prototypes, this is hard to compete with).

Those three things are why the Quake engines have the highest frame-rates (along with high quality).

The finishing touches of DooM III were writen in C++
(I don''t think Carmack will touch it with a ten-foot pole yet, but we may be surprised with Quake 4).

Where the Quake III engine has an advantage over a design like ORGE, is in cache coherency. With the OO scene-graph, you can jump all-over the memory space of the CPU each step the rendering. With Quake''s deterministic BSP trees, and flat player & projectile list, everything that the uses the same code is garuanteed to be rendered sequentially (there by minimizing CPU cache misses).
ORGE''s advantage is that it''s vastly more flexible.