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

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: http://www.revergestudios.com/boost-synapse/.
>>>
>>
>> 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 
signal.