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
Alright... I believe that my multiton dependency lifetime is functional based on a few simple tests. However, I could easily be wrong, so I would appreciate the efforts of everyone who tries to break my code. My next task will be to try a multiton longevity lifetime policy, and then perhaps I'll try to find a way to make GetInst accept multiple keys. The code at http://boost-sandbox.sourceforge.net/vault/ under Singleton is up to date. -Jason
Jason Hise wrote:
Alright... I believe that my multiton dependency lifetime is functional based on a few simple tests. However, I could easily be wrong, so I would appreciate the efforts of everyone who tries to break my code. My next task will be to try a multiton longevity lifetime policy, and then perhaps I'll try to find a way to make GetInst accept multiple keys. The code at http://boost-sandbox.sourceforge.net/vault/ under Singleton is up to date.
I just realized that I should probably at least provide a small sample program so that people can see how the multiton is intended to be used. In the following example, a unique country can exist for each unique name, a unique state can exist for each unique name, and states depend upon the country "USA". #include <string> #include <Multiton.h> using namespace boost::singleton; class Country : public Multiton < std::string, Country > { protected: Country ( ) { } ~ Country ( ) { } }; // uncomment to enable lazy creation class State : public Multiton < std::string, State/*, MultitonDependencyLifetime < std::string, State, true >*/ > { private: // guarantee that the USA is created immediately // before the creation of the first state Country::LifetimePolicy::Dependency require_usa; protected: State ( ) : require_usa ( "USA" ) { } ~ State ( ) { } }; void f ( ) { // this creates the ohio instance only if lazy creation is false State::LifetimePolicy::Dependency require_oh ( "Ohio" ); { // this creates the ohio instance if it has not been created yet State::Pointer ohio = State::GetInst ( "Ohio" ); // this creates the florida instance State::Pointer florida = State::GetInst ( "Florida" ); } int i = 5; // florida has been destroyed // but dependency on ohio is still in scope, so ohio lives on } // ohio is destroyed, after which point the USA is destroyed // if it is desired for these things to live to the end of the program, // just add static dependencies, ex: // Country::LifetimePolicy::Dependency require_usa ( "USA" ); int main ( ) { f ( ); return 0; }
Currently, my dependency lifetimes, when set to use lazy creation, only create the object when the first pointer is created, instead of creating whenever the first dependency is created. I was thinking that it might make sense to extend this even further and have it only created the first time a member is accessed through the singleton. This would simply require one more intermediate pointer type. In addition, this intermediate pointer could function to lock the operations performed on the singleton/multiton. Are there any drawbacks to this plan, or should I implement it? -Jason
participants (2)
-
Dave Handley -
Jason Hise