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

On Tue, May 12, 2015 at 1:34 AM, Dominique Devienne wrote:

On Tue, May 12, 2015 at 4:25 AM, Emil Dotchevski

...

wrote:

...

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

Interesting. Thanks for sharing.

One thing that surprised me in the example is that you store the QPushButton in a shared_ptr, which from shared_ptr point-of-view has sole ownership, while also setting the QDialog as the parent of that button.

http://doc.qt.io/qt-4.8/qwidget.html#QWidget states "The new widget is deleted when its parent is deleted". The shared_ptr goes out of scope before the QDialog, so obviously Qt has a way to avoid the double-delete (I suspect via its internal/intrusive tracking of children), but the other way around (longer lifetime for the shared_ptr) would crash, no?

Yes, if you delete a child it unregisters from the parent and that's fine. If the parent is deleted before the shared_ptr to the child that would be a double delete, but in the example that doesn't happen.

And the shared_ptr seems to be required by the API?

Yes it is, however shared_ptr is quite flexible, e.g. you can use it with null_deleter if needed, etc. Also, Qt sends signals before it deletes an object, which can be used to at least detect the double delete.

Also the fact that you must static_cast from a void* to get back the QPushButton is a little disturbing, when the single type itself never "said" in its signature the emitter has to be a QPushButton. Wouldn't such casting also be fraught with dangers in case of multiple or virtual inheritance? Thanks, --DD

Yes, one has to be careful with casting. I'm wondering if it's worth storing in the connection object the type of the emitter, which can be captured at the time connect is called, if available. Thanks for the feedback! Emil