Timmo Stange wrote:
I've come across another problem that I find difficult to solve: Since signals are not copyable, the current implementation reference-wraps them when they're used as a slot target. The proper lifetime-dependency is established by signals being trackable subclasses, but we agreed that this won't work with thread-safe signals. Our weak_ptr-based solution doesn't work well when the tracked object is the actual target function object. Any suggestions?
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. The series of problems does not end, though ;). Now I have a problem with understanding this in the original code: template<typename T> void maybe_get_pointer(const T& t, mpl::bool_<false>) const { // Take the address of this object, because the object // itself may be trackable add_if_trackable(boost::addressof(t)); } If I'm not mistaken, this takes the address of an object stored by value in the target function object and adds it to the list of tracked objects if it's derived from trackable. What I don't understand is how that is supposed to work. If not provided by reference, the visitor is run over a temporary target function object passed by the client when connecting or creating the slot. It is copied after that by the Function object by default. The tracked object will then be destroyed together with the temporary function object and the slot will be disconnected. The trackable_test.cpp only checks a case in which a pointer to trackable is bound to the function. So is this a bug or am I missing something? Regards Timmo Stange