Objektbäume & Eigentumsverhältnisse

Übersicht

QObjects organisieren sich in Objektbäumen. Wenn Sie eine „ QObject “ mit einem anderen Objekt als übergeordnetem Element erstellen, wird sie zur Liste „ children()“ des übergeordneten Elements hinzugefügt und gelöscht, sobald dieses gelöscht wird. Es hat sich herausgestellt, dass dieser Ansatz sehr gut zu den Anforderungen von GUI-Objekten passt. Beispielsweise ist ein „ QShortcut “ (Tastenkürzel) ein untergeordnetes Objekt des entsprechenden Fensters; wenn der Benutzer dieses Fenster schließt, wird das Tastenkürzel ebenfalls gelöscht.

QQuickItemDas „Item“ (Element), das grundlegende visuelle Element des Moduls „ Qt Quick “, erbt von „ QObject “, hat jedoch ein Konzept des visuellen Elternelements, das sich von dem des „QObject “-Elternelements unterscheidet. Das visuelle Elternelement eines Elements muss nicht unbedingt mit seinem Objekt-Elternelement übereinstimmen. Weitere Details finden Sie unter „Concepts – Visual Parent“ in Qt Quick.

QWidget, die Basisklasse des Moduls „ Qt Widgets “, erweitert die Eltern-Kind-Beziehung. Ein Kind wird normalerweise auch zu einem untergeordneten Widget, d. h., es wird im Koordinatensystem seines Elternelements angezeigt und grafisch durch dessen Grenzen beschnitten. Wenn die Anwendung beispielsweise ein Meldungsfeld löscht, nachdem es geschlossen wurde, werden auch die Schaltflächen und die Beschriftung des Meldungsfelds gelöscht – genau wie gewünscht –, da die Schaltflächen und die Beschriftung Kinder des Meldungsfelds sind.

Sie können untergeordnete Objekte auch selbst löschen; diese werden dann aus ihren übergeordneten Objekten entfernt. Wenn der Benutzer beispielsweise eine Symbolleiste entfernt, kann dies dazu führen, dass die Anwendung eines ihrer „ QToolBar “-Objekte löscht; in diesem Fall würde das übergeordnete „ QMainWindow “-Objekt der Symbolleiste die Änderung erkennen und seinen Bildschirmbereich entsprechend neu konfigurieren.

Die Debugging-Funktionen „ QObject::dumpObjectTree()“ und „ QObject::dumpObjectInfo()“ sind oft hilfreich, wenn sich eine Anwendung seltsam verhält oder anzeigt.

Erstellungs-/Zerstörungsreihenfolge von QObjects

Wenn QObjects auf dem Heap erstellt werden (d. h. mit `new`), kann aus ihnen in beliebiger Reihenfolge ein Baum aufgebaut werden, und später können die Objekte in diesem Baum in beliebiger Reihenfolge zerstört werden. Wird ein „ QObject “ im Baum gelöscht und hat das Objekt ein übergeordnetes Objekt, entfernt der Destruktor das Objekt automatisch aus dessen übergeordneten Objekt. Hat das Objekt untergeordnete Objekte, löscht der Destruktor automatisch jedes untergeordnete Objekt. Kein „ QObject “ wird zweimal gelöscht, unabhängig von der Reihenfolge der Zerstörung.

Wenn „ QObjects “ auf dem Stack angelegt werden, gilt dasselbe Verhalten. Normalerweise stellt die Reihenfolge der Zerstörung nach wie vor kein Problem dar. Betrachten Sie den folgenden Codeausschnitt:

int main()
{
    QWidget window;
    QPushButton quit("Quit", &window);
    //...
}

Das übergeordnete Objekt, window, und das untergeordnete Objekt, quit, sind beide „ QObjects “, da QPushButton von QWidget erbt und QWidget von QObject erbt. Dieser Code ist korrekt: Der Destruktor von quit wird nicht zweimal aufgerufen, da der C++-Sprachstandard (ISO/IEC 14882:2003) vorschreibt, dass Destruktoren lokaler Objekte in umgekehrter Reihenfolge ihrer Konstruktoren aufgerufen werden. Daher wird der Destruktor des untergeordneten Objekts, ` quit`, zuerst aufgerufen und entfernt sich selbst aus seinem übergeordneten Objekt, ` window`, bevor der Destruktor von ` window ` aufgerufen wird.

Betrachten wir nun aber, was passiert, wenn wir die Reihenfolge der Erstellung vertauschen, wie in diesem zweiten Codeausschnitt gezeigt:

int main()
{
    QPushButton quit("Quit");
    QWidget window;

    quit.setParent(&window);
    //...
}

In diesem Fall verursacht die Reihenfolge der Zerstörung ein Problem. Der Destruktor des Elternelements wird zuerst aufgerufen, da er zuletzt erstellt wurde. Er ruft dann den Destruktor seines untergeordneten Elements quit auf, was falsch ist, da quit eine lokale Variable ist. Wenn quit anschließend den Gültigkeitsbereich verlässt, wird sein Destruktor erneut aufgerufen – diesmal korrekt –, aber der Schaden ist bereits angerichtet.