Re: [boost] [Formal review] Singleton library

From: Jason Hise (chaos_at_[hidden])
Date: 2005-05-05 07:54:00

David Sankel wrote:

>    *  What is your evaluation of the design?
>
>Excellent. Certainly the best Singleton library I've seen. The ability
>to change the memory model (dynamic/static) easily is an especially
>nice feature.
>  
>
Thank you :)

>As we've all used singletons before, this is potentially very useful.
>However, I cannot see any wide-spread use for the multiton library.
>While an interesting idea, the mutiton would be better implemented as
>a map<string,object> for runtime or just shared variables at
>compile-time. These options are more flexible from the get-go.
>  
>
I actually tend to agree.  IMO, a singleton should exist to provide 
access to and manage the lifetime of some global resource, but should 
not be a global resource itself.  If the resource being managed is 
instead a member variable, client code can much more easily add a new 
managed instances if the need becomes apparent.  It can do so by either 
by adding another resource instance to the existing singleton and 
providing an accessor function for it, or by deriving a new singleton 
from the existing one and applying CRTP to the base.

// the following code creates two distinct singletons which manage 
separate resources

template < typename Derived >
class Base : basic_singleton < Derived >
{
private:
    Resource r;

public:
    Resource & get_res (  ) { return r; }
};

typedef Base < Base > SingletonBase;

class DerivedA : public Base < DerivedA >
{
};

int main (  )
{
    // these are the two managed resources
    Resource & res1 = SingletonBase::pointer (  )->get_res (  );
    Resource & res2 = DerivedA::pointer (  )->get_res (  );
    return 0;
}

The multiton might prove useful in situations when the programmer makes 
the mistake of not separating the concerns of resource management and 
resource functionality, and wants to quickly introduce another singleton 
instance.  However, it is probably not a good long term solution, as a 
single typo in the key (I'm assuming a string is used for the multiton 
key) could lead to difficult-to-debug runtime errors.  Specifically, a 
new singleton instance would be created which would be completely 
unrelated to the singleton that client code was intending to access.

Of course, if anyone is currently finding the multiton useful I'd like 
to hear from you.

-Jason