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