Re: [Boost-users] [signals] thread_safe_signals feature-complete

From: Frank Mori Hess (fmhess_at_[hidden])
Date: 2007-02-17 17:59:43

On Saturday 17 February 2007 03:26 pm, Timmo Stange wrote:
> Frank Mori Hess wrote:
> > It's to compensate for the fact that it is not called in the
> > constructor, which I originally tried.  If it's not called before the
> > first dereference, then you might try to execute an invalid slot.  If
> > it's not called before the first increment, then you might not
> > increment past the first slot.  I got rid of the call in the
> > constructor because it killed concurrent invocation, due to the
> > iterators still in scope in operator() holding locks to the first
> > slot.  However, since I optimized it to only create temporary
> > iterators when passing them to the combiner, I could probably just put
> > the call back into the constructor.
>
> I'd say the combiner must always check for an empty range and the
> comparison of first and last will always ensure a valid position, or?
>

Yes, you're probably right.  I must have got it into my head that the 
combiner couldn't check for an empty range back when I discovered 
last_value had undefined behaviour if there were no slots connected.

-- 
Frank