qt:heap_versus_stack
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
qt:heap_versus_stack [2010/12/08 18:55] – mithat | qt:heap_versus_stack [2010/12/08 22:17] – [Long answer] mithat | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== Heap or Stack? ====== | ====== Heap or Stack? ====== | ||
+ | Should Qt objects be created on the heap or on the stack? | ||
+ | |||
+ | ===== 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' | ||
+ | |||
+ | ===== 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). | 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., '' | 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., '' | ||
- | |||
- | ===== Requirements ===== | ||
For this to work, there are two requirements: | For this to work, there are two requirements: | ||
- | - All child objects must be created on the heap; however, | + | - All child objects must be created on the heap; however, |
- Child objects must explicitly be made children of their parents (i.e., they must be // | - Child objects must explicitly be made children of their parents (i.e., they must be // | ||
Line 14: | Line 20: | ||
<code cpp-qt> | <code cpp-qt> | ||
QObjectSubclass theParent; | QObjectSubclass theParent; | ||
- | + | AnotherQObjectSubclass *foo; // pointer to a child | |
- | AnotherQObjectSubclass *foo; | + | foo = new AnotherQObjectSubclass( "bar", & |
- | foo = new AnotherQObjectSubclass( "foo", & | + | |
</ | </ | ||
===== Automatic Management with Layout Managers ===== | ===== Automatic Management with Layout Managers ===== | ||
- | When widgets are added to [[layout managers]], they are automatically reparented to FIXME (the layout manager' | + | When widgets are added to [[layout managers]], they are automatically reparented to FIXME (the layout manager' |
<code cpp-qt> | <code cpp-qt> | ||
Line 29: | Line 34: | ||
</ | </ | ||
- | 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? |
qt/heap_versus_stack.txt · Last modified: 2010/12/08 22:59 by mithat