Re: [boost] boost signals2 review

Subject: Re: [boost] boost signals2 review
From: Frank Mori Hess (fmhess_at_[hidden])
Date: 2008-11-11 22:26:08

On Tuesday 11 November 2008 11:25, Stjepan Rajko wrote:
> On Mon, Nov 10, 2008 at 9:18 AM, Andrew Webber <andy_at_[hidden]> 
wrote:

> > *   Why the change to boost::optional for signal return values.  Maybe
> > I missed a discussion about the motivation on the mailling list, but
> > this is an interface change that appears to be unnecessary.

The default combiner used by Boost.Signals (last_value) requires there to 
be at least one slot connected for non-void return types.  This isn't a 
practical requirement in a multi-threaded environment, where other threads 
may be connecting/disconnecting concurrently with signal invocation.  
optional_last_value avoids the problem, since it can return an empty 
boost::optional when no slots are connected.  Also, I'd like to note that 
there is really no difference between the void specializations of 
last_value and optional_last_value, which is the common case.

> > *   I would like to see examples provided to explain the use of
> > postconstructable, predestructable, and deconstruct_ptr.  I think a
> > concrete example might clear up some people's confusion over when it's
> > appropriate to use these.

Ok

> > *  I'm not very happy about the tendancy of the slot disconnect
> > exceptions to show up in Visual Studio output.  For instance, I built
> > a test program where several tracked objects were destroyed from
> > different threads, based on a random timer, while the slot was being
> > invoked over and over.  The program worked well except for a great
> > deal of repeated output like the following:
> >
> > First-chance exception at 0x7c812a5b in SignalsTest.exe: Microsoft C++
> > exception:
> > boost::exception_detail::clone_impl<boost::exception_detail::error_inf
> >o_injector<boost::bad_weak_ptr>
> >
> >> at memory location 0x0012dc0c..
> >
> > First-chance exception at 0x7c812a5b in SignalsTest.exe: Microsoft C++
> > exception: boost::signals2::expired_slot at memory location
> > 0x0012df58..

If visual studio wants to tell you every time an exception gets thrown, 
isn't that visual studio's problem?  Or, are you trying to make the point 
that Signals2 should be trying harder to avoid using exceptions in the 
automatic disconnection code paths, due to possible performance overhead?