[Interest] What's the recommended way to put QObjects in smart pointers?

[André Somers]

Op 05/05/2016 om 13:20 schreef Nye:
> On Thu, May 5, 2016 at 4:22 AM, Nikos Chantziaras <realnc at gmail.com 
> <mailto:realnc at gmail.com>> wrote:
>
>     On 05/05/16 01:44, Nye wrote:
>
>         No one said it does. Perhaps I'm misunderstanding, are you
>         searching for
>         a silver bullet for memory management?
>
>
>     I already found it. Question is how to make Qt work with it :-)
>
>
> You most certainly have not. I'm tired of repeating this, but here I 
> go again: C++ IS NOT JAVA!
>
>
>          > That's not good enough. I need to delete objects way before
>         their
>         parent is deleted.
>
>         So delete them. As I said, parent is notified of the child's
>         deletion.
>
>
>     If I delete them, the parent may already have deleted them. So I'd
>     have a double-delete.
>
>
> We are running in a circle here. If the parent may delete the children 
> before you've lost all the references to them, then use QPointer.
>
>          > When 'parent' gets deleted before 'dialog', then 'dialog' gets
>         deleted even though it's on the stack.
>
>         And how does the parent gets deleted before the 'dialog' if I
>         may ask,
>         unless you're doing deletions from different threads ...?
>
>
>     I don't know. There's long call chains. Someone may delete the
>     parent. There's no way to know.
>
>
> The whole premise behind Mr. Sommers' code was that this is in one 
> function (one stack frame), so unless you do `delete this` in the 
> middle of the function (directly or indirectly) there doesn't seem be 
> a way the parent gets deleted.
Well, that's not quite true of course. If you want to show a dialog 
created on the stack, you will have to use it's exec() method. That 
spins an event loop, and that means that a lot can happen in the mean 
time. It can vary from an incoming DBUS messages causing the application 
to terminate to something in response to a signal from that dialog 
itself, to some timer triggering a series of events that lead to the 
destruction of the parent.

So, in that sense, Nikos is right.

I prefer just dealing with that using... new and ::open instead.

André

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20160505/8d0f9265/attachment.html>