From: dherring_at_[hidden]
Date: 2008-01-18 09:30:31
My vote: Accept the current implementation.
I initially thought boost should reject this singleton implementation
because it bundles too many concepts into one package. Others have
pointed out some clear factorization points.
They looked something like:
template <class T> class singleton;
template <class T> class mutexed_ptr;
template <class T> class mutexed_singleton :
public singleton<mutexed_ptr<T> >;
But a bird in hand is worth two in the bush... While good ideas have been
put forth, I don't see their implementation coming soon; and most of these
changes should have little effect on the API.
Ramblings:
Despite the naysayers, boost needs a singleton framework (or at least some
concise documentation on how to implement them portably). Ignoring a
common idiom won't make it go away.
A few purposes for singletons:
1) only create a single object
As Anthony points out, this is generally bad and shortsighted.
2) establish a central point of communication
This can be a good thing.
3) work around foreign APIs
Singletons can save the day when working with callbacks in foreign APIs.
Until everyone starts using functor objects or the like, singletons may be
the only way to pass "extra parameters" through another library's callback
API.
4) simplify public APIs
Mirroring the previous point, "dependency injection" can horribly
clutter an API. Its fine for a couple things; but carried too far, it can
introduce tigher coupling between and an application and a library since
the application now has an active role in passing the library state
around. This is especially important when adding a new library to "legacy
code" where social factors may prevent dependency injection while
singletons allow more isolated changes.
Of these use cases, only 1 and 2 require special static initialization (3
and 4 may use an explicit init() call). Similarly, none of them require
locking semantics, though locking should be easy to specify/enable.
- Daniel