PDA

View Full Version : C vs. C++



Owlet
11-16-2001, 02:30 PM
For most OpenGL-related programming stuff, is pure C going to be any faster than C++? I personally like to have nice object-oriented wrappers for things (for example, setting up DirectInput for the keyboard, or creating a rendering context for OpenGL). Am I going to sacrafice any speed by doing this? Intuition tells me that the bottleneck really lies in the graphics processing, and that object-oriented code compiled with a good optimizer would be just as fast as hacker-style C spaghetti code.

Any ideas?

Thanks,
Owlet`

rts
11-16-2001, 05:19 PM
C++ is just like C, in that if you code poorly, your code will run poorly: if you code well, it will run well.

It's funny how long myths can persist... "C++ is slower than C" has been around nearly as long as "Jesus has risen from the dead".

Owlet
11-16-2001, 08:09 PM
C++ being slower than C is really not a myth. When I said C++, I really meant using it as an object-oriented language, not just C with some cute tricks (e.g. references) thrown in. Some object-oriented features, such as virtual functions, do incur overhead. Obviously badly written code in any language will run slower than well-written code in any other language (except for maybe LISP :-P)

There is always a price to pay for abstraction. I'm asking if that price is negligible or not.

Owlet

T2k
11-17-2001, 01:16 AM
c++ isnt slower than c, thats a myth, the difference in speed is produced by different ways of handling data, produced by the programmers, and if you want really fast code you should use assembler code...

Setting up data like rcs/dcs/directinput dont have to be fast, or do u use em every frame ?!?

Owlet: virtual functions ? a bad example, because they make some code faster than using a seperate flag for checking which of the thousend functions to call for the actual object, and overhead (4byte for the pointer vs 4byte for the type (or less bytes to make your app slower ?) ) ? look at this:
you have 3 objects different in drawing function, which you call every frame)

c++ style code:
struct BASE{
//some data, if something can be shared, else nothing here
virtual void Draw()= 0;
};

struct A : public BASE{
//some data
void Draw();
};

struct B : public BASE{
//some data
void Draw();
};

struct C : public BASE{
//some data
void Draw();
};

A a;
B b;
C c;
BASE *actual= &b;
actual->Draw(); //nothing checked only call the correct function

and in other not object oriented languages, where you dont have virtual functions, how would you do this, use a void pointer, use some bits to check for objecttype ? and then coose the function

harsman
11-17-2001, 07:23 AM
Look, this is asked every couple of months here, and no good ever comes of it. Use whatever you feel like, it doesn't really matter. The language is just a tool, use what you're comfortable with and what suits the purpose. OOP is great for simulation type stuff (like, say games), after all Simula was developed to do just that, and I wouldn't do anything in pure C if I could avoid it. But hey, to each his own. If you like coding in C and feel C++ is to complicated, do all your work in C. It honestly doesn't matter.

ET3D
11-17-2001, 07:48 AM
My thought: if you just wrap things outside the main rendering loop, then you shouldn't have a speed problem. The only potential problem I see is if you wrap things in a way that conflicts with the best hardware use (like having vertex objects that you must convert to some other form each frame).

If you wrap geometry in a C++ way so that you can implement things using hardware specific methods for each type of hardware, then it could make for code that is both fast and readable, IMO.