Tobias Schwinger <tschwinger <at> isonews2.com> writes:
and compromises the replaceability of all the Singleton templates, which is a mistake.
I am not sure what exactly it compromises.
'singleton<T>' and 'mutexed_singleton<T>' sharing the same syntax.
In my suggestion there is single syntax, so nothing to share.
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 and an alternative is as brief usage wise.
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. Or do you expect us to believe your word?
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
Oh well...
The ability to have automatic locking when using a member pointer?
Ability is good. Your design actually more on enforcement side.
It's more about having just one interfaces for all Singleton variants.
I don't suggest having different interfaces for singletons. I argue that plain instance interface is all we need for all flavours of singleto, while what you present is at least 2: interface-> and lease.
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
You can skip the initialization check.
local reference and Meyers' singleton are as good in this regard.
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.
If there is just a single thread all Singletons behave the same -- with or without that macro defined.
If you want to avoid the initialization check within one thread you can 'lease' a non-mutexed Singleton.
Yes, the creation will be synchronized but it's very unlikely that this part will become a performance bottleneck.
It's not about performance at all. The fact that BOOST_HAS_THREADS is defined, doesn't mean I plan to build MT application. In fact I may not link with pthread at all. For example it defined if _REENTRANT is defined. In general it defined if compiler *thinks* it's in multithreaded mode. On the other hand I can imagine a curcomstances where I want syncronized initialization with BOOST_HAS_THREADS not defined. And finally even if I build MT application it doesn't mean I want creation of this concrete singleton to be syncronized. And you enforce it.
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.
OK, then just don't care and things just work. If you insist on Meyers' Singleton: Write it -- it's just a few lines .
That's true. But your framework need to support it as well. What If I decide that I do need to manage order of destruction of my singletons? Do I need to rewrite it completely now? Gennadiy