I''m writting high performance engine and I don''t know if I should use classes in it? Yeah, I knot it is simpler and safer to use classes, but are classes slower than non-object programming method?

REALLY interesting question...i just learned how to use classes and the philosophy under object oriented programmation and id like to know the answer too:-)

that depends on where you use them - I personally would never make e.g. a vector class - because in C (as a struct)
you just store the point info in the ram - in c++ you would even be loading all the member functions of the class to ram - and
making a class with only variables and then having the functions external would even be stupid because that is not the purpose of classes

but what I would do with classes is a particel system handler


I think as long as you do it the right way you can have classes
nearly as fast as pure c handling

correct me if I''m wrong

That's a pretty frequently asked question ...

Here is my opinion! Classes will be SLOWER than procedural code in some circumstances. Classes cause the CPU to push the stack (look up google if your interested). The extra memory overhead of a class if used a lot in loops (depending on what your requirements are) can decrease the number of cache hits.

I'm currently wading through 2,500,000 stars, and calculating which are visible from a point in space. If I used classes it would probably cripple my code.

HOWEVER - there are certain circumstances where classes are probably a better way of doing things! Do what ever you feel comfortable with.

Also, don't forget that the hardware is getting faster and faster. So this argument will be less relevant as time passes.

Edited by - Shag on January 20, 2002 1:20:57 PM

quote:

---

Original post by ZGL_Sigma
that depends on where you use them - I personally would never make e.g. a vector class - because in C (as a struct)
you just store the point info in the ram - in c++ you would even be loading all the member functions of the class to ram - and
making a class with only variables and then having the functions external would even be stupid because that is not the purpose of classes

---

Since you said "correct me if I''m wrong"...

When you write a vector class, you dont end up "loading the member functions to RAM" (along with the point data). For each class the functions are only included once. If the class has no virtual methods, there is no storage overhead compared with a plain C struct. Use sizeof() and you`ll see that a struct of three floats is the same size as a class of three floats, even if the class has methods.

If you do have virtual functions, then each object has a single pointer to a lookup table that is used to dispatch functions, so again, the code for each function is only included once.

Classes are not slower than the equivalent procedural code. If your code does this:

Point.X = 23;Point.Y = 56;

What that really does, in the assembly, is create two variables: "Point.X" and "Point.Y". There is no object "Point" as far as the assembly code is concerned. So it''s not slower. The assembly code of that would look like this:

mov Point.X, 23
mov Point.Y, 56


As for a dynamically created object, like in this code:

pPoint->X = 23;pPoint->Y = 56;

That''s more complicated. The assembly does this:

mov eax, pPoint
mov dword ptr [eax], 23
mov dword ptr [eax+4], 56

The last two instructions take the same amount of time to execute as the two instructions in the first example, though there''s that added "move eax, Point" needed since it''s a pointer.
But for the equivalent procedural code:

*pX = 23;*pY = 56;

...the assembly code would be this:

mov eax, pX
mov ebx, pY
mov dword ptr [eax], 23
mov dword ptr [ebx], 56

So the non-class version is actually slower in this case. Of course this is an unrealistic example, but you see what I mean. Let''s take a more realistic example: Point is a dynamic array of 32 points, and we want to set the values of one of them:

rPoint[14].X = 23;rPoint[14].Y = 56;

The assembly is:

mov eax, rPoint
mov dword ptr [eax+112], 23
mov dword ptr [eax+116], 56

112 is 14 * sizeof(CPoint), since CPoint is two longs, its size is 8. Anyway, the equivalent regular code, with X and Y being dynamic arrays of longs:

rX[14] = 23;rY[14] = 56;

assembly:

mov eax, rX
mov ebx, rY
mov dword ptr [eax+56], 23
mov dword ptr [ebx+56], 56

56 is 14 * sizeof(long). So again, it''s longer.

Anyway, maybe you''re just talking about member functions. Well, member functions are really just regular functions, with the object passed as a parameter. So this:

void CPoint :: Set ( int x, int y ){ X = x; Y = y;}

is actually executed like this:

void CPoint_Set ( CPoint* this, int x, int y ){ this->X = x; this->Y = y;}

...which is exactly the same thing. Note that virtual functions complicate things a bit, though not more so than the procedural equivalent (an array of functions).

Also, for people who know assembly, I know I neglected pairing but you never know what previous instructions might pair with them so I just ignored that.

~CGameProgrammer( );

Might I suggest that some of the more clueless newbies refrain from posting answers to questions like this? Every time this issue comes up there is an initial rush of posts containing vague notions, rumours and superstition.

Once there was a time when all people believed in God and the church ruled. This time is called the Dark Ages.

@Krunk

okay - thx.

I thought the functions are loaded to memory in each instance of the class.

BUT : would you be using classes vor vertices - I still think
C better fits it

In response to ZGL_Sigma''s question, the last time I had to work with vertices I just used a struct with no methods. The reason for that wasn`t performance - it was just that I didn`t see much need to encapsulate the data. The 3 components of a vertex don`t have to be kept in any consistent state - all combinations of x, y and z values are acceptable. Also, there were no range limits on the individual components.

That''s not to say that that''s a good design or that it has any performance benefits over any other approach though. It was just less work for me at the time

No, the functions aren''t really part of the object. In fact, you can call functions on a NULL object. Like this:

class CObject{ public: void Example ( ) { printf( "See? It works.\n" ); Example2( ); } void Example2 ( ) { if( this ) printf( "This object exists.\n" ); else printf( "This object doesn''t exist.\n" ); }};void main ( ){ CObject* O = NULL; O->Example( );}

CObject::Example() is basically just CObject_Example(CObject*). In this example, it is passed a null pointer, but that''s OK as long as it doesn''t try to access any member variables of the null pointer.

~CGameProgrammer( );