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