Boost logo

Boost :

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

Gennadiy Rozental wrote:
> Tobias Schwinger <tschwinger <at>> 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.

 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

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


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