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

From: Timmo Stange (ts_at_[hidden])
Date: 2007-02-26 04:30:36

Frank Mori Hess wrote:

>> A signal would then rather be a handle object, or not? I wouldn't
>> see a problem in this if it were just for the invocation and
>> connection to another signal, but with member functions like
>> connect() and disconnect() it would appear like a rather unusual
>> construct to me.
> 
> It would be like signals::connection, which is a handle object and has a 
> disconnect().

Right, but that's a much clearer concept in my book. The connection
describes a relation between the signal and a slot and nothing concrete
that can live on its own.

Let me try to explain it from a different angle: What good does this
copyable signal handle do? You don't need to track it, because you
have a full copy (that's where the idea originated from). That means
you can still receive notifications after the original object which
you decided to observe has long gone. You can still connect new slots
to the signal to be notified of state changes in that dead entity ;).

I may be missing some important practical use (that's why I asked
about common practice with shared - or perhaps independent - signals),
but at the moment it looks more like a design choice that is based on
implementation considerations to me.

Regards

Timmo Stange