Review Request: Singularity

Hello, I would like to thank the Boost community for their invaluable feedback regarding the features and implementation details of Singularity. Singularity has been greatly refined and I am now requesting a formal review. I have compiled and run Singularity on 4 different compilers: GCC 4.5, MSVC++ 2010, the CL2000 TI compiler targeting the 2803x processor, and the Green Hills compiler targeting the Cortex-A8 ARM processor. The documentation, implementation and Boost unittests are available on GitHub at https://github.com/icaretaker/Singularity. Please note, that I have also implemented Singularity in C++11 using perfect function forwarding in the /cpp11 subdirectory, but that is not part of the submission, unless Boost is accepting C++11 libraries at this time. I will now include an excerpt of the documentation file "singularity.htm" which is part of the GitHub download: Introduction<file:///C:/home/ben/workspace_boost/boost/source/common/libs/singularity/singularity.htm#singularity.introduction> The Singularity Design Pattern allows you to restrict any class to a single instance. Singularity gives you direct control over the lifetime of the object, and does not require you to grant global access to the object, nor limit you to a single constructor for that object. Motivation<file:///C:/home/ben/workspace_boost/boost/source/common/libs/singularity/singularity.htm#singularity.motivation> The ability to restrict a class to a single instance is an important technique. While the commonly used Singleton Design Pattern achieves the desired goal, it introduces three undesirable limitations, namely: 1. Lifetime: Singleton introduces lifetime management complexities. The undefined destruction order of multiple singletons is just one example. 2. Scope: Singletons are always globally accessible. Accessibility should be orthogonal to restrictions on the number of instances. 3. Initialization: Singletons typically restricts the class to the default constructor. This makes Singleton difficult for classes which require non-default constructors. Like Singleton, Singularity restricts a class to a single instance. However Singularity does not suffer from lifetime, scoping and initialization problems. The following are the advantages of Singularity over Singleton: 1. The lifetime of the single object is bounded by calls to create() and destroy(). This lifetime is managed similiarly to objects bounded by calls to new() and delete(). 2. Singularity does not force global access to the instance. If global access is required, then a globally accessible get_global() function can be enabled upon creation of the instance. 3. Singularities of objects can be created using any available constructor for that object. Thank you, Ben Robinson, Ph.D.

Hi, On Sun, Aug 14, 2011 at 23:20, Ben Robinson <icaretaker@gmail.com> wrote:
The documentation, implementation and Boost unittests are available on GitHub at https://github.com/icaretaker/Singularity.
I will now include an excerpt of the documentation file "singularity.htm" which is part of the GitHub download:
Could you provide an online page that we can read in a browser without downloading the package?
Introduction<file:///C:/home/ben/workspace_boost/boost/source/common/libs/singularity/singularity.htm#singularity.introduction>
Motivation<file:///C:/home/ben/workspace_boost/boost/source/common/libs/singularity/singularity.htm#singularity.motivation>
Those links are obviously wrong :)
Like Singleton, Singularity restricts a class to a single instance. However Singularity does not suffer from lifetime, scoping and initialization problems. The following are the advantages of Singularity over Singleton:
1. The lifetime of the single object is bounded by calls to create() and destroy(). This lifetime is managed similiarly to objects bounded by calls to new() and delete(). 2. Singularity does not force global access to the instance. If global access is required, then a globally accessible get_global() function can be enabled upon creation of the instance. 3. Singularities of objects can be created using any available constructor for that object.
Just a quick question : what about having a "singularity" in separate modules, like dlls? I've seen several singleton implementation ask the user to define manually the static instance because without doing it there would be problems with multiple dlls/so not using the same instance in case of extensions (dll/so loaded at runtime via os-specific API (or boost::extension) ). I'm not sure about the details of this potential problem, but did you try to use singularity in this kind of configuration? Joël Lamotte
participants (2)
-
Ben Robinson
-
Klaim - Joël Lamotte