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)

Excellent...

> 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> > {};

and

class my_multiton : public multiton<my_multiton> {};

template <class M>
class multiton {
    typedef typename multiton_factory_impl<M> multiton_factory
public:
    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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk