|
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