Timmo Stange wrote:
I don't like this idea, because it effectively means dropping tracking altogether.
You must be referring to the fact that you can't detect an expired slot until it is invoked (a fact that slipped my mind). I'll have it both ways then: keep the explicit slot-to-slot tracking, but also make slot::operator() throw on an expired slot, and make last_value handle exceptions thrown by expired slot exceptions. The signal would still do an explicit lock() on the slot, and call it through a slot::unlocked_call() which doesn't bother checking the tracked objects. Then, the disconnect on exception would handle cases where the user hasn't explicitly tracked the slot, due to automatic disconnection on invocation being good enough and not wanting to keep track of slots hidden inside other function objects.
... while silently swallowing the bad_weak_ptr exceptions.
I don't have any problem with throwing a more specialized exception. To be really paranoid, it could even have a private constructor to discourage the user from reusing it for other purposes. I probably wouldn't do that though, as I don't see a problem with letting the user deliberately trigger the signal's slot disconnection mechanism if they choose to. -- Frank