Tobias Schwinger <tschwinger <at> isonews2.com> writes:
2. thread_specific_singleton.
The same as above. This should be singleton<thread_specific<T> >. Current design mixes two orthogonal concepts: uniqueness of class instance and thread specific object storage.
One could implement what you propose. It would probably even make things easier on my side.
It complicates client code
How come? If anything it simplify things. Let's say I want now more than one instance of the class, but still need syncronized access to it's methods. In your case I'll havereimplement the whole thing.
and compromises the replaceability of all the Singleton templates, which is a mistake.
I am not sure what exactly it compromises.
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.
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.
5. instance proxy.
Given complete absence of rationale of this design, I can't really devise why is was chosen, but it seems wrong. We end up with pricy complication with unclear purposes. What's wrong with just returning T& from instance method? The same time we can get rid of all this member_dereference staff and it's limitations.
What limitations are you talking about?
in member_derefernce there is max_args macro
The ability to have automatic locking when using a member pointer?
Ability is good. Your design actually more on enforcement side.
6. lease.
Pretty much the same as above. synchronized<T> should have it's own lock facility. Otherwise instance() should be straightforward access to the instance and no need for any proxies/leases.
Again, fails to see the advantage of a uniform interface.
The simpler, the better. So this is actually other way around: what is an advantage of this lease API
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.
8. No Meyer's singleton
What if do not want all this manager staff?
What's "all this manager staff" and
I just want singleton. Don't care about it's distruction order. And don't need anyone to manage it.
what's a "Meyers' singleton"?
http://www.devarticles.com/c/a/Cplusplus/C-plus-plus-In-Theory-The-Singleton... Pattern-Part-I/4/ Gennadiy