Re: [boost] Interest in non-intrusive signal/slot lib?

Subject: Re: [boost] Interest in non-intrusive signal/slot lib?
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2015-05-18 00:35:26

On Sun, May 17, 2015 at 7:40 PM, Gavin Lambert <gavinl_at_[hidden]>
wrote:

> On 17/05/2015 09:35, Edward Diener wrote:
>
>> typedef void (*button_down)(int x, int y);
>> typedef void (*button_up)(int x, int y);
>>
>> void handle_button_down( int x, int y );
>> void handle_button_up( int x, int y );
>>
>> auto c1=connect<button_down>(e,&handle_button_down);
>> auto c2=connect<button_up>(e,&handle_button_up);
>>
>> Is there some reason why the above would not work ? The fact that
>> button_down and button_up are the same types above but different types
>> the way synapse is currently designed seems irrelevant. I am enquiring
>> whether there is an internal reason for that.
>>
>
> I had the same confusion at first.  The issue is that there is no "signal
> container" instance within the emitter itself, which is how you'd normally
> distinguish between signals with the same signature.
>
> This library stores all signals centrally in the management object,
> indexed by type, rather than having members of the emitter object (that's
> the "non-intrusive" part).  As a result the types need to be unique as
> they're the only differentiating feature.
>

I now understand where the confusion comes from, too. In Boost Signals 2, a
signal (emitter) is an actual object, and it is the address of that object
that identifies different signals independently from their signature.
Indeed, in Synapse signals are *not* objects, they're types.

> I am curious whether alternate designs have been considered, such as using
> strings to locate signals (as in Gtk) or using arbitrary atoms returned
> from a registration function.
>

The reason why I've settled on using types is that this way the connections
are separated "by signal" at compile time, e.g. adding button_down
connections does not add to the time it takes to emit button_up signals.

> I'm also curious if there are any performance consequences of, say,
> registering a "click" event on hundreds of buttons simultaneously, with
> different actions required for each, since this model will have a single
> list with hundreds of entries to search through on each emit, whereas more
> "traditional" designs will have hundreds of single-entry lists and a much
> more trivial emit.
>

The current implementation uses a single list per signal type, meaning that
if there are multiple emitters emitting the same signal they will
contribute to the time it takes to emit the signal from a specific emitter.
In my experience so far this has never showed up in profiling. It is of
course possible to order by emitter (weak_ptr<void const>::op<) but at this
point this would be premature.

-- 
Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode