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

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2008-01-18 04:12:54

Gennadiy Rozental wrote:
> Tobias Schwinger <tschwinger <at> isonews2.com> writes:
>>>>> 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.
> 
> No. It doesn't ensure that. One can still create instances of my class with 
> valid C++. It's not brief implementation wise in comparison with doing nothing 

which is error prone

> and an alternative is as brief usage wise.

Further:

Making friend with a template in another namespace does not work with a 
well-known and widely used compiler.

>  
>>>>> 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.
> 
> So you can't state it works for DLL. No one is able to verify. 

No? I didn't know the people on this list are incapable of writing code!

> Or do you expect us to believe your word?
>  

Believe whatever you want ;-).

>>>>> 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.
> 
> It does. You either do or don't do syncronization based on it.
>  

Synchronisation with what? In a program with just one thread it's just a 
no-op.

Regards,
Tobias