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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2005-01-10 13:48:01

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.

The upside is no base classes and no visit_each.

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?