On Tuesday 11 November 2008 11:25, Stjepan Rajko wrote:
On Mon, Nov 10, 2008 at 9:18 AM, Andrew Webber <andy@aligature.com> 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?