Frank Mori Hess wrote:
However, my way also allows track() to be called an arbitrary number of times before connecting the slot. How would multiple tracked objects be handled with a track(p).connect()/.connect_to() syntax?
I suppose track() would return a reference to the slot_type, so that you could do: signal_type::slot_type( f, p1.get(), p2.get() ).track( p1 ).track( p2 ).connect_to(...);
If you allow track to take varying numbers of arguments, it requires the user to know how many tracked objects there will be at compile time. Being able to call track() multiple times only requires knowing the number of tracked objects at run time, which might be handy if the tracked objects are being collected in a container. I suppose you could overload track to accept a container argument.
Also, support for the first alternative could be easily implemented using the second, since whatever object is returned by signal::track() will have both a reference to the signal and the slot in its connect() function.
Another question is if both alternatives should be provided, or if tracking should only work when you create a slot_type object explicitly. 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). Regards Timmo Stange