OGRE Decision to use Singleton

Anything and everything that's related to OGRE or the wider graphics field that doesn't fit into the other forums.
iblues1976
Gnome
Posts: 379
Joined: Fri Sep 16, 2011 4:54 pm
x 10

Re: OGRE Decision to use Singleton

Post by iblues1976 »

zorocke wrote:
c6burns wrote:Also keep in mind shared pointers are in play
Are they?
https://bitbucket.org/sinbad/ogre/src/6 ... at=default

It seems like msSingleton should be a unique_ptr, unless the user is responsible freeing the instance?
I'm not sure what you are referring too but if I was going to use shared_ptr vs unique_ptr, in the case of singleton, I would use shared_ptr. This does not mean that the user is responsible to free up the resource, since this is the concept of shared_ptr.. however, if you use unique_ptr, as far I know, you have to use std::move to be able to move the pointer to another place, and it would not make sense in the case of singleton...

Maybe I misunderstood what you said.
User avatar
c6burns
Beholder
Posts: 1512
Joined: Fri Feb 22, 2013 4:44 am
Location: Deep behind enemy lines
x 138

Re: OGRE Decision to use Singleton

Post by c6burns »

My statement was confusing. I wasn't saying the singletons themselves are or should be shared. My point is a rebuttal to a common criticism that a singleton's memory often can't be released until the end of program execution and this is bad. In Ogre's case this doesn't matter because the singletons are just used to manage other resources which are allocated and released on their own lifecycle, often married to hardware concerns.
zorocke
Halfling
Posts: 48
Joined: Mon Dec 22, 2008 5:01 pm

Re: OGRE Decision to use Singleton

Post by zorocke »

I was thinking of the msSingleton on line 75 inside the Ogre::Singleton class.

Code: Select all

// private member of the Ogre::Singleton 
static T* msSingleton;
// Then in the constructor
        Singleton( void )
        {
            assert( !msSingleton );
#if defined( _MSC_VER ) && _MSC_VER < 1200   
            int offset = (int)(T*)1 - (int)(Singleton <T>*)(T*)1;
            msSingleton = (T*)((int)this + offset);
#else
        msSingleton = static_cast< T* >( this );
#endif
        }
It seems to me like the msSingleton should be wrapped in a unique_ptr, that way an instance of a class inheriting from Ogre::Singleton is absolutely managed without the user's code have to worry about managing it? The accessor functions to access the singleton instance could still just return a regular pointer or reference. It wouldn't be necessary to pass a shared pointer around since the unique_ptr will hold onto the singleton instance until the end of application since it is static.
In Ogre's case this doesn't matter because the singletons are just used to manage other resources which are allocated and released on their own lifecycle, often married to hardware concerns.
Maybe this is why the Ogre::Singleton does not use an unique_ptr now to hold the single instance like I would of thought it should be done.
Post Reply