Subject: Re: [boost] first steps to submitting - boost :: observers
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2016-09-19 01:15:44
On Sun, Sep 18, 2016 at 3:53 PM, Robert McInnis <r_mcinnis_at_[hidden]>
wrote:
> 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