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

From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2008-01-18 10:00:40

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?
 
> > 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.
 
> > 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.
 
> >>>>> 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.

Gennadiy