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

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

Peter Dimov wrote:

>> Let me try to explain it from a different angle: What good does this
>> copyable signal handle do?
> 
> Same as all C++ handles; prevent dangling references. C++ handles are the 
> equivalent of Java references. Value semantics are better when they're 
> possible, but if the alternative is noncopyability and raw pointers, I 
> always prefer the handle approach. Not all C++ programmers agree. A 
> construct on which Java is built upon must be evil. :-)

I think there is a much more valid objection: as you state yourself,
it's not a natural C++ language construct. I prefer to give handles a
distinctive name (..._handle, ..._pointer, ..._proxy, etc.) to indi-
cate that this is not the real object with value semantics. In the
future we well thankfully have shared_ptr, which will be well noticed
as what it is by a C++ programmer. I think it would suffice here, too,
*if* we need this.

> That said, in this case I think that the hybrid approach is better than the 
> two other alternatives. 

I would like to get a little bit more concrete here: For what do we
need this? Is the signal really something a client should store
references to? In a case of a real independent signal that is not
owned by a single entity, but shared by several, is a shared_ptr
not the better alternative?

I still only see the signal-to-signal connection as the most probable
case in which a reference to the signal needs to be stored somewhere
and I think such a connection would usually be established by the
signal owner, which makes tracking simple or completely unnecessary
and the binding to the signal (C++-)reference is not a problem at all.

Regards

Timmo Stange