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

From: Timmo Stange (ts_at_[hidden])
Date: 2007-02-23 17:26:02

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