I have a problem with the sematics of the the signal connect method.
Consider this simple program:
#include <iostream>
#include
Main world at 0xbffff2e0 Hello, World!, the parallel world exist at 0x8056128 Thats all folks!
My problem is that the object signalled is not the same object that I subscribed to the signal. Is this really what was inteded ? Is the any rationale behind this behaviour ? -- 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
On Wednesday 16 April 2003 08:26 am, Jesper Bojesen wrote:
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. In STL, function objects are copied around at will, so Signals picks up that part of the function object concept. If you want Signals to keep a reference to a function object (instead of making a copy), use boost::ref: sig.connect(boost::ref(hello)); Doug
Jesper Bojesen wrote:
I have a problem with the semantics of the the signal connect method.
[...]
int main () { // Connect a HelloWorld slot HelloWorld hello; std::cout << "Main world at " << (void *) &hello << std::endl;
boost::signal
sig; sig.connect(hello); sig ();
std::cout << "Thats all folks!\n"; return 0; }
[...]
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.
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.
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
Jesper Bojesen wrote:
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.
This would mean that any use of signals with bind is a programming error. sig.connect( bind(...) ); // object returned by bind dies here
On Wednesday 23 April 2003 09:56 am, Jesper Bojesen wrote:
On Wed April 23 2003 15:24, Peter Dimov wrote:
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.
Many of the function objects that a signal deals with are tempoaries, e.g., function objects returned from bind, whose types sometimes cannot be named (by the user). It would be extremely inconvenient to have to try to store these objects so that we could pass a reference to the signal. Also, within the STL there seems to be the implicit assumption that function objects are cheap to copy and don't carry individual state; Signals follows this philosphy as well. Doug
participants (3)
-
Douglas Gregor -
Jesper Bojesen -
Peter Dimov