Differences

This shows you the differences between two versions of the page.

--- qt:heap_versus_stack [2010/12/06 20:27] – mithat
+++ qt:heap_versus_stack [2010/12/08 22:59] (current) – mithat
@@ Line 1: / Line 1: @@
 ====== Heap or Stack? ======
-In contrast to many modern programming languages that have garbage collection systems to periodically delete orphaned objects, C++ has no automatic memory management. The traditional approach to managing dynamically allocated storage in C++ is to explicitly delete allocated memory that you no longer require. When you are dealing with large trees of objects, this can become quite tedious and the source of errors (especially memory leaks).
+Should Qt objects be created on the heap or on the stack?((Reminder: the heap is the memory store from which dynamically allocated storage is taken; the stack is used for standard variable storage as well as for passing actual parameters to functions, etc.))
+===== Short answer =====
+If the object is going to be part of a tree of Qt objects (as will be the case for most Qt GUI objects), then it should be created on the heap.
+If the object is not part of a tree or is the root of a tree, then it can be created either on the heap or the stack. It seems to be a tradition (or maybe there's a good technical reason for this) to create the main ''QApplication'' object on the stack. It is also typical to create main windows (tree roots) on the stack so that they do not need to be manually deleted.
+===== Long answer =====
+In contrast to many modern programming languages, C++ has no automatic memory management. The traditional approach to managing dynamically allocated storage in C++ is to explicitly delete allocated memory that you no longer require. When you are dealing with large trees of objects, this can become quite tedious and the source of errors (especially memory leaks).
 Qt tries to make up for this by providing automatic memory management for the objects under its domain. Qt user interfaces are almost always made up of a tree of Qt widgets, which are themselves subclasses of Qt objects (i.e., ''QWidget''s derive from ''QObject''). Qt automates the destruction of such trees: deleting the root of a tree of Qt objects will automatically delete all children of the root as well. So, managing the destruction of a large Qt interface requires only destroying the root object.
 For this to work, there are two requirements:
-  - All child objects must be created on the heap; however, The root itself may be on the stack. (If you need a reminder, the heap is the memory store from which dynamically allocated storage is taken; the stack is used for standard variable storage as well as for passing values to functions, etc.) In other words, objects that you intend to place in the tree must be created dynamically (using ''new''). Often, you will create a pointer as well to point to the newly created child.
+  - All child objects must be created on the heap; however, the root itself may be on the stack. In other words, child objects that you intend to place in the tree must be created dynamically using the ''new'' operator.
   - Child objects must explicitly be made children of their parents (i.e., they must be //reparented//). Constructors for (re)parentable Qt objects let you pass parameters to specify the parent.
@@ Line 12: / Line 20: @@
 <code cpp-qt>
 QObjectSubclass theParent;                              // create theParent on the stack
+AnotherQObjectSubclass *foo;                            // pointer to a child
-AnotherQObjectSubclass *foo;
+foo = new AnotherQObjectSubclass( "bar", &theParent );  // create foo on the heap and reparent to theParent
-foo = new AnotherQObjectSubclass( "foo", &theParent );  // create foo on the heap and reparent to theParent
 </code>
 ===== Automatic Management with Layout Managers =====
-When widgets are added to [[layout managers]], they are automatically reparented to FIXME (the layout manager's parent)|(the layout manager). Therefore, parents are not specified when creating widgets when adding them to layout managers. However, you still must reparent the layout manager.
+When widgets are added to [[layout managers]], they are automatically reparented to the overlying object (typically the layout manager's parent). Therefore, parents are not specified when creating widgets that are added to layout managers. However, you must reparent the layout manager itself.
 <code cpp-qt>
@@ Line 27: / Line 34: @@
 </code>
-FIXME What happens when layout managers are nested? Do the child managers get automatically reparented?
+FIXME What happens when layout managers are nested? Do the child managers get automatically reparented? To whom?