Re: [boost] [review] Fast track review of Boost.Utility/Singletonbegins today

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2008-01-17 15:32:31

Gennadiy Rozental wrote:
> Tobias Schwinger <tschwinger <at> isonews2.com> writes:
> 
>>> 2. thread_specific_singleton.
>>>
>>> The same as above. This should be singleton<thread_specific<T> >. Current 
>>> design mixes two orthogonal concepts: uniqueness of class instance and 
>>> thread specific object storage.
>> One could implement what you propose. It would probably even make things 
>> easier on my side.
>>
>> It complicates client code 
> 
> How come? If anything it simplify things. Let's say I want now more than one 
> instance of the class, but still need syncronized access to it's methods. In 
> your case I'll havereimplement the whole thing.
> 
>> and compromises the replaceability of all the 
>> Singleton templates, which is a mistake.
> 
> I am not sure what exactly it compromises.

'singleton<T>' and 'mutexed_singleton<T>' sharing the same syntax.

>>> 3. public construction and boost::restricted
>>>
>>> I don't like this solution and very much prefer private constructor with 
>>> friend declaration (especially if encapsulated into single macro). This 
> will 
>>> be a never ending source of confusion (what is boost::restricted, can I 
> have 
>>> restricted access, how do I create restricted instances etc) and doesn't 
>>> really protect - once can still create instances of my class with valid 
> C++ 
>>> code.
>> You're still free to use a private constructor and a friend declaration.
> 
> Yes. But argue that you are trying to promote bad practice.

Arguably. It works well to ensure the component is used as intended,
it's brief and it optimizes out entirely.

>>> 4. DLL support
>>>
>>> Explanation of DLL issues in docs is very unclear. No examples provided. 
> No 
>>> tests showing that solution actually works. Accordingly I can't really 
>>> comment on it, but from what I got I really doubt it.
>> The test just hasn't been automated yet. And, yes, the documentation can 
>> use some improvement.
> 
> As far as I can tell, simply there is no tests for this scenario.

I probably didn't include it in the archive.

>  
>>> 5. instance proxy.
>>>
>>> Given complete absence of rationale of this design, I can't really devise 
>>> why is was chosen, but it seems wrong. We end up with pricy complication 
>>> with unclear purposes. What's wrong with just returning T& from instance 
>>> method? The same time we can get rid of all this member_dereference staff 
>>> and it's limitations.
>> What limitations are you talking about?
> 
> in member_derefernce there is max_args macro

Oh well...

> 
>> The ability to have automatic locking when using a member pointer?
>  
> Ability is good. Your design actually more on enforcement side.
>

It's more about having just one interfaces for all Singleton variants.

>>> 6. lease.
>>>
>>> Pretty much the same as above. synchronized<T> should have it's own lock 
>>> facility. Otherwise instance() should be straightforward access to the 
>>> instance and no need for any proxies/leases.
>> Again, fails to see the advantage of a uniform interface.
> 
> The simpler, the better. So this is actually other way around: what is an 
> advantage of this lease API

You can skip the initialization check.

> 
>>> 7. MT support
>>>
>>> Setting aside mutexed and thread specific singletons covered above, 
> regular 
>>> singleton handling of MT is wrong as well. In simple words my primary 
>>> complain: you can't use define based solution for switching MT/non MT. It 
>>> should be template parameter. As of now there is no singleton that can 
> work 
>>> in presence of threads but without disregard to them.
>> I can't get your point. There probably is none.
> 
> I meant "without regard to them". IOW BOOST_HAS_THREADS is global compile time 
> switch which should have no bearings in design on singleton. regardless of 
> this flag I may or may not want instance construction to be syncronized.

The design doesn't change based on that macro.

If there is just a single thread all Singletons behave the same -- with
or without that macro defined.

If you want to avoid the initialization check within one thread you can
'lease' a non-mutexed Singleton.

Yes, the creation will be synchronized but it's very unlikely that this
part will become a performance bottleneck.

>  
>>> 8. No Meyer's singleton
>>>
>>> What if do not want all this manager staff?
>> What's "all this manager staff" and 
> 
> I just want singleton. Don't care about it's distruction order. And don't need 
> anyone to manage it.

OK, then just don't care and things just work. If you insist on Meyers'
Singleton: Write it -- it's just a few lines :-).

> 
>> what's a "Meyers' singleton"?
> 
> http://www.devarticles.com/c/a/Cplusplus/C-plus-plus-In-Theory-The-Singleton-
> Pattern-Part-I/4/
>  

OK, that's basically a Go4 Singleton implemented in C++. It might now
work reliably in dynamic libraries with some ABIs.

Regards,
Tobias