On Wed, May 20, 2015 at 3:00 PM, Edward Diener
In the use case in which you define your buttons, there's not much to
gain, you make them contain your signal objects. But third-party buttons don't contain your signal objects, they contain their own functionality for notifying you of events, sometimes that's (their own) signal implementation, sometimes a callback/std::function, sometimes you need to override a virtual method, sometimes they send you messages. With a non-intrusive signal library, you just attach an emit call to the third-party notification mechanism and the rest of the code can connect to the non-intrusive signal. This avoids the need to wrap the external objects in your own types that contain signal objects.
The rest of the code can connect to the non-intrusive signal as long as it has access to the signal emitter. It is not as if when the signal emitter goes out of scope you can make a connection to that signal anymore. Or have I misunderstood this ?
No, you got that right.
In both cases whatever is emitting the signal has to be accessible.
On the surface that's not a big deal but typically the code that is emitting the signal already has an object that it did something to, or received a notification from. If emitting the signal requires another emitter object then in addition it must have access to that too -- which sometimes is problematic, not just inconvenient. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode