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

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

> > 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.
 
> > 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, 
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.
 
> > 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"?

http://www.devarticles.com/c/a/Cplusplus/C-plus-plus-In-Theory-The-Singleton-
Pattern-Part-I/4/
 
Gennadiy