From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2008-01-16 06:57:39
Whoops, I accidentally hit 'submit'... Here's the second part:
Anthony Williams wrote:
>>> thread_specific_singleton is overly complex for what should just amount to a
>>> simple use of thread_specific_ptr.
>> It uses 'thread_specific_ptr' and has additional responsibilities.
>> Could you be more specific, please?
> thread_specific_ptr on its own provides for one instance of an object per
> thread. I disagree that a class should impose that there is one and only one
> instance per thread (and no globals) --- this is a decision for the user of a
> class, not for the class itself. As I understand from the docs, the additional
> responsibility is the destruction order management. I agree this is a useful
> facility to provide, and think it is independent of the singleton nature of
> the classes, so should be separated into its own class.
The responsibilities of a Singleton. Citing another post (sorry for the
redundancy -- I think I'll add a brushed-up version of this list to the
1. Making the user implement a class
1.1. encourages a well-defined object interface,
1.2. embraces a design that can easily be changed to use non-globally
scoped objects instead, and
1.3. prevents pollution of the global namespace.
2. Providing on-demand initialization
2.1. makes non-trivial construction work with any ABI's shared libs, and
2.2. automatically resolves dependencies between Singletons.
3. Ensuring a single instance of the Singleton class
3.1. allows to properly model unique facilities (hardware, registries,
etc.) in an object oriented fashion, and
3.2. allows to encapsulate a well-defined access point in the first
>>> I've written code that used singletons (and regretted it later), and used
>>> code that other people have written containing singletons.
>> So you should like this library: The design chosen allows you to easily
>> substitute Singletons with Smart Pointers.
> I disagree. If people know something is a singleton, then they don't bother
> keep the reference around, as they can get it again later. Changing code that
> does that to code that can use a passed in instance requires adding parameters
> and/or storing references. You can't just change uses of a singleton to use a
> smart pointer instead without thought to *how* it's being used.
I won't argue on this one. I can imagine that having to refactor a mess
like this is a most unpleasant experience.
Still it's not the fault of the Singletons but of developer's laziness:
At least the developers in the project you mention had a choice whether
to write flexible code or not. With globals and static functions, they
wouldn't have had a choice but to make a mess.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk