[boost] Re: Singleton: review

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2005-05-16 12:22:59

>> Problem domain
>> ============
>>
>> But... from my experience it's really bad idea to try to manage an order 
>> of destruction of global variables. Any responsible library designers 
>> should prefer explicit teardown procedure.
> Explicit teardowns would be source of coupling and something
> pretty hard to maintain (for me, others may find it easy).

I do not see how it may be cause of any new coupling. It does add one 
function to the singleton interface. If you have several singletons in you 
library that have non-trivial teardown I usually add single library level 
teardown routine.

>> class A : singleton_ex<static_lifetime_ex<instant_creation,my_lock> > 
>> {...};
>>
>> Here I not only need to mention default creation policy, but also strange 
>> beast static_lifetime_ex. And I only needed custom lock:
>>
>> class A : singleton<lock<my_lock> > {}
>>
> This is valid issue. Perhaps named template parameters technique
> could be used here.

Most importantly design shoulf be cleared from all these "super policies"

>> Inability of the author to clearly recognize orthogonal policies lead to 
>> 2 subpolicies with "create" in their name: CreationPolicy and Creator.
> The name and concept may be reconsidered as suggested
> by Dan Rosen in other thead.

As it follows from my review I do not see a need for creator at all.

>> I do not see why would anyone would need to employ malloc or 
>> std::allocator to allocate memory for global variable.
> Quite often. If you do custom memory management with new/delete

First of all you do NOT do custom memory management "quite frequently". I 
mean in general in C++ comminity. But even in such case  I do not see a 
reason to apply it to singleton. Custom memory allocation is a performace 
enhancement tecnique (most cases). I do not see a need to speed up singleton 
construction. It happends once per process lifetime.

> you often set it up after statics initialization (say when loading a DLL).
> Either one needs to do nasty tricks with shared variables or use 
> malloc/etc.

You lost me here with "set it up after statics initialization".

>> Most interesting is that among all of these "creators"/creation_policies 
>> I don't see a solution for singleton with non-default constructor.
>>
> Yes, this should be supported.

It's actually should be one of the major "features" of generic singleton 
(would we ever need one).

>> is about 300 times faster then (modify definition above to employ default 
>> singleton: class A : public basic_singleton<A>)
>>
>> (used g++ 3.3.3 on windows)
>>
>
> I tried this with Intel 7 plugged in VC6 IDE, Release mode,
> all settings default and the ratio was 8.7 (in favor of raw class A).

Well it obviosly depends on compiler and it's optimizer module. But even 2 
times overhead in performace critical area may not be acceptable. And 
singleton prone to be such an area.

>> Author does admit that multithreading issues were not considered. IMO any 
>> singleton design that doesn't cover MT couldn't be accepted as generic.
> Not every library in Boost is MT safe even when it could be useful.
> MT was left into next stage.

You could not leave MT for the next stage of singleton design. Singletons 
have a long history dealing with MT issues topped with DL idiom.

> I suggested it as example but shortage of time ...

I do not see why the hurry. IMO this submission simply is not ready to be 
reviewed (beyond the fact it's doing the wrong service for the programmers 
IMO)

Gennadiy