From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2008-01-18 04:12:54
Gennadiy Rozental wrote:
> Tobias Schwinger <tschwinger <at> isonews2.com> 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
>>>>> be a never ending source of confusion (what is boost::restricted, can I
>>>>> restricted access, how do I create restricted instances etc) and doesn't
>>>>> really protect - once can still create instances of my class with valid
>>>> 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.
>>>>> 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,
>>>>> 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.
>>>>> should be template parameter. As of now there is no singleton that can
>>>>> 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
>>> 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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk