Boost logo

Boost :

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2008-01-18 04:12:54

Gennadiy Rozental wrote:
> Tobias Schwinger <tschwinger <at>> writes:
>>>>> 3. public construction and boost::restricted
>>>>> I don't like this solution and very much prefer private constructor with
>>>>> friend declaration (especially if encapsulated into single macro). This
>>> will
>>>>> be a never ending source of confusion (what is boost::restricted, can I
>>> have
>>>>> restricted access, how do I create restricted instances etc) and doesn't
>>>>> really protect - once can still create instances of my class with valid
>>> C++
>>>>> code.
>>>> You're still free to use a private constructor and a friend declaration.
>>> Yes. But argue that you are trying to promote bad practice.
>> Arguably. It works well to ensure the component is used as intended,
>> it's brief and it optimizes out entirely.
> 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

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

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

> Or do you expect us to believe your word?

Believe whatever you want ;-).

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


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