The Meta-Object System#
An overview of Qt’s meta-object system and introspection capabilities.
Qt’s meta-object system provides the signals and slots mechanism for inter-object communication, run-time type information, and the dynamic property system.
The meta-object system is based on three things:
QObjectclass provides a base class for objects that can take advantage of the meta-object system.
Q_OBJECTmacro inside the private section of the class declaration is used to enable meta-object features, such as dynamic properties, signals, and slots.
The Meta-Object Compiler (
moc) supplies each
QObjectsubclass with the necessary code to implement meta-object features.
moc tool reads a C++ source file. If it finds one or more class declarations that contain the
Q_OBJECT macro, it produces another C++ source file which contains the meta-object code for each of those classes. This generated source file is either
#include'd into the class’s source file or, more usually, compiled and linked with the class’s implementation.
In addition to providing the signals and slots mechanism for communication between objects (the main reason for introducing the system), the meta-object code provides the following additional features:
metaObject()returns the associated
meta-objectfor the class.
className()returns the class name as a string at run-time, without requiring native run-time type information (RTTI) support through the C++ compiler.
inherits()function returns whether an object is an instance of a class that inherits a specified class within the
tr()translates strings for internationalization.
property()dynamically set and get properties by name.
newInstance()constructs a new instance of the class.
It is also possible to perform dynamic casts using
QObject classes. The
qobject_cast() function behaves similarly to the standard C++
dynamic_cast(), with the advantages that it doesn’t require RTTI support and it works across dynamic library boundaries. It attempts to cast its argument to the pointer type specified in angle-brackets, returning a non-zero pointer if the object is of the correct type (determined at run-time), or
None if the object’s type is incompatible.
For example, let’s assume
MyWidget inherits from
QWidget and is declared with the
obj = MyWidget()
obj variable, of type
QObject *, actually refers to a
MyWidget object, so we can cast it appropriately:
widget = QWidget(obj)
The cast from
QWidget is successful, because the object is actually a
MyWidget, which is a subclass of
QWidget . Since we know that
obj is a
MyWidget, we can also cast it to
myWidget = MyWidget(obj)
The cast to
MyWidget is successful because
qobject_cast() makes no distinction between built-in Qt types and custom types.
label = QLabel(obj)
The cast to
QLabel , on the other hand, fails. The pointer is then set to 0. This makes it possible to handle objects of different types differently at run-time, based on the type:
if QLabel label = QLabel(obj):
While it is possible to use
QObject as a base class without the
Q_OBJECT macro and without meta-object code, neither signals and slots nor the other features described here will be available if the
Q_OBJECT macro is not used. From the meta-object system’s point of view, a
QObject subclass without meta code is equivalent to its closest ancestor with meta-object code. This means for example, that
className() will not return the actual name of your class, but the class name of this ancestor.
Therefore, we strongly recommend that all subclasses of
QObject use the
Q_OBJECT macro regardless of whether or not they actually use signals, slots, and properties.