). I am planning on using a struct and a linked list to keep track of all the data, but if using a class was somehow more efficient, then I want to use that instead.
Classes -- what's the point?
Author
I have always wondered what the point of using Classes was. I can''t see how they are any better than using Structs and functions outside of a class. Are there any benefits of using Classes?
The reason I''m asking is because I want to make a particle effects engine (I''ve made one before, but I''m bored and want to make a better one ). I am planning on using a struct and a linked list to keep track of all the data, but if using a class was somehow more efficient, then I want to use that instead.
). I am planning on using a struct and a linked list to keep track of all the data, but if using a class was somehow more efficient, then I want to use that instead.
At first look it''s just another way to ''tidy up'' your code, but if you want to restrict access to certain variables to only a few functions, you can do this with class. They can turn out to be very useful.
-J
-J
A class is obvious less efficient because theres one more step although theres hardly any difference. Destroy(&Thing); is IMO no better than Thing.Destroy();. So if you look at it that way then classes are no better than structs and external functions. But classes do have inheritence (yes i know the struct keyword can do that but) which can be useful for things like particle engines. Theres so little speed difference and there is the advanatage of inheritence so i recoment classes for your particle engine. Anyway, if you know how to make a particle engine wouldnt you already know the answer to this question?
The one thing that bothers me about classes is how they are often delegated to one-shot tasks. For example, say there''s a class called "CMyDirectX" which will be used to encapsulate DX functionality in a project. If it''s only used once in a single object... I really don''t see the point of writing a class that will only be instantiated once.
I think classes are overrated. I dunno, maybe that''s just me.
I think classes are overrated. I dunno, maybe that''s just me.
Ok, here''s an example of a good use of classes ...
Suppose you are writing a 3d engine, and you want to support multiple graphics APIs. You can create a CRenderer class, and a number of derived classes, such as COpenGLRenderer, CD3DRenderer, and CSoftwareRenderer. You can now change which renderer your engine uses simply by creating an object of a different type. No other code in your app has to change.
Or something like that. It''s a lot easier to do with classes than with structs and function pointers.
Suppose you are writing a 3d engine, and you want to support multiple graphics APIs. You can create a CRenderer class, and a number of derived classes, such as COpenGLRenderer, CD3DRenderer, and CSoftwareRenderer. You can now change which renderer your engine uses simply by creating an object of a different type. No other code in your app has to change.
CRenderer* pRenderer;if(CApp.menuSelection == R_OPENGL) pRenderer = new COpenGLRenderer;else if(CApp.menuSelection == R_DIRECT3D) pRenderer = new CD3DRenderer;else if(CApp.menuSelection == R_SOFTWARE) pRenderer = new CSoftwareRenderer;pRenderer->transform();pRenderer->calculateVisibility();pRenderer->drawScene();pRenderer->flip(); Or something like that. It''s a lot easier to do with classes than with structs and function pointers.
quote:Original post by Omaha
I really don''t see the point of writing a class that will only be instantiated once.
But in several projects. It''s called "code reuse."
[ GDNet Start Here | GDNet FAQ | MS RTFM | STL | Google ]
Thanks to Kylotan for the idea!
quote:Original post by Oluseyi
But in several projects. It''s called "code reuse."
I think he was refering to that as oppossed to functions (maybe not?). What immediately came to mind for me is the "random number" class that I''ve seen before. I think it''s pretty pointless to have a class for random numbers when you could just have a couple functions in a "RandGen" namespace or something.
[Resist Windows XP''s Invasive Production Activation Technology!]
As with all things, OOP is not a panacea. You still have to make intelligent design decisions when utilizing classes/structs and methods/functions. Sometimes I prefer to use file-scope OO, or namespaces. So rather than having a CGraphicsContext class with an Initialize method and so on, I might simply have InitializeGraphics() with static data at filescope.
In other (and much fewer) words, I agree entirely.
[ GDNet Start Here | GDNet FAQ | MS RTFM | STL | Google ]
Thanks to Kylotan for the idea!
In other (and much fewer) words, I agree entirely.
[ GDNet Start Here | GDNet FAQ | MS RTFM | STL | Google ]
Thanks to Kylotan for the idea!
I think it''s much clearer to write a common interface-header, like:
video.h
and then do the implementations in different cpp-modules, like:
video_win.cpp
video_linux.cpp
with global "member variables", rather than making a interface-class and inheriting video-classes for all platforms...
BTW: My 1st post, yay!
video.h
and then do the implementations in different cpp-modules, like:
video_win.cpp
video_linux.cpp
with global "member variables", rather than making a interface-class and inheriting video-classes for all platforms...
BTW: My 1st post, yay!
Let's say you want functions to draw tiled maps and sprites. You could call your functions "DrawMap" and "DrawSprite", although that can get annoying (I've been there). You could overload them: "Draw(MAP *map)" and "Draw(SPRITE *sprite)", but then, when you're reading this...
Draw(MainMap);
Draw(Player);
for(int n = 0; n < NumObjects; n++)
Draw(Objects[n]);
...you still have to look at what's inside the brackets before you know what's being drawn. If you use classes, you'd be looking at this...
MainMap->Draw();
Player->Draw();
for(int n = 0; n < NumObjects; n++)
Objects[n]->Draw();
...and since we are used to reading from left to right, this generally helps. We already know we're looking at the drawing code, so we should put the object on the left, where we will see it before "Draw". Reading "Draw" won't help you.
Also, c++ has operator overloading...
EDIT: I think I'll try [n] instead of <img src="wink.gif" width=15 height=15 align=middle><br><br>Edited by - Beer Hunter on December 31, 2001 6:23:29 PM
Draw(MainMap);
Draw(Player);
for(int n = 0; n < NumObjects; n++)
Draw(Objects[n]);
...you still have to look at what's inside the brackets before you know what's being drawn. If you use classes, you'd be looking at this...
MainMap->Draw();
Player->Draw();
for(int n = 0; n < NumObjects; n++)
Objects[n]->Draw();
...and since we are used to reading from left to right, this generally helps. We already know we're looking at the drawing code, so we should put the object on the left, where we will see it before "Draw". Reading "Draw" won't help you.
Also, c++ has operator overloading...
EDIT: I think I'll try [n] instead of <img src="wink.gif" width=15 height=15 align=middle><br><br>Edited by - Beer Hunter on December 31, 2001 6:23:29 PM
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
