Tobias Schwinger <tschwinger <at> isonews2.com> 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.
4. DLL support
Explanation of DLL issues in docs is very unclear. No examples
We shouldn't based our desings/interfaces based on broken compilers. 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.
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 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. Gennadiy