
David Sankel wrote:
* What is your evaluation of the design?
Excellent. Certainly the best Singleton library I've seen. The ability to change the memory model (dynamic/static) easily is an especially nice feature.
Thank you :)
As we've all used singletons before, this is potentially very useful. However, I cannot see any wide-spread use for the multiton library. While an interesting idea, the mutiton would be better implemented as a map<string,object> for runtime or just shared variables at compile-time. These options are more flexible from the get-go.
I actually tend to agree. IMO, a singleton should exist to provide access to and manage the lifetime of some global resource, but should not be a global resource itself. If the resource being managed is instead a member variable, client code can much more easily add a new managed instances if the need becomes apparent. It can do so by either by adding another resource instance to the existing singleton and providing an accessor function for it, or by deriving a new singleton from the existing one and applying CRTP to the base. // the following code creates two distinct singletons which manage separate resources template < typename Derived > class Base : basic_singleton < Derived > { private: Resource r; public: Resource & get_res ( ) { return r; } }; typedef Base < Base > SingletonBase; class DerivedA : public Base < DerivedA > { }; int main ( ) { // these are the two managed resources Resource & res1 = SingletonBase::pointer ( )->get_res ( ); Resource & res2 = DerivedA::pointer ( )->get_res ( ); return 0; } The multiton might prove useful in situations when the programmer makes the mistake of not separating the concerns of resource management and resource functionality, and wants to quickly introduce another singleton instance. However, it is probably not a good long term solution, as a single typo in the key (I'm assuming a string is used for the multiton key) could lead to difficult-to-debug runtime errors. Specifically, a new singleton instance would be created which would be completely unrelated to the singleton that client code was intending to access. Of course, if anyone is currently finding the multiton useful I'd like to hear from you. -Jason