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
> > valid C++. It's not brief implementation wise in comparison with doing
> which is error prone
What is error pronne?? Doing nothing?
> > and an alternative is as brief usage wise.
> 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
> >>> 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
> >>>> 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
> > 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
> > time
> >>> switch which should have no bearings in design on singleton. regardless
> >>> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk