Re: [boost] pure virtual singleton

From: Jason Hise (chaos_at_[hidden])
Date: 2005-03-28 19:56:15

Rob Stewart wrote:

>with:
>
>class make_me_a_singleton : public singleton_base
>{
>...
>};
>
>without:
>
>class make_me_a_singleton
>{
>...
>private:
>   make_me_a_singleton() { };
>   ~make_me_a_singleton() { };
>};
>
>To me, the first ("with") version is clearer.  It doesn't force
>defining private ctor/dtors that aren't otherwise needed and its
>intent is more apparent.
>  
>
Thank you, those are my thoughts precisely :)

>The first version is achievable just as easily with
>noninstantiable as with singleton_base.  If singleton_base offers
>nothing more than noninstantiable, then the choice of names is
>debatable.
>  
>
If you check the current version of the library, you will notice that 
'singleton_base' offers a lot more than non-instantiable, specifically 
in the realm of control over the instance lifetime, dependency 
management between multiple singletons, and safety with regard to using 
singletons that have already been destroyed.

>To make the class instantiable by the framework, the supplied
>Creator policy class must have access to the ctor.  You can make
>the ctor private and then make the Creator a friend, but then
>outside code can call creator<T>::create() to create an
>instance.  If creator<T>::create() is private, and singleton<T>
>is a friend, then only singleton<T> can instantiate a T.  That,
>of course, is a lot of machinery just to ensure that T can only
>ever be instantiated as a Singleton.
>  
>
I agree, this might be a bit much machinery, especially because creator 
policies are likely to be written often by client code.  However, there 
is a way to move all of the machinery into the library, so that client 
written creators don't have to re-implement it.  Create and destroy are 
not static functions, as a creator must be allowed to have a saved 
state.  These are just plain old member functions, and require a creator 
instance in order to be called.  Thus, by adding a creator base with a 
pure virtual function, we can make all creators uninstantiable and 
unusable by client code.  This creator base could then additionally 
provide the derived instantiable singleton class needed by most 
creators, making it even easier for client code to write their own creators.

-Jason