Boost logo

Boost :

From: Dave Handley (dave.handley_at_[hidden])
Date: 2005-01-25 12:50:40

Jason Hise wrote:

> I agree entirely... which is why I plan to make multiton a sibling class
> instead of making the singleton support it with additional policies. It
> will live in the same namespace and possibly be able to utilize some of
> the same policies that the singleton does (for instance any allocator
> that doesn't restrict creation to one instance)


> Almost. The key passed in to GetInst would be templated, and Child
> would be the multiton itself. However, upon further meditation I wonder
> if having Child a separate type would be preferable. I guess the
> question at hand is how important it is to enforce that there can only
> be instances that correspond to a key. With your model, anyone could
> easily instantiate a Child.

What I was essentially thinking about was a class that IS actually a
singleton, then a class which you inherit off to generate the
"multiton" using CRTP in a similar way to the singleton. Essentially
your classes would be something like (with slightly better names than
my last attempt of Child and multiton):

template <class M>
class multiton_factory_impl : public singleton<multiton_factory_impl<M> > {};


class my_multiton : public multiton<my_multiton> {};

template <class M>
class multiton {
    typedef typename multiton_factory_impl<M> multiton_factory
    static M* GetInst( int number ) { return
multiton_factory::GetInst()->GetInst( number ); }
// All the usual private constructors to force creation through here
// along with appropriate friending to support it

This is slightly better than my last suggestions because the GetInst
function is actually in the real multiton, rather than in the
singleton. Anyway, I look forward to seeing your implementation.

Dave Handley

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