Re: copying sigc::signals

[Chris Vine <chris cvine freeserve co uk>]

On Thu, 04 Mar 2010 22:46:04 -0600
Jonathon Jongsma <jonathon quotidian org> 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