Arbres d'objets et propriété

Présentation générale

QObjects s’organisent en arborescences d’objets. Lorsque vous créez une QObject dont un autre objet est le parent, elle est ajoutée à la liste children() du parent, et est supprimée lorsque celui-ci l’est. Il s’avère que cette approche répond très bien aux besoins des objets d’interface graphique. Par exemple, un « QShortcut » (raccourci clavier) est un enfant de la fenêtre correspondante ; ainsi, lorsque l’utilisateur ferme cette fenêtre, le raccourci est également supprimé.

QQuickItem, l’élément visuel de base du module Qt Quick, hérite de QObject, mais sa notion de parent visuel diffère de celle du parentQObject . Le parent visuel d’un élément n’est pas nécessairement le même que son parent objet. Pour plus de détails, consultez la section « Concepts - Parent visuel » à l’adresse Qt Quick.

QWidget, la classe fondamentale du module Qt Widgets, étend la relation parent-enfant. Un enfant devient normalement aussi un widget enfant, c'est-à-dire qu'il s'affiche dans le système de coordonnées de son parent et que son affichage est limité graphiquement par les limites de son parent. Par exemple, lorsque l’application supprime une boîte de message après sa fermeture, les boutons et l’étiquette de cette boîte de message sont également supprimés, comme on le souhaite, car les boutons et l’étiquette sont des enfants de la boîte de message.

Vous pouvez également supprimer vous-même des objets enfants ; ceux-ci se détacheront alors de leurs parents. Par exemple, lorsque l’utilisateur supprime une barre d’outils, cela peut entraîner la suppression par l’application de l’un de ses objets ` QToolBar ` ; dans ce cas, le parent ` QMainWindow ` de la barre d’outils détectera le changement et reconfigurera son espace à l’écran en conséquence.

Les fonctions de débogage QObject::dumpObjectTree() et QObject::dumpObjectInfo() s’avèrent souvent utiles lorsqu’une application présente un comportement ou un aspect inhabituel.

Ordre de construction/destruction des QObjects

Lorsque des objets QObjects sont créés sur le tas (c'est-à-dire à l'aide de `new`), il est possible de construire une arborescence à partir de ceux-ci dans n'importe quel ordre, et par la suite, les objets de cette arborescence peuvent être détruits dans n'importe quel ordre. Lorsqu’un QObject de l’arborescence est supprimé, si l’objet possède un parent, le destructeur le retire automatiquement de son parent. Si l’objet possède des enfants, le destructeur supprime automatiquement chacun d’entre eux. Aucun QObject n’est supprimé deux fois, quel que soit l’ordre de destruction.

Lorsque des objets ` QObjects ` sont créés sur la pile, le même comportement s’applique. Normalement, l’ordre de destruction ne pose toujours pas de problème. Prenons l’exemple suivant :

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

Le parent, window, et l’enfant, quit, sont tous deux des objets de type « QObjects », car QPushButton hérite de QWidget, et QWidget hérite de QObject. Ce code est correct : le destructeur de quit n’ est pas appelé deux fois, car la norme du langage C++ (ISO/IEC 14882:2003) spécifie que les destructeurs des objets locaux sont appelés dans l’ordre inverse de celui de leurs constructeurs. Par conséquent, le destructeur de l’enfant, quit, est appelé en premier, et il se supprime de son parent, window, avant que le destructeur de window ne soit appelé.

Mais voyons maintenant ce qui se passe si l'on inverse l'ordre de construction, comme le montre ce deuxième extrait de code :

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

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

Dans ce cas, l’ordre de destruction pose problème. Le destructeur du parent est appelé en premier, car il a été créé en dernier. Il appelle ensuite le destructeur de son enfant, quit, ce qui est incorrect car quit est une variable locale. Lorsque quit sort par la suite de sa portée, son destructeur est appelé à nouveau, cette fois-ci correctement, mais le mal est déjà fait.