|
|
Boost Users : |
From: Jesper Bojesen (jbb_at_[hidden])
Date: 2003-04-23 08:56:40
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_at_[hidden] Phone mobile: (+45) 40 99 55 03 Phone direct: (+45) 46 55 04 42 Fax: (+45) 46 55 11 66
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net