Frank Mori Hess wrote:
I think I might have found a solution, if not a particularly beautiful one: With "signal for a slot" being handled as a special case anyway, I can create a "counterfeit copy" of the signal with the original signal object controlling the state and the counterfeit just sharing the implementation. When the original copy goes out of scope, all slots will be disconnected. The rest can be handled with some additional functionality in the tracking code.
If the signal is implemented with a pimpl via a shared_ptr, couldn't boost::track just store a weak_ptr to the pimpl in the special case of a signal argument? The signal could invoke the the boost::tracked by using the get_pointer() function and invoking it as a pointer to a function object (assuming the pimpl provides an operator() member function). Is that is what you are already suggesting?
Our influence on slot target storage and invocation is limited, as the client tells us what container type to use through a template parameter (SlotFunction). I would prefer to store a normal function object there instead of trying to trick it into invoking the object through a pointer and still getting the argument binding right. That's why I'd rather use a copy of the full signal object instead of its pointer to implementation. We can be sure that everything will work as expected, no matter what type SlotFunction is. The tracking will then need extra functionality to identify signal targets that have been disconnected, but I think that's easier to achieve, because we are in control of all the types involved. Regards Timmo Stange