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