Ogre Singletons

Get answers to all your basic programming questions. No Ogre questions, please!
Post Reply
User avatar
Moohasha
Gnoll
Posts: 672
Joined: Fri Dec 07, 2007 7:37 pm

Ogre Singletons

Post by Moohasha » Tue Mar 24, 2009 6:14 pm

I have a question about the Ogre::Singleton class. I don't remember where I saw it (because it's not in the API), but when you derive from the Ogre::Singleton class you have to instanciate the singleton yourself by calling new className(); somewhere in your code before you ever call getSingleton() or getSingletonPtr(). Isn't this bad for singleton classes? Whenever I've implemented my own singleton classes outside of Ogre, the getSingleton() call checks the static instance to see if it is initialized, and if not it instanciates it. So the first call of getSingleton() creates the singleton. Does Ogre not do it this way because it's a template class? It just seems bad to rely on the programmer to instanciate the singleton, and to only instanciate it ONCE, prior to it being used.
0 x
Black holes are where God divided by 0

User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
Contact:

Re: Ogre Singletons

Post by Klaim » Tue Mar 24, 2009 7:03 pm

It's better to let the user programmer explicitly tell when exactly he wants Ogre to be created and initialized. Otherwise, if he moves code around, the suggested getSingleton() calls could initialize at times not wanted by the programmer. That wouldn't be a good idea as Ogre creation/initialization is far from free...
0 x

Speedo
Greenskin
Posts: 106
Joined: Fri Jan 23, 2009 9:17 pm

Re: Ogre Singletons

Post by Speedo » Tue Mar 24, 2009 9:52 pm

It just seems bad to rely on the programmer to instanciate the singleton, and to only instanciate it ONCE, prior to it being used.
OTOH it solves what can be a fairly hefty problem with the singleton pattern - control over when your singleton objects are created and destroyed.

Personally the method Ogre uses is the one I prefer. If you forget to create the instance it shouldn't be hard to figure out, since your code is going to blatantly fail. If you take a look at the OgreSingleton class, it has assertions that will fail if you try to create multiple instances.
0 x

User avatar
Moohasha
Gnoll
Posts: 672
Joined: Fri Dec 07, 2007 7:37 pm

Re: Ogre Singletons

Post by Moohasha » Wed Mar 25, 2009 4:38 pm

Klaim wrote:It's better to let the user programmer explicitly tell when exactly he wants Ogre to be created and initialized. Otherwise, if he moves code around, the suggested getSingleton() calls could initialize at times not wanted by the programmer. That wouldn't be a good idea as Ogre creation/initialization is far from free...
I'm not refering to Ogre's Singletons (Root, MaterialManager, etc...). I'm refering more to your own singletons that inherit from Ogre::Singleton. I guess I prefer it the other way because you can garantee that the singleton will always be created the first time it's called, whereas if you have to call new <ClassName> before you can use it or your app crashes, then you have to worry about the instanciation being called before any access which might be a problem if you move code around.
But maybe that's just my coding style. Not saying one's better than the other, I'd just never seen singletons handled the way Ogre does it, so I wanted other people's opinions.
0 x
Black holes are where God divided by 0

User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
Contact:

Re: Ogre Singletons

Post by Klaim » Wed Mar 25, 2009 4:54 pm

I'm talking about Singleton pattern in general, like you said.

Speedo said it better than me :
OTOH it solves what can be a fairly hefty problem with the singleton pattern - control over when your singleton objects are created and destroyed.

In the case you create the singleton on get, you don't control explicitly when the singleton will be created. That way, you can move code around without worrying when the singleton will be created.
But then, you can't verify that your logic is correct after code has changed. You can't predict if in the future a change in the code will make the singleton creation and then impact performances (maybe, not always).

Sometimes you don't care, but most of the cases, you need to know exactly what you're doing, because your future self will have to know too, and explicit code is easier to read (if not with ugly syntaxes).
You shouldn't limit your choice of Singleton pattern to what suit your needs now but choose the best behavior on a case per case basis.

I often need to know exactly where I create the few singletons I use, making the code assert if the order of execution of the code changed in a bad way, so I would never use the create on get approach in my current projects with my current singletons. But I used this approach some time ago for a case where I simply didn't care.

Choose your weapon depending on the target.
0 x

Speedo
Greenskin
Posts: 106
Joined: Fri Jan 23, 2009 9:17 pm

Re: Ogre Singletons

Post by Speedo » Wed Mar 25, 2009 9:25 pm

I guess I prefer it the other way because you can garantee that the singleton will always be created the first time it's called, whereas if you have to call new <ClassName> before you can use it or your app crashes, then you have to worry about the instanciation being called before any access which might be a problem if you move code around.
IMO, if you have so many singletons that that's seriously a problem, then you're probably abusing the singleton pattern (most likely for global access to objects). I don't really ever have more than maybe 3-5 of my own singleton classes to worry about - one is pretty much always the application object, then stuff like input manager, configuration manager, etc. The types of things where you want one instance and one instance only of that class.
0 x

dsamersoff
Gnoblar
Posts: 1
Joined: Fri Dec 15, 2017 11:35 am

Re: Ogre Singletons

Post by dsamersoff » Fri Dec 15, 2017 11:51 am

I see this bad singleton implementation is still there (ogre 1.9.0) - do you plan to fix it in a future?

PS: I'm getting an error trying to compile OGRE. GNU ld optimize out this variable, but it's better to fix it by re-designing the singleton.
C:/ucs/usr/local/include/OGRE/OgreSingleton.h:89: undefined reference to `Ogre::Singleton<Ogre::TerrainGlobalOptions>::msSingleton'
0 x

paroj
OGRE Team Member
OGRE Team Member
Posts: 573
Joined: Sun Mar 30, 2014 2:51 pm
x 83
Contact:

Re: Ogre Singletons

Post by paroj » Sun Dec 17, 2017 1:35 am

as explained by Klaim we do not consider the implementation bad, thus there is no fixing required.
0 x

Post Reply