Re: [Boost-users] [signals] dropping ThreadingModel template parameter

From: Timmo Stange (ts_at_[hidden])
Date: 2007-03-01 16:53:11

Frank Mori Hess wrote:

> I guess if that's what the people want.  Allthough, I note that more 
> ubiquitous and lower-level libraries like smart_ptr have gotten away with 
> not providing a thread-safety template parameter.  In any case, a problem 
> I'd like to address is how painful it currently is to declare a 
> thread-safe signal, the threading model being at the end of a long list of 
> template parameters.  Two possibilities come to mind.  One is making 
> lightweight_mutex the default ThreadingModel, maybe called "auto_threaded" 
> and still providing single_threaded and multi_threaded for those 
> determined enough to plow through all the template parameters.  The other 
> is providing a templated typedef class that uses a tweaked set of defaults 
> for the template parameters appropriate for thread-safety.  For example,
> 
> mt_signal<Signature>::type
> 
> might be a signal type using last_value<optional<R> > for the combiner and 
> signals::multi_threaded for the ThreadingModel.

There's a third alternative: I've added support for a generalized
default parameter signals::use_default in my implementation, which
allows specifying the ThreadingModel argument without providing
an explicit SlotFunction argument.

On a side note: Boost.Iterator uses "use_default" at the boost
namespace scope and I wonder if it wouldn't be good to move such
common phrases into a distinct part/library in a namespace with
a short name. I'm using that in a class library of my own and
call those words and phrases "tactics". They are only simple types
and can be used for policy template parameters. So that "exclusive"
can be used to instantiate a mutex template as well as a file
template, for example - instead of exclusive_mutex and
exclusive_file.

Back to Signals: It's quite likely that a user will typedef the
signals anyway, so a long instantiation name is not a big problem.
Other cases where I'm reluctant to add too many parameters are
situations in which that complicates the interaction between re-
sulting types. That often speaks against an Allocator template
parameter, but is not applicable here, either. You can still
connect any type of slot to any type of signal - as long as the
signature matches.

Regards

Timmo Stange