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-18 17:34:43

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.

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

BTW, I don't see how the signal handler can retrieve the emitter (e.g. 
to disconnect from). 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.

In summary, I find the vocabulary weird, instead saying you have signals 
instances your library works with signal types and an emitter that 
doesn't emits anything and that is used as signal instance identifier.  
I suspect that having to manage with this signal emitter (identifier) 
and a signal type makes the implementation (that I have not yet 
inspected) less efficient, as having an instance don't need any look up, 
isn't it?

What is the advantage of your design respect to working with signals 
instances?
What am I missing?

What are the advantages of your library respect to Boost.Signal2?
Best,
Vicente