Frank Mori Hess wrote:
Another question is if both alternatives should be provided, or if tracking should only work when you create a slot_type object explicitly.
I have no problem with only providing tracking support through slot::track().
I agree.
I'd also like to mention that you can effectively hide the tracking from the connection setup site with the original implementation. If you only provide a typedef for the functor you want to be used for the connection, visit_each can collect the information automatically (or at least in a way invisible to the connecting code).
I'm not following what you're saying here. Can you give some kind of example for what you're suggesting?
You can look at random_signal_system.cpp for a real example, but it's quite simple: A class can provide a predefined function class and an overload for visit_each. The connecting code creates an instance of that class to connect to the signal and doesn't need to care about tracking, because it is set up by the slot and visit_each. struct some_observer { signals::tracked ptr_to_some_secret_object; some_observer(); // Sets up ptr_to_some_secret_object void operator()(); // Uses ptr_to_some_secret_object }; ... signal0<void> sig; sig.connect(some_observer()); The advantage is that the party establishing the connection does not need to know what objects have to be tracked. It's not such a big asset, but it's something you cannot do with the explicit track(). Regards Timmo Stange