DO NOT delete QObjects, mmmkay?

[Aaron J. Seigo]

On Thursday 08 November 2007, Diego Iastrubni wrote:
> Yes, but be warned, that signal is emitted *after* the QObject has been
> deleted. So, if you want to retrieve something out a "soon to be
> deleted" object, it will not help you as the parameter sent is a
> dangling pointer.

it's actually emitted *during* deletion. so the subclass, if any, is 
unavailable, but the QObject itself is still there .. not that i'd recommend 
relying on any specifics about its state of being. 

and the children of it aren't deleted until after the signal. so .. you can 
still access the children...

though what you suggest, treating it as if it is a dangling pointer, is 
usually the best idea indeed. usually i use this signal to get notified when 
an object actually goes away so that i'm not concerned about having to delete 
it in a known order; for collection management type classes i find a common 
pattern is for deleteLater() and destroyed() to be used in tandem.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20071108/5c8399a9/attachment.sig>