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

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 ;-)

Jeff