On Wed April 23 2003 15:24, Peter Dimov wrote:
Jesper Bojesen wrote:
I have a problem with the semantics of the the signal connect method.
[...]
[...]
[...]
My problem is that the object signalled is not the same object that I subscribed to the signal.
Is this really what was inteded ?
Yes.
Is the any rationale behind this behaviour ?
Yes. Consider what would happen if hello were destroyed before the sig() call.
But we have signals::trackable to handle that problem. I would much prefer to have a compilation error for a non-trackable function object, than have semantics that at first glance seems to do what I expect, and then, when I start doing more involved processing in the slot, will come back and bite me. The thinking here is that if the slot goes away without disconnecting that is a programming error. -- When the signal makes a copy of the slot, it only masks the error, it doesn't fix it.
I am aware that I can get the behaviour that I expected if I create the slot using the bind function, however, I find the simpler syntax very nice, but its semantics are counter intuitive, and potentially very confusing.
Try sig.connect(ref(hello)) to request a reference to be stored.
Ah! - much nicer indeed. -- Jesper Bojesen Medical Insight Email: jbb@medical-insight.com Phone mobile: (+45) 40 99 55 03 Phone direct: (+45) 46 55 04 42 Fax: (+45) 46 55 11 66