On Sun, Sep 18, 2016 at 3:53 PM, Robert McInnis
On Sunday, September 18, 2016 6:50 AM, Bjorn Reese wrote:
What are the advantages of this library over Boost.Signals2 [1]?
Afaik, Signals2 is not meant to be associated with a single instance of a single object representing a particular event produced by that object.
Same question with regards to the Boost.Synapse [2] proposal.
I do not have boost::Synapse in 1.61. I did find it searching the site. Looking through its documentation
Yes, Synapse is not an official Boost library (pending review). Here is a short tutorial:http://zajo.github.io/boost-synapse/Tutorial.html.
it seems to allow for the production of events within the object instance as well as producing numerous types of events, so that would be similar. I am unfamiliar with how it is implemented as the emitter seems to have to match the observer and if done on each trigger, that would be very costly. This also implies there is a large container of signals, indexed by source object ptr.
In Synapse signals are types, the dispatch by signal is done at compile time. The run-time lookup is only within connections of the same type. So, emit<S>(pe), where S is a signal type and 'pe' is a raw pointer, searches only within S connections for a connection to an emitter with address equal to 'pe'. The lookup is necessary because of the non-intrusive nature of Synapse: any object of any type whatsoever can be used as an emitter. Performance is a priority for me, however it is pointless to discuss performance without a practical use case. In my experience the connected user function (the user code that is executed within emit<>(pe) for each connection to the passed emitter 'pe') is usually significantly heavier than the Synapse machinery. Emil