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

Subject: Re: [boost] Interest in non-intrusive signal/slot lib?
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2015-05-12 05:51:07

On Tue, May 12, 2015 at 1:34 AM, Dominique Devienne <ddevienne_at_[hidden]>
wrote:

> On Tue, May 12, 2015 at 4:25 AM, Emil Dotchevski <emildotchevski_at_[hidden]
> >
> 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