Re: [Boost-users] [signals] Automatic connection management and MT

From: Timmo Stange (ts_at_[hidden])
Date: 2007-02-06 15:09:24

Doug Gregor wrote:

> So, the issue with Function's operator== is that it isn't possible to  
> compare two instances of boost::function via the operator==. However,  
> one can compare a boost::function object with a different function  
> object (say, std::plus<int>) using operator==. Signals only relies on  
> the latter behavior, e.g.,
> 
> 	sig.disconnect(my_func_object);
> 
> will compare the boost::function stored in each slot against  
> my_func_object using operator==, and remove those that match.

Ok, I think I got it now, thanks. So all the signal implementation
has to take care of is to keep the my_func_object type as a
template.

> Storing the combining in an Any was a dumb idea :)
> 
> Still, you will probably need to keep the combiner on the heap  
> somehow, because if a slot deletes the signal object, you don't want  
> to crash. This could happen in a GUI system, for example, in a  
> "button pressed" event on a "cancel" button, which deletes the dialog  
> holding the "cancel" button.

For the thread-safe implementation we will also need to keep
the signal's mutex alive for that case, so I was thinking of
using the impl shared_ptr (although I'm afraid of too many
atomic reference count adjustments being involved in every
signal invocation). Ensuring the combiner simultaneously would
bring us back to square one with storing it in the base class
(as an Any eventually).

I don't think the current implementation allows deletion
of the signal from a slot, btw. The signalN::combiner()
function returns a reference to the stored combiner, not
a copy of it. How about simply copying it in operator(), as
being CopyConstructable is a precondition for the combiner
anyway?

Thanks for the clarifications.

Regards

Timmo Stange