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