From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2008-01-16 05:08:49
"Tobias Schwinger" <tschwinger_at_[hidden]> wrote in message
>> For instance, the design
>> could be made more flexible by allowing thread-safety to be specified as
>> policy (with appropriate default) or by delegating the responsibility to
>> 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.
> 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.
>> 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
>> 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
>> a problem in and of itself - this library will do nothing to discourage
> 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
> 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
>> singletons are not a singleton's only dependency: client code ( e.g.
>> 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
>> 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
>> ensure a resource is only instantiated once without necessarily providing
>> global access to that resource.
> So Singletons should be dynamic arrays in your opinion?
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk