Qt Memory management mechanism

This article was first published on my homepage http://www.devbean.info, and will be published directly there. Now there is a Flex 4 and "from C + + to Objective-c" series, thank you for your support!

Strongly typed languages always explicitly or implicitly contain type information for objects when they are created. That is, a strongly typed language is always associated with the type of the object when it allocates the object memory space. In contrast, weakly typed languages do not do so. After allocating memory space, there are two ways to free up space: by hand, or by using the garbage collector. C + + requires developers to manually free up memory space. The advantage of this is that the developer has complete control of the interior and knows when the release is appropriate. Java uses the garbage collector. It will have a thread in the background to constantly see which objects are not being used and can be recycled based on certain algorithms. This frees the developer from the underlying implementation and focuses on the business logic.

This article focuses on QT memory management, which uses the QT mechanism to implement a simple garbage collector.

C + + memory management mechanism

C + + requires developers to manage their own memory. There are three types of strategies:

1. Let the created object delete its own sub-object (the sub-object referred to here refers to the object's properties, not the subclass, similar to the following);
2. Let the last object handle the delete;
3. Regardless of memory.

The last one is usually a "memory leak" and is considered a bug. So now we are going to choose which of the previous two is more appropriate. Sometimes, delete creates an object that is much simpler than all its child objects, and sometimes finding the last object can be quite difficult.

Qt Memory management mechanism

Qt can maintain the hierarchy of objects internally. For visual elements, this hierarchy is the child component's relationship to the parent component, and for non-visual elements, it is the dependency of one object to another. In Qt, deleting a parent object deletes its child objects together. This helps reduce memory problems by 90%, creating a mechanism similar to garbage collection.

Qpointer

Qpointer is a template class. It is similar to a normal pointer, except that Qpointer can monitor dynamically allocated objects and update them when the object is deleted.

2. Qpointer behaves like a normal pointer
4. Qdate *mydate = new Qdate (Qdate::currentdate ());
6. Qpointer mypointer = MyData;
8. Mydate->year (); ///2005
10. Mypointer->year (); ///2005
14. Qpointer will behave differently when the object is delete
16. Delete mydate;
20. if (mydate = = NULL)
22. printf ("clean pointer");
24. Else
26. printf ("dangling pointer");
28. Output dangling pointer
32. if (Mypointer.isnull ())
34. printf ("clean pointer");
36. Else
38. printf ("dangling pointer");
40. Output clean pointer

Note the above code. After a raw pointer delete, its value is not set to NULL, and therefore becomes a wild pointer. However, Qpionter does not have this problem.

Qobjectcleanuphandler

The Qt object Cleaner is an important part of implementing automatic garbage collection. It can register many sub-objects and automatically delete all child objects when they are deleted. At the same time, it can also identify if a child object has been deleted, thereby removing it from its list of child objects. This class can be used for cleanup of classes that are not in the same hierarchy, for example, when a button is pressed to close many windows, because the window's parent property is not likely to be set to a button in another window, this class can be quite handy when used.

2. Create an instance
4. Qobjectcleanuphandler *cleaner = new Qobjectcleanuphandler;
6. Create window
8. Qpushbutton *w = new Qpushbutton ("Remove Me");
10. W->show ();
12. Register the first button
14. Cleaner->add (w);
16. If the first button is clicked, delete itself
18. Connect (w, SIGNAL (clicked ()), W, SLOT (Deletelater ()));
20. Create a second button, note that this button does not have any action
22. w = new Qpushbutton ("nothing");
24. Cleaner->add (w);
26. W->show ();
28. Create a third button to delete all
30. w = new Qpushbutton ("Remove All");
32. Cleaner->add (w);
34. Connect (w, SIGNAL (clicked ()), cleaner, SLOT (Deletelater ()));
36. W->show ();

In the code above, three windows with only one button are created. When the first button is clicked, it will delete itself (through the Deletelater () slot), at which point the cleaner automatically clears it from its own list. When the third button is clicked, The Cleaner is deleted, which removes all windows that are not closed at the same time.

Qt Garbage Collection

As objects become more complex, it is difficult to decide when to make a delete operation when this object is used in many places. Fortunately, Qt has a good garbage collection mechanism for all classes that inherit from Qobject. There are many ways to implement garbage collection, the simplest is the reference count, and the other is to save all objects. We will explain these two implementations in detail below.

Reference count

The application count is the simplest garbage collection implementation: Each object is created, the counter is incremented by 1, minus 1 for each deletion.

2. Class Countedobject
4. {
6. Public
8. Countedobject ()
10. {
12. ctr=0;
14. }
18. void Attach ()
20. {
22. ctr++;
24. }
28. void Detach ()
30. {
32. ctr--;
34. if (Ctr <= 0)
36. Delete this ;
38. }
40. Private
42. Int Ctr;
44. };

Each child object should call the Attach () function after it is created, and the counter will be incremented by 1, and the detach () update counter should be called when it is deleted. However, this class is primitive and does not use Qt's convenient mechanism. Below we give a Qt version of the implementation:

2. Class Countedobject: Public qobject
4. {
6. Q_object
8. Public
10. Countedobject ()
12. {
14. ctr=0;
16. }
20. void Attach (Qobject *obj)
22. {
24. ctr++;
26. Connect (obj, SIGNAL (destroyed (qobject*)), SLOT (Detach ()));
28. }
32. Public Slots:
34. void Detach ()
36. {
38. ctr--;
40. if (Ctr <= 0)
42. Delete this ;
44. }
48. Private
50. Int Ctr;
52. };

We use Qt's signal slot mechanism to automatically reduce the value of the counter when the object is destroyed. However, our implementation does not prevent the object from being created by calling two times attach ().

Record owner

A more appropriate implementation is not only to remember that several objects hold references, but also to remember which objects are. For example:

2. Class Countedobject: Public qobject
4. {
6. Public
8. Countedobject ()
10. {
12. }
16. void Attach (Qobject *obj)
18. {
20. //Check owner
22. if (obj = = 0)
24. return;
26. //Check whether you have added
28. if (owners.contains (obj))
30. return;
32. //Registration
34. Owners.append (obj);
36. Connect (obj, SIGNAL (destroyed (qobject*)), SLOT (Detach (qobject*)));
38. }
42. Public Slots:
44. void Detach (Qobject *obj)
46. {
48. //Delete
50. Owners.removeall (obj);
52. //If the last object is also deleted, delete itself
54. if (owners.size () = = 0)
56. Delete this ;
58. }
62. Private
64. Qlist owners;
66. };

Now our implementation has been able to prevent one object from calling Attach () and detach () multiple times. However, another problem is that we cannot guarantee that the object will call the Attach () function for registration. After all, this is not a C + + built-in mechanism. One solution is to redefine the new operator (this implementation is also complex, but avoids the case where an object does not call attach () registration).

This article is from Devbean ' s world:http://www.devbean.info.
Please indicate the original source of the article when reprinted: Http://www.devbean.info/2011/03/qt_memory_management/.

http://devbean.blog.51cto.com/448512/526734

Qt Memory management mechanism