[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Not used QPointers showing modal dialogs via exec() - No crash
From:       Thomas_Lübking <thomas.luebking () gmail ! com>
Date:       2013-11-11 19:14:54
Message-ID: 3f6e3694-ee20-4ce1-a074-c7a497b2e897 () gmail ! com
[Download RAW message or body]

On Montag, 11. November 2013 19:42:13 CEST, Kevin Krammer wrote:

> If anything, D-Bus, timer, whatever, causes deletion of the 
> dialog's parent, 
> in this case KMinesMainWindow, then it will delete its child QObject.

If a QObject with children on the stack gets deleted, you're in trouble \
anyway, see the big fat warning in the QObject API about this.

> When the C++ code of the functions cleans up the stack, it will 
> at least also 
> invoke the dialog's destructor.

This however would bite you if the deconstructor attempts to operate on the \
deleted parent()


Long story short:
-----------------
if you cannot ressonably assume -or even better: guarantee- that the \
environment is gonna survive the nested eventloop:

a) create the object with nested loop on the heap and assign it a qpointer
b) check whether the nested pointer is NULL after the nested loop has quit
c) if you need to perform more stuff on "this" after the nested loop has \
exited, assign a qpointer to "this" before entering the loop and check it \
afterwards as well (for odds are good that "this" has gone as well) d) \
actually better guard any ("toplevel") pointers that you intend to access \
after a nested event loop.

Alternatively under this (unsafe state) condition, just don't use a nested \
eventloop.

Cheers,
Thomas

> > Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to \
> > unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]