Boost logo

Boost :

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

Tobias Schwinger <tschwinger <at>> 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.
> 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
> >>> 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
> 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at