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