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

On Mon, May 18, 2015 at 4:22 PM, Gavin Lambert wrote:

On 19/05/2015 09:36, Edward Diener wrote:

...

On 5/18/2015 1:39 PM, Emil Dotchevski wrote:

...

On Mon, May 18, 2015 at 8:42 AM, Edward Diener wrote:

...

That's not where the confusion existed for me. Gavin Lambert explained why each signal must be a different type. I realized that a signal is a type, but not why the same signal could not be used for more than one event ( button down, button up etc. ).

The signal *is* the event though. So I guess I still don't understand. If you have two events, "button up" and "button down", then you need two Synapse signals or else you wouldn't be able to tell them apart.

Your synapse code evidently needs to tell them apart but from the end-user's perspective it isn't necessary, since the only thing he cares about is the parameter types being specified. If he has a signal of:

typedef void (*button_signal)(int,int) ;

why wouldn't he use it for both a button_up and a button_down event, since it has the correct number and type of parameters for both ?

The key issue is that the list of connected handlers is associated with the type (which I did say before, but evidently not clearly enough).

This means that if you use the same type and the same emitter, it's the same "signal" and it's not possible to differentiate between them -- you can call them "button_down" and "button_up" if you like, but they're just aliases for the same thing and using either of them will result in the same set of handlers being invoked (which is the union of connections made using either name, because again they're just aliases).

If you want separate handler lists (ie. a separate signal) then you have to have a separate type, and that requires that the type be unique in some way. The author chose to use the return value for that purpose.

(The implementation stores all connected handlers in a list indexed by type, and then at emit time calls only the ones with the correct emitter.)

Gavin, you got it and explained it very well, thank you. -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode