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

Subject: Re: [boost] Interest in non-intrusive signal/slot lib?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-05-20 02:21:11

Le 19/05/15 01:40, Emil Dotchevski a écrit :
> On Mon, May 18, 2015 at 2:34 PM, Vicente J. Botet Escriba <
> vicente.botet_at_[hidden]> wrote:
>
>> Hi,
>>
>> as others I was surprised with the design, in particular the signal
>> declaration form
>>
>> typedef struct report_progress_(*report_progress)( int );
>>
>>
>> What is wrong with the usual way
>>
>> struct report_progress = signal<void(int)>;
>>
>> If you want to make two signals with the same signature two different
>> signal types you could provide something like
>>
>> struct report_progress : signal<report_progress, void(int)> {};
>>
>> The fist parameter would be the signal name.
>>
> This is definitely possible but I think a simple function pointer typedef
> is better because in that case you can define Synapse signals without
> having to include any headers, reducing physical coupling.
I understand, but I suspect that the the server or the application would 
need to use an include for your library, isn't it?.
>
>
>> I find weird also the emmiter name. In my opinion you are disguising in
>> this emitter parameter the signal instance instead of the signal sender. I
>> don't believe the signal sender is interesting enough in synchronous signal
>> programming as it is with asynchronous one (as asynchronous has often
>> associated agents that send and receive signals).
>>
> It's unconventional, yes, but the ability to emit a signal from any object
> whatsoever (including 3rd-party objects) is what makes it possible to use
> Synapse in situations where other similar libraries would be very difficult
> or impossible to use.
Please, could you elaborate. How having signal instances forbids the use 
of 3pp objects?
>
>
>> BTW, I don't see how the signal handler can retrieve the emitter (e.g. to
>> disconnect from).
>
> In synapse the only way to disconnect a signal is to destroy the connection
> object you receive from connect<>, although emit<> won't call functions if
> the corresponding emitter has expired even if the connection object is
> still afloat.
Ok, I see for disconnect.
>
>> This mean that the user would need to have two different signal handlers
>> to manage two different emitters (two different instances). What is the
>> rationale to don't providing this information on the to the signal handler.
>>
> You can bind whatever you want and pass it to the signal handler.
I see. It would be good to see an example of how your library handles 
this signal sender pattern.
>
>
>> What is the advantage of your design respect to working with signals
>> instances?
>> What am I missing?
>>
> See the example on the main page (
> http://revergestudios.com/boost-synapse/index.html) and
> http://revergestudios.com/boost-synapse/using_Boost_Synapse_to_handle_events_from_an_OS_message_pump.html
> and possibly
> http://revergestudios.com/boost-synapse/questions_and_answers.html.
These links give me differences not the advantages. Could you be more 
precise? Could you show how things are done with each library and the 
associated performances? What can not be done with Boost.Signal2 that 
can be done with your library?

Vicente
>