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 19:40:52

On Mon, May 18, 2015 at 2:34 PM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> wrote:

> Le 12/05/15 04:25, Emil Dotchevski a écrit :
>
>  Hello,
>>
>> I realize that Boost has Signals library already, but I've implemented a
>> non-intrusive one which approaches the problem differently, and I'm pretty
>> sure that there is no overlap between the two. It turned out more generic
>> than I originally anticipated, so I thought I'd ask if others would find
>> it
>> useful as well.
>>
>> Specifically I was motivated by wanting to use Qt without MOCing. I asked
>> the Qt community if that was possible which generated several rather
>> annoyed negative responses. :) The issue is that while in Qt it's possible
>> to use any function as a Slot, to define a new Qt signal for an existing
>> Qt
>> type one needs to derive from the Qt type, define the signal (as a member
>> function) and do the MOC dance -- which I wanted to avoid.
>>
>> The result is a small, non-intrusive signals/slots library that allows
>> objects of any type to be used as signal emitters, e.g. one of the
>> included
>> examples shows how signals can be emitted by a Windows HWND object.
>>
>> Documentation and source code released under the Boost license can be
>> found
>> here: http://www.revergestudios.com/boost-synapse/.
>>
>>
>>
> 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 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.

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

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

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

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