[KDE/Mac] crashing Qt through a QObject's dtor

[Ian Wadham]

On 06/01/2015, at 10:35 PM, René J.V. Bertin wrote:

> On Tuesday January 06 2015 11:36:18 René J.V. Bertin wrote:
> 
>> And then the hackers' delight question:
>> Staring at the code at almost 3am this morning it occurred to me that there is nothing wrong per se if QAction::isEnabled() returns false if the d pointer is NULL (an invalid QAction cannot/shouldn't be enabled), so I changed `return d->enabled` to `return d? d->enabled : false;` . Haven't seen the crash occur since ...
> 
> The question here is of course: how wrong is that approach?

Not at all, IMHO.  In my young day it used to be known as "defensive
programming"… :-)

Actually you often see stuff like "if (objectPointer) { objectPointer->doBar(); }"
in KDE and Qt code.  It relieves the program of having to keep track of
whether an object has been constructed yet.  So why not the same at
the other end of the object's life-cycle?

Another point about Qt programming, which sometimes gets
overlooked and introduces bugs, is that QObject's and
QWidget's and C++ inheritors thereof, can be automatically
deleted, in the correct order, if you create them with a "parent"
QObject or QWidget.  This is easy to overlook when there is
concurrency and an object is not descended from QObject
or QWidget, such as a game-engine object that goes on
running after the game's main window.  Been there, done
that… :-)  So have several other KDE Games programmers.

But if this does not apply in your case, please excuse the noise.

Cheers, Ian W.