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

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2007-02-23 16:19:34

On Friday 23 February 2007 14:23 pm, Peter Dimov wrote:
>
> signal.track( p ).connect( bind( f, p.get() ) );
>
> or, with some bind syntactic sugar added:
>
> signal.track( p ).connect( f, p.get() );
>
> The slot-based formulation could look like:
>
> signal_type::slot_type( bind( f, p.get() ) ).track( p ).connect_to(
> signal );
>
> or
>
> signal_type::slot_type( f, p.get() ).track( p ).connect_to( signal );
>
> Both seem passable, the first alternative looks a bit more natural. The
> second has the advantage of potentially producing a reusable slot class
> that can operate without a signal (if we get its interface right).

Ah, now were getting some convergence.  I prefer the second, because it is 
nearly what I'm promoting, except you've moved the signal/connect to the 
end, where I would have done:

signal.connect(signal_type::slot_type( f, p.get() ).track( p ));

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?  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.

-- 
Frank