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