|
1 /**************************************************************************** |
|
2 ** |
|
3 ** Copyright (C) 2010 Nokia Corporation and/or its subsidiary(-ies). |
|
4 ** All rights reserved. |
|
5 ** Contact: Nokia Corporation (qt-info@nokia.com) |
|
6 ** |
|
7 ** This file is part of the documentation of the Qt Toolkit. |
|
8 ** |
|
9 ** $QT_BEGIN_LICENSE:LGPL$ |
|
10 ** No Commercial Usage |
|
11 ** This file contains pre-release code and may not be distributed. |
|
12 ** You may use this file in accordance with the terms and conditions |
|
13 ** contained in the Technology Preview License Agreement accompanying |
|
14 ** this package. |
|
15 ** |
|
16 ** GNU Lesser General Public License Usage |
|
17 ** Alternatively, this file may be used under the terms of the GNU Lesser |
|
18 ** General Public License version 2.1 as published by the Free Software |
|
19 ** Foundation and appearing in the file LICENSE.LGPL included in the |
|
20 ** packaging of this file. Please review the following information to |
|
21 ** ensure the GNU Lesser General Public License version 2.1 requirements |
|
22 ** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html. |
|
23 ** |
|
24 ** In addition, as a special exception, Nokia gives you certain additional |
|
25 ** rights. These rights are described in the Nokia Qt LGPL Exception |
|
26 ** version 1.1, included in the file LGPL_EXCEPTION.txt in this package. |
|
27 ** |
|
28 ** If you have questions regarding the use of this file, please contact |
|
29 ** Nokia at qt-info@nokia.com. |
|
30 ** |
|
31 ** |
|
32 ** |
|
33 ** |
|
34 ** |
|
35 ** |
|
36 ** |
|
37 ** |
|
38 ** $QT_END_LICENSE$ |
|
39 ** |
|
40 ****************************************************************************/ |
|
41 |
|
42 /*! |
|
43 \page objecttrees.html |
|
44 \title Object Trees and Object Ownership |
|
45 \brief Information about the parent-child pattern used to describe |
|
46 object ownership in Qt. |
|
47 |
|
48 \section1 Overview |
|
49 |
|
50 \link QObject QObjects\endlink organize themselves in object trees. |
|
51 When you create a QObject with another object as parent, it's added to |
|
52 the parent's \link QObject::children() children() \endlink list, and |
|
53 is deleted when the parent is. It turns out that this approach fits |
|
54 the needs of GUI objects very well. For example, a \l QShortcut |
|
55 (keyboard shortcut) is a child of the relevant window, so when the |
|
56 user closes that window, the shorcut is deleted too. |
|
57 |
|
58 \l QWidget, the base class of everything that appears on the screen, |
|
59 extends the parent-child relationship. A child normally also becomes a |
|
60 child widget, i.e. it is displayed in its parent's coordinate system |
|
61 and is graphically clipped by its parent's boundaries. For example, |
|
62 when the application deletes a message box after it has been |
|
63 closed, the message box's buttons and label are also deleted, just as |
|
64 we'd want, because the buttons and label are children of the message |
|
65 box. |
|
66 |
|
67 You can also delete child objects yourself, and they will remove |
|
68 themselves from their parents. For example, when the user removes a |
|
69 toolbar it may lead to the application deleting one of its \l QToolBar |
|
70 objects, in which case the tool bar's \l QMainWindow parent would |
|
71 detect the change and reconfigure its screen space accordingly. |
|
72 |
|
73 The debugging functions \l QObject::dumpObjectTree() and \l |
|
74 QObject::dumpObjectInfo() are often useful when an application looks or |
|
75 acts strangely. |
|
76 |
|
77 \target note on the order of construction/destruction of QObjects |
|
78 \section1 Construction/Destruction Order of QObjects |
|
79 |
|
80 When \l {QObject} {QObjects} are created on the heap (i.e., created |
|
81 with \e new), a tree can be constructed from them in any order, and |
|
82 later, the objects in the tree can be destroyed in any order. When any |
|
83 QObject in the tree is deleted, if the object has a parent, the |
|
84 destructor automatically removes the object from its parent. If the |
|
85 object has children, the destructor automatically deletes each |
|
86 child. No QObject is deleted twice, regardless of the order of |
|
87 destruction. |
|
88 |
|
89 When \l {QObject} {QObjects} are created on the stack, the same |
|
90 behavior applies. Normally, the order of destruction still doesn't |
|
91 present a problem. Consider the following snippet: |
|
92 |
|
93 \snippet doc/src/snippets/code/doc_src_objecttrees.qdoc 0 |
|
94 |
|
95 The parent, \c window, and the child, \c quit, are both \l {QObject} |
|
96 {QObjects} because QPushButton inherits QWidget, and QWidget inherits |
|
97 QObject. This code is correct: the destructor of \c quit is \e not |
|
98 called twice because the C++ language standard \e {(ISO/IEC 14882:2003)} |
|
99 specifies that destructors of local objects are called in the reverse |
|
100 order of their constructors. Therefore, the destructor of |
|
101 the child, \c quit, is called first, and it removes itself from its |
|
102 parent, \c window, before the destructor of \c window is called. |
|
103 |
|
104 But now consider what happens if we swap the order of construction, as |
|
105 shown in this second snippet: |
|
106 |
|
107 \snippet doc/src/snippets/code/doc_src_objecttrees.qdoc 1 |
|
108 |
|
109 In this case, the order of destruction causes a problem. The parent's |
|
110 destructor is called first because it was created last. It then calls |
|
111 the destructor of its child, \c quit, which is incorrect because \c |
|
112 quit is a local variable. When \c quit subsequently goes out of scope, |
|
113 its destructor is called again, this time correctly, but the damage has |
|
114 already been done. |
|
115 */ |