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

From: Frank Mori Hess (fmhess_at_[hidden])
Date: 2007-02-10 17:08:06

On Friday 09 February 2007 08:55 pm, Timmo Stange wrote:
> Frank Mori Hess wrote:
> >> The problem is that we don't get to return an optional, because the
> >> return type is specified as "T", not "optional<T>".  And,
> >> unfortunately, we can't rely on there always being a default
> >> constructor there.
> >>
> >> Right now, the implementation is allowed to crash if you call one of
> >> these signals and there are no slots. Throwing an exception brings
> >> some sane defined behavior to something that is now completely
> >> undefined.
> >>
> >> If we could reliably detect default-constructibility, we might be
> >> able to come up with something better.
> >
> > We could add a little header with a definition of a "last_optional"
> > combiner for people to use if they prefer.
>
> 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.

-- 
Frank