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

On Mon, May 18, 2015 at 2:34 PM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> 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;

If you want to make two signals with the same signature two different signal types you could provide something like

struct report_progress : signal {};

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