8.6. QObject Lifecycle

8.6. QObject Lifecycle
	Chapter 8. QObject, QApplication, Signals, and Slots

[ fromfile: qobject-lifecycle.xml id: qobject-lifecycle ]

This section describes a few best practices for managing the QObject lifecycle.

	No `static` `QObject`s
	It is important to ensure that every QObject you construct is created after the QApplication, and destroyed before the QApplication is destroyed. Objects created in `static` storage are destroyed after `main()` has returned, which is too late. This means you should never define `static` storage-class `QObject`s.^[73]

	Stack or Heap?
	In general, a QObject without a parent should be created on the stack or defined as an subobject of another class. A QObject with a parent should not be on the stack because then it might get deleted twice accidentally. All `QObject`s created on the heap should either have a parent, or be managed somehow by another object.

deleteLater()

	deleteLater()
It is not recommended to `delete` `QObject`s directly. In a program with an event loop, it is better to use `QObject::deleteLater()`. This schedules the object to be destroyed when the application is processing events, for example, if you have called it from a slot, after your current slot returns. This is actually required from slots where you may wish to delete the `sender()` of a signal.^[74]

It is not recommended to delete QObjects directly. In a program with an event loop, it is better to use QObject::deleteLater(). This schedules the object to be destroyed when the application is processing events, for example, if you have called it from a slot, after your current slot returns.

This is actually required from slots where you may wish to delete the sender() of a signal.^[74]

^[73]Storage class is discussed in Section 20.3.

^[74]Example 17.21 has an example of this usage.


8.5.1. Points of Departure		8.7. QTestLib