Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk