From: Jeff Garland (jeff_at_[hidden])
Date: 2007-04-05 16:14:45
Cliff Green wrote:
> Jeff Garland <jeff_at_[hidden]> wrote:
> My only big design regret from my last project was using
> Singletons in an infrastructure library layer used by
> multiple applications. I will never do it again. Promise!
> My design policy now is to never embed Singletons in a
> library - if an application wants to instantiate a library
> object as a Singleton, let the app take responsibility and
> manage it accordingly (of course a good generic Singleton
> library in Boost would help ease some of the not-trivial
> issues with Singletons).
I agree with the design philosophy...it's really pretty rare that the
singleton is absolutely required. Oh, and btw, the standard library has been
burned by this too -- the instantiation weight of std::cout, std::err, etc
make the inclusion of the iostream header a killer for embedded apps (several
K size increase in the executable just by including)...
There has been a boost.singleton proposed and I believe rejected and probably
given up on by now.
> Here's an example from ACE, that caused untold wasted
> hours in problem analysis: ACE Reactors have a Singleton
> interface, allowing simple and easy Reactor instantiation
> and use. Two different application layers (written by
> different teams) were using the ACE Reactor Singleton in
> the same application. Depending on what event handlers
> were registered with the Reactor and which events were
> processed, unexpected results occurred. Unit tests were
> absolutely clean, since the unit tests only tested the
> event handlers from one layer. If the separate layers had
> each instantiated their own Reactor objects, interference
> would not have happened.
> And don't get me started on the initialization, dynamic
> library loading, and multi-threaded issues I've had to
> work through with Singletons ...
Ok -- here's another fun one: destruction order of co-dependent singletons
crashing the process on exit -- that's always a fun one to fix ;-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk