"Tobias Schwinger" <tschwinger@isonews2.com> wrote in message news:fmkefr$cf3$1@ger.gmane.org...
For instance, the design could be made more flexible by allowing thread-safety to be specified as a policy (with appropriate default) or by delegating the responsibility to the wrapped type.
OK, FWIW policies complicate things. And what's their benefit here?
I disagree. In general policies promote modularization. In this concrete case policy based solution would allow more flexibility in how "thread-safe" I want to be.
If BOOST_HAS_THREADS is defined, it looks as though I have no choice but to use mutexed instantiation and/or access. If I'm not interested in synchronised access, then the lease interface is useless.
Wrong:
The lease interface is useful to improves performance. The test whether the Singleton has been initialized (which requires synchronization) can be performed only once.
The lease interface only improves preformance in your design. With Meyer's singleton instance() is as efficient. With any other solution that returns T&, I just need to store local referene to the target type. Gennadiy
The solution to the OOI problem does not scale, and I would go as far as saying that it doesn't work in practice. In my experience, it's a constant maintenance nightmare to try and keep the various slot assignments in the correct order (I have to deal with a large number of singletons; yes that is a problem in and of itself - this library will do nothing to discourage it).
You must have misunderstood the docs. OOI is not done with slots. The slots are to prevent unnecessary resurrection during destruction.
The only scheme I've personally had any success with, so far, involves some form of reference counting, i.e. singletons that depend on other singletons do so explicitly (by incrementing the other's refcount on construction; the singletons are destroyed when their refcount goes to zero).
You might have gotten away with it in practice, but introducing this kind of coupling seems really bad design to me.
Another reason why the proposed OOI solution fails in practice is that other singletons are not a singleton's only dependency: client code ( e.g. objects that reference the singleton) are dependencies as well and may affect the order of destruction.
What is the "proposed OOI solution" you are talking about?
You just can't assume the singleton manager will be the last thing to go - there may be other globals.
It's the "we should remove pointers from C++ because one can dereference NULL" kind-of argumentation.
BTW I find the very idea of being able to "force" singleton destruction quite scary, but I haven't looked at the implementation details.
It's necessary, as long as C++ runs on top of ABIs that don't support code to be run automatically when a dynamic library is unloaded and I can assure you that running code in an unloaded, dynamic library is a lot scarier :-).
The following sentence is also cause for concern: " Attempts to access an already destroyed Singleton instance cause the instance to be re-created." Is that true only for DLL usage?
It's true in general.
My biggest problem with this design is that it is unsuitable for library writers: types derived from typical singleton class designs, including boost::singleton and friends under review, invariably give rise to untestable code. To make a singleton's client code testable involves exposing some kind of overridable factory so that the singletonized type can be replaced with a test mockup. So far I have found this to be a hard problem to solve in general.
Interesting point.
Finally, this may constitute a minority opinion but I like to consider global access and single instance as orthogonal concepts. One may want to ensure a resource is only instantiated once without necessarily providing global access to that resource.
So Singletons should be dynamic arrays in your opinion?
Regards, Tobias
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost