Re: [boost] [review] Fast track review of Boost.Utility/Singletonbegins today

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 
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