Passing my whole game as a pointer!
Author
Hi,
My game is getting big now. Lots of classes. Pointers passed here and there!
As an experiment, I started passing a pointer to my whole game wrapper class, then letting each class call functions within cGame to get the individual pointers they use ( the ones I was previously passing in the constructor ).
Is there anything wrong with this?
Is it slow?
I am keeping the pointers private and using functions to get em... is that ok?
Si
I'm doing something like that right now... aside from seeming, as you said, very tidy, I thought it would easier to plug it in to some kind of launcher or menu system.
In an objectoriented design your main()-function shouldn't contain more than
so you'll always have a class like cGame that starts the whole thing.
#include "application.hpp"int main(){ Application myApp; try { myApp.exec(); } catch( ... ) { // ... }}so you'll always have a class like cGame that starts the whole thing.
but why would you do it that way. I have a game object, it is game.exe, and if it doesn't work my OS manages to recover. You need to think outside the box, and object doesn't necessarily correspond to an instantiation of a class or struct.
Basically a program comes down to three things: function definitions, type definitions, storage definitions. Each of these three is defined in terms of the others. A function has a type (a tuple consisting of its return value and its parameters, including *this if it is a member function), and is used to transform state, meaning it interacts with storage. Storage is defined by the type of data that it holds and it is transformed by functions. Type definitions give shape to storage and functions.
Basically a program comes down to three things: function definitions, type definitions, storage definitions. Each of these three is defined in terms of the others. A function has a type (a tuple consisting of its return value and its parameters, including *this if it is a member function), and is used to transform state, meaning it interacts with storage. Storage is defined by the type of data that it holds and it is transformed by functions. Type definitions give shape to storage and functions.
Quote:Original post by ext
In an objectoriented design your main()-function shouldn't contain more than
That's not object oriented -- it's silly.
Object oriented, despite what Java, C#, etc would have you believe, does not mean that functions outside of objects is bad. An "application" or "game" class is silly; I'm tempted to argue it borders on idiocy. It's not something that should be an object. You'll probably never have more than one. (NO, don't make it a singleton. That's even more stupid.) What do you gain by making it an object? Nothing. In a well designed system, none of the other classes should ever even know about this application class.
I know why this "Application class" BS popped up too. It's common when you're working inside generic application frameworks -- MFC, Direct3D, etc. In these frameworks, the application class has a distinct purpose, which is to inherit behaviors from a parent class. Initialization and termination behaviors, basic app management, that sort of thing. Now, if your engine is some kind of generic framework that does that, fine. Then having an application class makes sense. But what the hell is the point of this?
#include "stuff.h"class MyApp{public: bool Startup( ... ) { ... } bool Shutdown( ... ) { ... } void Run() { ... }};int main(){ MyApp App; try { App.Startup(); App.Run(); App.Shutdown(); } catch( ... ) { ... }}It's confusing and it's a waste of your time. Make all of the functions and application class members into program globals declared at the top of main. And no, you're not breaking the rules of object oriented programming. What you're doing is being simple and straightforward.
Think back to why classes exist, guys. This sort of thing is abuse, not good practice.
Yep, I always thought that the idea of Main() being a public static method in C# was lame. In addition, I don't think that Math methods should be in a class; a namespace would do just fine.
[Overall, C# is beautiful]
[Overall, C# is beautiful]
Quote:Original post by PromitQuote:Original post by ext
In an objectoriented design your main()-function shouldn't contain more than
That's not object oriented -- it's silly.
Hear, hear!
I see too many people hamstrung by OO. It is merely a tool to use to simplify your life. If it isn't doing so, then drop it. Procedural programming can't be all wrong, right? There is no "object-oriented" design rule that specifies, "thou shalt have thine Application class referenced from main()."
As for the OP, you're adding all sorts of unnecessary coupling to your system. Now your graphic system knows about your sound system, input system, etc - basically everything in your game class. You may say, "so what?" but when you go to recompile, you're going to pay for this sort of incestuous subsystem knowledge. Each subsystem should exist in complete isolation of other subsystems as much as reasonably possible.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
