Re: [Boost-users] [signals] signal-signal connections and thread-safety

From: Frank Mori Hess (fmhess_at_[hidden])
Date: 2007-02-11 09:08:38

On Saturday 10 February 2007 07:11 pm, Timmo Stange wrote:
> Frank Mori Hess wrote:
> >> Yes, that'd be nice. I think a non-throwing partial specialization
> >> (or a simulated one for compilers that don't support it) of
> >> last_value would be good.
> >
> > If I'm following, you're saying something like
> >
> > last_value<T, U=T> would be like the current last_value<T> and
> > last_value<T, optional<T> > would be like last_optional<T>?  It seems
> > easier just to provide a stand-alone last_optional<T> since the
> > implementation of last_value<T> is so trivial.
>
> No, I meant a partial specialization for optional<T> directly, i.e.
> last_value<optional<T> >. That makes the return value of that function
> object (in our case the combiner) "optional", which reflects the
> intention to have it not throwing for an empty input range pretty
> well, I think.

The work-around for compilers lacking partial specialization is to give the 
specialization a different class name, right (e.g. last_optional<T>)?  So 
providing a partial specialization would result in last_value<optional<T> 
> throwing when compiled on some compilers and not on others.  It seems 
less confusing to provide last_optional<T> only.

-- 
Frank