From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2008-01-17 15:32:31
Gennadiy Rozental wrote:
> 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.
'singleton<T>' and 'mutexed_singleton<T>' sharing the same syntax.
>>> 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.
>>> 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.
>>> 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.
It's more about having just one interfaces for all Singleton variants.
>>> 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.
>>> 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. It
>>> 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 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.
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.
>>> 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 :-).
>> what's a "Meyers' singleton"?
OK, that's basically a Go4 Singleton implemented in C++. It might now
work reliably in dynamic libraries with some ABIs.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk