Boost logo

Boost :

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 >
    Resource r;

    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.


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