The Singularity Design Pattern seeks to address the three weaknesses of the Singleton Design Pattern. Namely: 1) Lifetime: Singleton introduces lifetime management complexities (for a detailed discussion, see Chapter 6 of Modern C++ Design by Andrei * Alexandrescu*). 2) Initialization: Singleton restricts the class to the default constructor. This makes Singleton unusable for classes which require non-default constructors. 3) Encapsulation: Singleton provides global access to the class. Some may view this as a feature, but advocates of unit testing, dependency injection, and context independent objects would disagree. Singularity guarantees a single instance of a class, but does not suffer from 1-3 above. Usage is as follows: // Usage as a Factory: typedef singularity<Horizon, single_threaded> HorizonSingularityType; Horizon & horizonF = HorizonSingularityType::create(value, &event, event); HorizonSingularityType::destroy(); // Usage as a Base Class: class Horizon : public singularity<Horizon, multi_threaded, global_access> Horizon & horizonB = Horizon::create(value, &event, event); Horizon & horizonC = Horizon::get(); Horizon::destroy(); The usage example above shows the three advantages of Singularity over Singleton: 1) Singularity does not permit lazy initialization by design. The lifetime of the single object is bounded by create() and destroy(), and this lifetime is managed just like objects bounded by new() and delete(). 2) Singularities of objects can be created using any available constructor for that object. 3) Singularity prevents global access to the instance by default. However, if this is required, or will help to transition from Singleton, a policy can be supplied which enables a get() accessor to the instance. It is also worth pointing out that thread safety is policy based, and both a single_threaded, and multi_threaded policy are provided. The source files are available here: http://www.mediafire.com/?d8kn5fx2n5d22 I look forward to your feedback. Thank you, Ben Robinson, Ph.D.