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.

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