|
Boost Users : |
From: Douglas Gregor (gregod_at_[hidden])
Date: 2003-04-23 10:23:49
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
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