Frank Mori Hess wrote:
Ah, I see. Couldn't you achieve the same thing by deriving some_observer from the slot class? Then the some_observer constructor could call slot::track() to set up its own tracking.
The target function class would need to know the signal's slot_type for that, which is not really the same situation we have with implicit tracking. It would work though. I'm actually undecided here. I don't really like providing both al- ternatives, because it makes the interface confusing, as I've stated earlier. I now see that using the implicit tracking alone will lead to syntactically obscure constructs with the non-trivial cases (tracking of not directly related objects). The explicit tracking solves that and also removes a lot of behind-the-scenes magic. If the latter becomes the only solution, I'd prefer it being applicable on connections, too, though. The explicit construction of slots is otherwise seldom necessary and I wasn't aware it is at all possible before I started working on signals. We should also keep in mind what the tracking will be used for mostly. I think this is in order of importance: 1. tracking of objects for member function slots 2. tracking of parameters directly 3. tracking of signals as slots 4. tracking of indirectly related objects If that is close to reality, shifting to explicit tracking is a major change. Cases 1 and 2 are handled quite well with the implicit tracking. Case 3 involves some acrobatics in the implementation and case 4 leads to an obscure syntax. On the other hand, all cases will result in two or more statements with explicit tracking. I find it difficult to favor one or the other here. Regards Timmo Stange