Ogre Singletons
-
- Gnoll
- Posts: 672
- Joined: Fri Dec 07, 2007 7:37 pm
- x 8
Ogre Singletons
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.
Black holes are where God divided by 0
-
- Old One
- Posts: 2565
- Joined: Sun Sep 11, 2005 1:04 am
- Location: Paris, France
- x 56
Re: Ogre Singletons
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...
-
- Greenskin
- Posts: 106
- Joined: Fri Jan 23, 2009 9:17 pm
Re: Ogre Singletons
OTOH it solves what can be a fairly hefty problem with the singleton pattern - control over when your singleton objects are created and destroyed.It just seems bad to rely on the programmer to instanciate the singleton, and to only instanciate it ONCE, prior to it being used.
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.
-
- Gnoll
- Posts: 672
- Joined: Fri Dec 07, 2007 7:37 pm
- x 8
Re: Ogre Singletons
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.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...
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.
Black holes are where God divided by 0
-
- Old One
- Posts: 2565
- Joined: Sun Sep 11, 2005 1:04 am
- Location: Paris, France
- x 56
Re: Ogre Singletons
I'm talking about Singleton pattern in general, like you said.
Speedo said it better than me :
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.
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.
-
- Greenskin
- Posts: 106
- Joined: Fri Jan 23, 2009 9:17 pm
Re: Ogre Singletons
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.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.
-
- Gnoblar
- Posts: 1
- Joined: Fri Dec 15, 2017 11:35 am
Re: Ogre Singletons
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'
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'
-
- OGRE Team Member
- Posts: 2133
- Joined: Sun Mar 30, 2014 2:51 pm
- x 1143
Re: Ogre Singletons
as explained by Klaim we do not consider the implementation bad, thus there is no fixing required.