From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-08-01 07:45:05
On Wednesday 31 July 2002 10:43 pm, Niall Kelly wrote:
> boost::function1<void, unsigned> f =
> boost::bind(&AClass::AMethod, pAInst, _1);
> The code above happily compiles and runs as expected.
> However, if pAInst is deleted at some point the bound
> method remains connected to the signal.
> I then realised that rather than assigning the result
> of the bind to the boost::function f, I should assign
> it to a tSlotType variable which is then passed to
> sig.connect(). In this case, the trackable behaviour
> works as documented - if I delete pAInst, the slot is
> disconnected as expected.
> My concern is that it seems reasonable to pass a
> boost::function to the signal's connect (just as it is
> reasonable to pass a plain old C function) and yet the
> behaviour is quite different to the case where the
> slot is explicitly connected as a slot_type.
It does seem reasonable, but unfortunately I don't think it can work without
introducing significant overhead into boost::function. Now that I think about
it, this can be _really_ confusing: the slot_type is almost a boost::function
object (but not exactly), but their behavior is completely different with
respect to bound objects and there's no way to detect that at compile time. I
think the best option is to completely disallow direct connection of
boost::function objects as slots.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk