On Mon, Dec 5, 2016 at 9:31 AM, Nat Goodspeed
I think what confused me about the Synapse documentation was the use of the term "emitter," which suggests a locally-stored signal instance.
I suppose that makes sense to a Signals2 user because in its design the signal object does the emitting, but the term "emitter" would make perfect sense to people who have experience with other signal programming libraries, for example Qt. I added a new documentation page in an attempt to clarify and highlight the differences in design between Synapse and Signals2, since it seems like many readers wonder what I might think is wrong with Signals2 (the answer is nothing, it's just different): http://zajo.github.io/boost-synapse/Comparison_between_Boost_Signals2_and_Sy... .
In one of our applications, we use an "event" framework in which senders and receivers are loosely coupled. Any given sender and receiver can communicate, regardless of the relative order in which they are constructed, by consulting a central map with find-or-create semantics. They need only agree on the map key. In other words, I believe that application has use cases of the kind that Synapse intends to address.
Yes, it is possible to use Signals2 in a specific case like this, to achieve what Synapse does in the general case non-intrusively (any object whatsoever can be passed as an emitter to emit<>). With Synapse, that central map would be replaced by emit<S>(e), where "e" would be the address of either the "sender" or the "receiver", or even of some other object known to both -- whichever makes sense to use as the Synapse emitter.
(But the connection need only be made once for each receiver -- the search isn't performed all over again on every event. I expect the same is true for proper use of Synapse.)
Nope, Synapse must do the search every time emit is called, though it is limited only to connections of the specified signal type (in Synapse, signals are types). That is the price of it being non-intrusive, however do note that the search can be done in O(1) using hashing.
So for me the term "rendezvous point" makes more sense than "emitter."
To me the Synapse library looks like this:
* front-end API based on a central map of rendezvous points * back-end implementation of rendezvous points that essentially duplicates Boost.Signals2, with some features omitted (as in the critiques earlier in this thread)
Our map's mapped_type is (a thin class wrapped around) boost::signals2::signal. So while I understand the value of having a central map of rendezvous points, I do not understand why you would use anything other than Boost.Signals2 on the back end.
Please see my response to Klemens Morgenstern. Thanks, Emil