Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

IronFist

Classes -- what's the point?

This topic is 6043 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement
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

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

  
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.

Share this post


Link to post
Share on other sites
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!]

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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 [ i ]

Edited by - Beer Hunter on December 31, 2001 6:23:29 PM

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!