Boost logo

Boost :

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

Rob Stewart wrote:

>class make_me_a_singleton : public singleton_base
>class make_me_a_singleton
> 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
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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at