From: Cliff Green (cliffg_at_[hidden])
Date: 2007-04-05 14:45:19
Jeff Garland <jeff_at_[hidden]> wrote:
> Yeah sure, classic Meyer's singleton. Couple problems.
> It's not thread safe
> and you could easily inline this code into multiple
>translation units. In
> both cases you might wind up with multiple copies of
>your singleton in the
> process. It's this sort of thing that makes true
>singletons devilishly hard
> to do...
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).
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 ...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk