Re: [sigc] Re: [Boost-users] Signals & Slots

From: Doug Gregor (dgregor_at_[hidden])
Date: 2005-01-10 14:58:25

On Jan 10, 2005, at 1:48 PM, Peter Dimov wrote:

> Doug Gregor wrote:
>>> I always thought that Boost had quite some influence on standard
>>> proposal? Who come that the TR is in a bad shape for a signal system,
>>> then?
>>
>> I wouldn't say that it is in bad shape for a signal system. The
>> problem with {boost:: or tr1::}function and a signals system is that
>> they both do the same thing: erase the static type of a function
>> object so that it can be called through an entity that does not
>> encode that type. The problem is that we need to call visit_each
>> before we erase that type: 'function' shouldn't do it all the time,
>> because that could be costly, and the signal/slot can't do it because
>> the type is gone.
>
> I still think that we need to explore the alternative approach of 
> storing a weak_ptr in the function object and make the signal 
> automatically disconnect on bad_weak_ptr. This ties automatic 
> disconnection to shared_ptr+weak_ptr, but now they are part of TR1.

This is still a really good idea, and we should support it.

> The upside is no base classes and no visit_each.

The downside is that you have to use shared_ptr + weak_ptr. Granted, 
that's a pretty common use case.

> I'm not sure whether this line of thought should be continued to its 
> natural conclusion, making the signal disconnect on any exception, not 
> just bad_weak_ptr. bad_function_call, for example, is an obvious 
> candidate. What is the current course of action when a slot throws?

The exception is propagated to the combiner (Boost terminology; it's 
accumulator in libsigc++), which may intercept it. The default combiner 
propagates it back to the signal caller.

        Doug