[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]