Subject: Re: [boost] Interest in non-intrusive signal/slot lib?
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-05-20 18:00:24
On 5/20/2015 11:32 AM, Peter Dimov wrote:
> Edward Diener wrote:
>> This is similar to the way in the signals2 library that one has to
>> have access to a boost::signals2::signal in order to setup a
>> connection to a slot. So while I like your library I do not
>> immediately understand the advantage it has over signals2.
> When you already have an existing third-party object (say, XButton) it's
> more convenient to not have to think where to place the corresponding
> signal object. Non-intrusive dispatch is kind of like the library
> containing the equivalent of map<void*, signal>, automatically managing
> the signal objects corresponding to an external, third-party, object.
I understand that with Synapse you are merely making a call at a
convenient point in order to emit a signal, whereas with signals2 you
need to have a boost::signals2::signal object somewhere for the
particular signal triggering before you can emit a signal or have
connections to handle the signal. But in Synapse you also must have a
signal emitter which is accesible for the event handlers making the
connection to the event. This to me is equivalent to boost::signals2
having a signal object.
> 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 ?
In both cases whatever is emitting the signal has to be accessible. I do
understand that conceptually in Synapse have the signal emission be
disconnected from the signal connection appears a less dependent design
but this seems to me to be only on the surface.
This does not mean I do not like Synapse. Its syntax for emitting a
signal from any object is clearer than signals2, but under the surface
the separation between the signal and signal handler seems much the same.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk