The Meta-Object System

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:

1. The https:// class provides a base class for objects that can take advantage of the meta-object system.

2. The https:// macro inside the private section of the class declaration is used to enable meta-object features, such as dynamic properties, signals, and slots.

3. The https:// (moc) supplies each QObject subclass with the necessary code to implement meta-object features.

The moc tool reads a C++ source file. If it finds one or more class declarations that contain the https:// 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 https:// mechanism for communication between objects (the main reason for introducing the system), the meta-object code provides the following additional features:

• https://() returns the associated https:// for the class.

• https://() returns the class name as a string at run-time, without requiring native run-time type information (RTTI) support through the C++ compiler.

• https://() function returns whether an object is an instance of a class that inherits a specified class within the https:// inheritance tree.

• https://() translates strings for internationalization.

• https://() and https://() dynamically set and get properties by name.

• https://() constructs a new instance of the class.

It is also possible to perform dynamic casts using https://() on https:// classes. The https://() 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 nullptr if the object's type is incompatible.

For example, let's assume MyWidget inherits from QWidget and is declared with the https:// macro:

    QObject *obj = new MyWidget;

The obj variable, of type QObject *, actually refers to a MyWidget object, so we can cast it appropriately:

    QWidget *widget = qobject_cast<QWidget *>(obj);

The cast from https:// to 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 *myWidget = qobject_cast<MyWidget *>(obj);

The cast to MyWidget is successful because https://() makes no distinction between built-in Qt types and custom types.

    QLabel *label = qobject_cast<QLabel *>(obj);
    // label is 0

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 = qobject_cast<QLabel *>(obj)) {
        label->setText(tr("Ping"));
    } else if (QPushButton *button = qobject_cast<QPushButton *>(obj)) {
        button->setText(tr("Pong!"));
    }

While it is possible to use https:// as a base class without the https:// macro and without meta-object code, neither signals and slots nor the other features described here will be available if the https:// macro is not used. From the meta-object system's point of view, a https:// subclass without meta code is equivalent to its closest ancestor with meta-object code. This means for example, that https://() will not return the actual name of your class, but the class name of this ancestor.

Therefore, we strongly recommend that all subclasses of https:// use the https:// macro regardless of whether or not they actually use signals, slots, and properties.

See Also▲