Boost logo

Boost :

Subject: Re: [boost] Interest in non-intrusive signal/slot lib?
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-05-16 14:50:39

On 5/16/2015 2:20 PM, Emil Dotchevski wrote:
> On Sat, May 16, 2015 at 7:09 AM, Edward Diener <eldiener_at_[hidden]>
> wrote:
>> On 5/11/2015 10:25 PM, Emil Dotchevski wrote:
>>> 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:
>> The documentation says that a signal emitter is a void pointer. Doesn't it
>> need to be a shared_ptr<void> instead, since it must be passed to emit as a
>> weak_pointer ? You might clarify this in the documentation. Instead of:
> emit<> takes a void pointer, emit_weak<> takes a weak pointer. I have
> updated the documentation, I believe the new introduction and the simple
> example it presents are much more understandable now, thanks to the initial
> feedback I'm getting.

I will take a look.

>> I assume that the purpose of having the signal type be a pointer to a
>> function taking some data and returning an incomplete type instead of
>> returning void is to make each signal type unique. But is this really
>> necessary ?
> It is necessary so that if you have:
> typedef struct button_down_(*button_down)(int x, int y);
> you can tell it apart from
> typedef struct button_up_(*button_up)(int x, int y);

I understand that the types are different but when would you ever use
that knowledge in code ? The signal handler knows nothing about the type
of the signal except that it's signature matches the parameters of the

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