From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2008-01-17 11:31:16
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
> > 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
> > 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.
> > 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,
> > 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.
> > 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"?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk