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

Subject: Re: [boost] Interest in non-intrusive signal/slot lib?
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2015-05-17 22:40:33

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 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.

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.