On Thu, 04 Mar 2010 22:46:04 -0600 Jonathon Jongsma <[email protected]> wrote: > So, I made a rather surprising (to me) discovery the other day. When > you copy a signal, any slots that you connect to the copied signal > will also be triggered when you emit the original signal. Perhaps > this is better explained by the following code:
It would be necessary to think about it further, but this may be a necessary result of sigc::trackable. If a signal is copied, it may have to do a shallow copy because of the difficulty in "2nd-registering" copies of the slots it holds which have been registered with the sigc::trackables of remote objects (you would have to work on all the remote trackables as well as copying the signal object itself). This may be one of the downsides of implementing trackability at the slot level rather than the signal level. It is probably not impossible to get the right behaviour but it may be very difficult: but this is a guess. Copying objects derived from sigc::trackable also present converse difficulties. You don't usually want the assignee to inherit the assignor's connections, and you don't want the assignee disconnecting the assignor's slots if it is destroyed before the assignor (and vice versa). I think libsigc++ just provides a vacant sigc::trackable object in its assignment operator/copy constructor (I cannot now remember and I don't recall libsigc++'s policy on this being documented.) It is probably better simply to disallow copying of signals, rather than do shallow copies resulting in the curious effects you mention. I took that line when writing some signal/slot classes of my own for use where libsigc++ was not suitable because it is not thread safe. (But these also happen to implement trackability at the signal level.) Chris _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
