Re: [Boost-users] [signals] thread-safe post-disconnect() cleanup

From: Timmo Stange (ts_at_[hidden])
Date: 2007-02-24 10:10:51

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