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

From: Timmo Stange (ts_at_[hidden])
Date: 2007-02-09 20:55:59

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.

I've come across another problem that I find difficult to solve: Since
signals are not copyable, the current implementation reference-wraps
them when they're used as a slot target. The proper lifetime-dependency
is established by signals being trackable subclasses, but we agreed
that this won't work with thread-safe signals. Our weak_ptr-based
solution doesn't work well when the tracked object is the actual
target function object. Any suggestions?

Regards

Timmo Stange