Re: [boost] [system] Why is this not header-only?

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 ...

Cliff