I started thinking about OOP and came up with a question. Isn''t it kind of stupid to make a class when you are only going to create one instance of it? I think this kind of task is better for namespaces, but everyone I have talked to about this recently says classes are the way to go. Any thoughts? Here is an example (and an excuse to use that code box thing):

    
class GameEngine
{
    // put stuff here

};

GameEngine MyGameEngine;
MyGameEngine.MainMenu();
MyGameEngine.LoadLevel(1);
MyGameEngine.PlayLevel();
// ...

    

--------------------

You are not a real programmer until you end all your sentences with semicolons;

Yanroy@usa.com

Visit the ROAD Programming Website for more programming help.

Yes, using a class for only a single instance is very wasteful, that''s one of the why I am still using C for my code, C++ (OOP) is more useful for the highierlevel code like (in an RTS) unit management, building management and so on. Just use your better judgement where to use objects and where not to use objects. I have been able to keep it to structs and poitners with straight C code and it has worked well.

IMO Using OOP for graphics and sound handling is also wasteful because there will only ever need to be one set of functions that are used. Therefore the best places to use objects would be once you''ve already done all the graphics functions and that you are using them (object) for game management, IMHO especially useful in RPG''s, RTS''s, FPS''s and a lot of other genres where you manage stuff...



Dæmin
(Dominik Grabiec)
sdgrab@eisa.net.au

CyberPunk RPG
http://www.eisa.net.au/~sdgrab/index.html

For games I use C with only a few C++ features (new, delete, sometimes operator overloading), only for windowed applications I use C++ with MFC. I don''t think OOP is necessary, also if you code bigger projects.

Visit our homepage: www.rarebyte.de.st

GA

Haven''t you guys ever heard of static functions? I guess not . Static functions (and member variables) allow you to use the class directly instead of making an instance. For example, you could make your class like this:

    class GameEngine{   protected:    static int StaticVariable;    int regularVariable; //read about this belowpublic:     static void MainMenu ();    static bool LoadLevel (int level);    static void PlayLevel ();};//using class directly hereGameEngine.MainMenu();GameEngine.LoadLevel(1);GameEngine.PlayLevel();// ...         

The only limitation of static member functions/variables is that you can''t access non static members, so in the MainMenu function you couldn''t access the variable regularVariable.

--TheGoop

BTW, in response to ga, OOP is neccasary often times. Especially if your working with many other programmers.

I don''t believe that a class for a single instance of an object is wasteful. Quite the contrary...I think its quite natural. A class is a logical grouping of data and methods that operate on that data.

I agree that a single class instance is not necessarily wasteful. I admit that I''m a big class freak, but classes allow you to logically group data/functions together (as mordell mentioned) and makes code SO much easier to read and understand.

As for it being wasteful speed wise, doesn''t calling a function in a class just pass one extra referrence (of the class calling the function)? The speed hit should be very minimal, and the benifits far outway any small speedhit, imo.

The class gives you a way to group your functions. But generally I separate two issues: If you would design a class that would hold no data, I''d use a namespace instead. If it''s supposed to maintain state and express relations (several instances, or inheritance), I use classes.
Since namespaces (and static functions) don''t give you any runtime overhead compared to nametagged global functions, I''d rather have them grouped in a namespace, since I can control scope better that way.

Classes for stuff thats used once is not that wastefull. Especially if its stuff that initilizes DirectX and such. You can just use that class later in other projects when you don''t feel like copying and pasting the code over or rewriting it.

OneEyeLessThanNone

Tip: never put fish in the kitchen sink when cleaning out the aquarium with bleach and harsh detergents. They might get sick from food particles.

You don't need classes to group functions and data together. That is where different source files come in. You put all implementation into a source file and then provide interface functions in a header file (even better to sorround them in a namespace or use a naming convention like Graphics_DrawBitmap, Sound_PlaySound, Game_Quit, etc.). The header is all that the client of the module sees.

For information hiding in C++, I find this to be a better way. In C++ for someone to use a class it has to see the entire internal structure (private section) of the class in the class definition.

This can be an annyoance say if you have a direct-x class. Everyone who uses the class will have to know about LPDIRECTDRAWSURFACE's, LPDIRECTDRAW, etc. and will have to include the direct draw headers. Imagine if was something much larger than direct draw. Imagine the compile times. You could hide that information by creating an abstract class that provides all the interface functions and then passes them on to the direct draw class but is that worth it?

With source files you hide all that in the source file and the client of the code will never see any of it. This is really only good for things with things that there are only one of.

Only with objects that there can be more than one of do I prefer classes/structs. Unless if one object can have many different implementations like a graphics engine. You can implement a direct-draw class, a GDI class, an open-Gl class, an allegro class and through virtual functions only call on the generic graphics class. That hides the implemention as much as the source file approach does. But it introduces the overhead of virtual functions.

Edited by - Sheltem on June 15, 2000 1:23:53 AM