Inside qt Series (12): Parent-child relationship between Qt objects

A common mistake many C + + beginners make is to allocate a chunk of memory with malloc, new, and forget to release, causing a memory leak. The QT object model provides a parent-child relationship between Qt objects, and when many objects are set up in a certain order, the parent-child relationship is organized into a tree. When you delete a parent object, the QT object model mechanism ensures that all of its child objects, as well as the grandchild object, and so on, are automatically set, so that no memory leaks occur.

Everything has a positive and negative effect, this mechanism looks good, but it will cause a lot of QT beginners, I often answer the question is: After 1,new a Qt object, under what circumstances should delete it. The destructor for 2,QT is not a bug. 3, why normal delete a Qt object will produce segment fault. And so on and so forth, this article is a detailed explanation of the problem.

In each Qt object, there is a linked list that holds pointers to all of its child objects. When a new Qt object is created, if another QT object is specified as the parent of the object, the parent object will include a pointer to the child object in its list of child objects. Also, for any Qt object, its parent can be reset through the SetParent function at any time during its life cycle. When a parent object is deleted, it automatically deletes all of its child objects. When a sub-object is deleted, it removes itself from the list of child objects of its parent object.

Qwidget is the base class for all interface objects that appear on the screen, extending the parent-child relationship of the Qt object. A Widget object also naturally becomes a child widget of its parent widget object and is displayed in the coordinate system of its parent widget. For example, a button on a dialog (dialog) should be a child Widget of this dialog box.

For new and delete of Qt objects, let's illustrate the following.

For example, the following piece of code is correct: int main () {qobject* objparent = new Qobject (NULL);   qobject* objchild = new Qobject (objparent);   qobject* objChild2 = new Qobject (objparent); Delete objparent; Copy the Code

We use a graph to describe the relationship between the three objects:

If we change the above code to this, it is also correct: int main () {qobject* objparent = new Qobject (NULL);   qobject* objchild = new Qobject (objparent);   qobject* objChild2 = new Qobject (objparent);   Delete Objchild; Delete objparent; Copy the Code

In this code, we just look at something different from the previous piece of code, that is, delete the Objchild object before the delete Objparent object. When deleting a Objchild object, the Objchild object automatically removes itself from the Objparent object's list of child objects, that is, after the Objchild object is deleted, the Objparent object has only one child object ( OBJCHILD2). Then, when the Delete Objparent object, the ObjChild2 object is automatically also delete. So, this code is also safe. This design of the

Qt is unfriendly to some debugging tools, such as Valgrind. For example, in the above code, the Valgrind tool, when parsing the code, will assume that the ObjChild2 object has not been deleted correctly, and will report that there is a memory leak in the code. Haha, we know that the report is wrong.

We are looking at this piece of code: int main () {  qwidget window;   qpushbutton quit ("Exit", &window), and copy code /p>

In this code, we created two widget objects, the first one is window, the second is quit, they are QT objects, because Qpushbutton is derived from Qwidget, and Qwidget is derived from Qobject. The relationship between the two objects is that the Window object is the parent of the Quit object, and since they are all allocated on the stack, the Quit object is not destroyed two times. We know that variables declared inside a function body are destroyed when the function exits, so in this Code, window and quit two objects will be called when the function exits the destructor. So, suppose that if the destructor of the window is called first, it will delete the Quit object, and then the quit destructor is called again, and the program goes wrong. The fact that this is not the case, the C + + standard stipulates that the destructors for local objects are called in the reverse order of their construction order. So in this code, this is that the destructor of the Quit object must be called before the destructor of the Window object, so when the Window object is destroyed, the Quit object is no longer present and will not be refactored two times.

If we change the code to look like this, it will make a mistake, compare the previous explanation, please analyze it yourself.   int main () {Qpushbutton quit ("Exit");   Qwidget window; Quit.setparent (&window); Copy the Code

But when we write the program ourselves, we must also pay attention to one item, do not delete the sub-object two times, as in the previous code, the program must be crash.

====================================
Declaration: The
Inside qt Series column is the original technical article of the QT Core Technology Forum (insideqt.com).
This series of articles may be reproduced at will, but must retain the original address of this paragraph and each article.
The author retains copyright and may not use it for any commercial purpose without the author's consent

Inside Qt Series Column Total index:
Http://www.insideqt.com/bbs/viewthread.php?tid =9
Original Address of this article:
http://www.insideqt.com/bbs/viewthread.php?tid=72

Previous: emit, behind the scenes
Http://www.insideqt.com/bbs/viewthread.php?tid=55
Next: qt/e Architecture Overview
/HTTP/ www.insideqt.com/bbs/viewthread.php?tid=113
====================================