Boost logo

Boost :

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:
> 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 ( and
and possibly

Emil Dotchevski
Reverge Studios, Inc.

Boost list run by bdawes at, gregod at, cpdaniel at, john at