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

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2008-01-18 11:00:45

Gennadiy Rozental wrote:
> Tobias Schwinger <tschwinger <at> isonews2.com> writes:
>>> 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
> 
> What is error pronne?? Doing nothing?
>  

Yes.

>>> 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.
> 
> We shouldn't based our desings/interfaces based on broken compilers.
>  
>>>>>>> 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!
> 
> It's not my responsibility to do a unit testing for you. From where I stand 
> any feature which is not backed up with unit test, can't be considerred 
> supported.

 From where I stand testing is a minor concern as long as it's obvious 
that something /can/ work -- in dubio pro reo.

>  
>>> Or do you expect us to believe your word?
>>>  
>> Believe whatever you want .
> 
> I believe your library doesn't work for DLLs. And you didn't even provide a 
> test to prove me wrong.

The purpose of testing is not to prove anything -- it about detecting 
defects.

>  
>>>>>>> 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.
> 
> As I said, I may want to do syncronization even if BOOST_HAS_THREADS is not 
> defined (for example with coroutine based solutions). And what is more 
> important I may not want to do it if BOOST_HAS_THREADS is defined. Your desing 
> enforces these decisions for me.

OK, you might have a point there.

Regards,
Tobias