20.3.1. Globals, static, and QObject

20.3.1. Globals, `static`, and QObject
	20.3. Storage Class

20.3.1. Globals, `static`, and QObject

[ fromfile: globals.xml id: globals ]

There are two reasons generally used to justify giving an object global scope.

It needs a lifetime that is the same as the application.
It needs to be accessible from several different places in the application.

In C++, you should avoid the use of global scope as much as possible and instead use other mechanisms. However, you can still use global scope identifiers for the following:

Class names
Namespace names
The global pointer qApp, which points to the running QApplication object.

By turning a global object into a static class member, or a namespace member, you can avoid increasing the size of the global namespace while keeping the object accessible to several source code modules.

static and QObject

When creating QObject or other interesting classes^[117], it is important that their destructors do not get called after qApp (the singleton QApplication) has been destroyed (i.e., after main() is finished).

static QObjects (and other complex objects), that continue to exist after qApp has been destroyed, could have cleanup-code problems. This is because when it is destroyed, qApp takes a lot of other objects with it.

In general, you need to have control over the order of destruction of all complex objects. One way to ensure this is to make sure that each QObject allocated on the stack (or on the heap) is a child/grandchild/etc of a QObject that is already on the stack.

The QApplication (or its derived instance) is the "rootiest" stack object of them all, so you should try to make it the "last QObject standing." This makes qApp a good choice for "ultimate ancestor" of any orphan QObject in an application.

^[117]By "interesting" we mean any class with a destructor that has some important cleaning up to do.