On Sat, May 16, 2015 at 7:09 AM, Edward Diener
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 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); -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode