On Feb 9, 2007, at 3:21 PM, Timmo Stange wrote:
Frank Mori Hess wrote:
I'm noticing now that boost::last_value isn't thread-safe when used with a non-void return value, since a thread can't in general be sure the signal will have any slots connected to it when it is invoked. Would it be acceptable to make last_value throw an exception on the non-void, no slots case? Throwing an exception seems preferable to the dreaded "undefined behaviour". Or we could use a slightly modified default combiner with a different name.
Returning an Optional if T is default constructible seems like a viable refinement of that solution. I'm a little uncomfortable with exceptions being thrown potentially everywhere along the call chain as a default behaviour.
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. Cheers, Doug