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 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.
Further: 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 no-op. Regards, Tobias