Global/Singleton or Local?

[XianForce]

Okay, so I made a sort of 'framework' using SDL that simplifies things for me (at least that's what it's aimed to do, seems to complicate things haha).

Anyways, graphically it looks something like this:



And any of the game systems I have, hold a pointer to the ApplicationSystem. But I'm finding other classes (which I'll be making multiple instances of), need access to some of the different components of the ApplicationSystem. If I give them pointers to the ApplicationSystem, I'd think that a singleton would likely be more efficient, though.

So should I make a global/singleton ApplicationSystem? And also, is it a good practice to have a structure like this? This is what logically made sense to me at first, but now I'm thinking I should separate the VideoSystem, AudioSystem, and InputSystem from the StateMachine.

So I'm just looking for a few opinions, before I do anything drastic.

Thanks in advance for any replies!

[eatcomics]

The general consensus is no singletons (except for debug for some) and globals are frowned upon in object oriented programming, but you could very well use globals if you want... I'd say a pointer is a good way to go, it would be more efficient and safer than a singleton I would imagine

[XianForce]

The general consensus is no singletons (except for debug for some) and globals are frowned upon in object oriented programming, but you could very well use globals if you want... I'd say a pointer is a good way to go, it would be more efficient and safer than a singleton I would imagine

Well I was thinking a global. Because if every, let's say, entity had a pointer to it, then I would think globals would be more efficient...

[eatcomics]

you mean like a global pointer to it? that would be more efficient than all of them having it. but only a little, really if you're using pointers right there won't be much worry about efficiency... I'd say having a pointer to it in each class would be safer than a global that you could actually call somewhere you didn't mean to, but that's just what I would think, I still don't exactly know what you're talking about

[XianForce]

you mean like a global pointer to it? that would be more efficient than all of them having it. but only a little, really if you're using pointers right there won't be much worry about efficiency... I'd say having a pointer to it in each class would be safer than a global that you could actually call somewhere you didn't mean to, but that's just what I would think, I still don't exactly know what you're talking about

Yeah I have a problem with explaining things >.>.

[eatcomics]

its okay, I just sometimes can't grasp other peoples concepts, anywho...

[qpHalcy0n]

I'd say for those objects that are persistent (eg: xxxxxMachine, xxxxEngine, xxxxFactory), then there's absolutely no problem whatsoever having a global pointer to the instance. A good and safe bet is to just define an externally linked pointer at the end of the class definition. Then you need a consistent application entry handler which will create all the objects and perform any initialization. You also need a consistent application exit handler which will clean up all the objects and perform any cleanup, so you only have two places to look for persistent objects really.

The whole "no globals" thing is just really psychotic. I never understood that whole deal, myself. The only compelling arguments against such a practice involve code readability, persistence, and namespace pollution. All of which are fixed with a little simple management, like above.

[XianForce]

I'd say for those objects that are persistent (eg: xxxxxMachine, xxxxEngine, xxxxFactory), then there's absolutely no problem whatsoever having a global pointer to the instance. A good and safe bet is to just define an externally linked pointer at the end of the class definition. Then you need a consistent application entry handler which will create all the objects and perform any initialization. You also need a consistent application exit handler which will clean up all the objects and perform any cleanup, so you only have two places to look for persistent objects really.

The whole "no globals" thing is just really psychotic. I never understood that whole deal, myself. The only compelling arguments against such a practice involve code readability, persistence, and namespace pollution. All of which are fixed with a little simple management, like above.

Yeah, that's what I had before, and I changed it for some reason... Can't really remember why though...

But thanks, that cleared things up. I'll make the ApplicationSystem global then =D

[eatcomics]

I currently have 16 globals in my new project...

[XianForce]

I currently have 16 globals in my new project...

Well, the way I see it, I'll only need to have the ApplicationSystem global... Because everything will be running via the State... Once it has access to audio, input, and video, every other system can be passed by reference =D... And it would be silly to make play time systems global I would think... Because other game states wouldn't use them...

but then again, I'm a noob, so maybe not haha