On Sun, May 17, 2015 at 7:40 PM, Gavin Lambert
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
(e,&handle_button_down); auto c2=connect (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