Boost logo

Boost :

Subject: Re: [boost] Review Request: Singularity
From: Ben Robinson (icaretaker_at_[hidden])
Date: 2011-08-23 22:28:27


Mathias,

I think this discussion is getting a little off track. There is a lot
of literature on creating a thread-safe Singleton that manages the lifetime
of your object according to your needs. However, there is no silver bullet
for the pattern. Different variants make different tradeoffs depending on
the user's needs. The three issues that are inherent to Singleton are:

1) You have little control over when the Singleton is destroyed. Should you
have multiple Singleton which depend on each-other, very often you need a
very specific teardown order. Singularity gives you this control directly.
 Singleton does not. There are also creation ordering problems as well
depending on the implementation. These problems are well documented, and
solutions like the Meyers Singleton and the phoenix Singleton have been
developed to address it, but no solution is a silver bullet.
2) The instance() member is global, so you cannot fully encapsulate it
inside the classes that need it. Singularity allows you to optionally
expose global access to the class, should you desire context independent
objects.
3) Singleton restricts you to a single constructor, usually the default one.
 Singularity allows you to use any/all of the constructors of your object.

Singleton is useful. But it does it have quirks/limitations/difficulties.
 I am providing Singularity to directly address the weakness of Singleton,
and provide a better approach for ensuring a single instance of the class.
 My hope is that the community will recognize that the Singularity design
pattern is superior to the Singleton design pattern for many applications,
and adopt its use where appropriate.

Thank you,

Ben Robinson, Ph.D.

On Tue, Aug 23, 2011 at 2:34 PM, Mathias Gaunard <
mathias.gaunard_at_[hidden]> wrote:

> On 08/23/2011 10:26 PM, Stephan T. Lavavej wrote:
>
>> [Mathias Gaunard]
>>
>>> which is simple, short, fast to compile, and thread-safe.
>>>
>>
>> [John Maddock]
>>
>>> Not thread safe on the majority of compilers surely?
>>>
>>
>> [Mathias Gaunard]
>>
>>> Isn't MSVC the only one that doesn't do it?
>>> And MSVC11 does it, I believe.
>>> I thought I had read that somewhere, but I can't find the source anymore
>>> so maybe I'm just confusing it with something else.
>>> Hopefully it will be the case though.
>>>
>>
>> You're thinking of C++11 "magic statics" (my term),
>> http://www.open-std.org/jtc1/**sc22/wg21/docs/papers/2008/**n2660.htm>"Dynamic Initialization and Destruction with Concurrency".
>>
>
> I'm just thinking of them being thread-safe.
> Whether it uses the crazy lockfree algorithm or not is of little relevance
> to me, and is more a QoI issue.
>
> They have been thread-safe in GCC at least since version 4.0.
> It is mandated by the Itanium C++ ABI that is followed by most compilers.
>
>
> ______________________________**_________________
> Unsubscribe & other changes:
http://lists.boost.org/**
> mailman/listinfo.cgi/boost<http://lists.boost.org/mailman/listinfo.cgi/boost>
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk