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