Jeff Garland <jeff@crystalclearsoftware.com> 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