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

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2008-01-15 20:03:37

> Today starts the formal Fast-Track review of the Boost.Utility/Singleton 
> library.

I've never made much use of singletons, but I won't let that stop me 
from commenting...

My thoughts:

1. There's no "un-synchronised" version, for use in single-threaded 
programs or when all (first) accesses come from the same thread.

2. The "mutexed access" feature can be useful in situation other than 
singletons; can't something more general-purpose be provided?  I use a 
template class Lockable<T> which grants reader/writer-exclusive access 
to a contained T.  (Reader/writer locking could be useful here.)  (It 
might be useful to make the mutex type a template parameter, with a 
sensible default; I have a few mutexes of my own, with a 
boost::mutex-compatible interface.)

3. Function static variables can be thought of as "local singletons", 
but they aren't synchronised.  It would be great if we could replace 
"static T t(.....);" with "safe_static<T> t(.....);" and get the same semantics.

4. As far as I can see, most of what this library does is to simplify this:

class my_thing: noncopyable {
   my_thing() { ...... }
public:
   my_thing& instance() {
     static my_thing i;
     return i;
   }
};

to this:

class my_thing: public singleton<my_thing> {
public:
   my_thing(restricted) { ....... }
};

which is a saving, but not a huge one, and the fact that there's 
"behind-the-scenes magic you have to understand and trust" going on in 
the second case, compared to only "C++ 101" language features in the 
first one, makes me prefer not to use it.  EXCEPT, of course, for the 
thread-safety feature.  Which brings me back to my points above.  If 
instead we could write:

class my_thing: noncopyable {
   my_thing() { ...... }
public:
   my_thing& instance() {
     safe_static<my_thing> i;  // or maybe SAFE_STATIC(my_thing,i) if we 
have to
     return i;
   }
};

then I think I would be happy.

> * What is your evaluation of the design?

See above.

> * What is your evaluation of the implementation?

Not studied.

> * What is your evaluation of the documentation?

Good.

> * What is your evaluation of the potential usefulness of the library?

I suppose I might use it if I ever needed a thread-safe singleton.

> * Did you try to use the library? With what compiler?

No.

> * How much effort did you put into your evaluation?
>    A glance? A quick reading? In-depth study?

30 mins reading the docs and writing this message.

> * Are you knowledgeable about the problem domain?

Not especially.  I know a bit about threads.

> And finally, every review should answer this question:
>
> * Do you think the library should be accepted as a Boost library?
>    Be sure to say this explicitly so that your other comments
>    don't obscure your overall opinion.

My answer is yes, but....

Would other people like to comment about the quantity of stuff in 
Boost, and the extent to which sheer volume will slow down future 
releases?  I worry that by accepting libraries simply because they are 
"good enough", we'll end up unable ever to release anything!  If 
instead we were to focus on really compelling core stuff that ought to 
end up in the standard library, could we accelerate the release process?

Cheers,  Phil.