Qt – Why can’t I set a QObject parent in a class of which QObject is only an indirect base

parent-childqobjectqt

I have a class BatchItem that inherits QObject, plus several classes that inherit from BatchItem:

#ifndef BATCHITEM_H
#define BATCHITEM_H

#include <QObject>

class BatchItem : public QObject
{
    Q_OBJECT
public:
    virtual void start() = 0;
    virtual void stop() = 0;

signals:
    /* ... some signals ... */

};

#endif // BATCHITEM_H

Example of a class that inherits from BatchItem:

#ifndef VIDEOBATCHITEM_H
#define VIDEOBATCHITEM_H

#include "batchprocessing/batchitem.h"

#include <QtCore/QObject>

class VideoBatchItem : public BatchItem
{
    Q_OBJECT
public:
    explicit VideoBatchItem(/* ... */, QObject *parent = 0);

    void start();
    void stop();

private:
    /* ... some private member variables ... */
};

#endif // VIDEOBATCHITEM_H

And this is the corresponding .cpp:

#include "videobatchitem.h"

VideoBatchItem::VideoBatchItem(/* ... */,
                               QObject *parent) :
    /* ... */,
    QObject(parent)
{
    /* ... */
}

/* ... */

But when I try to compile, I get the following error:

error: type ‘QObject’ is not a direct base of ‘VideoBatchItem’

Of course I see that this is correct, as QObject is only an indirect base of VideoBatchItem. But why is that a problem?
Isn't that also the case for e.g. QAbstractScrollArea, which inherits from QFrame, which in turn inherits from QWidget? They all take a QWidget as their parent, although QAbstractScrollArea only indirectly inherits from QWidget.
Unfortunately I couldn't find an answer to that in neither the documentation nor the .cpp files of the named widget classes.

Since I cannot pass a QObject parent, is there still a way to use Qt's parent-child system for the destruction of my derived batch items?

Best Answer

You can't call QObject base constructor. It doesn't matter about type of parent parameter but call of QObject(QObject * parent). You should call in this case BatchItem() without parameter and call setParent(parent) in constructor body, or overload BatchItem(QObject *) constructor.

Related Solutions

C++ – When should Q_OBJECT be used

You should use the Q_OBJECT macro for any non-templated classes that derive from QObject.

Besides signals and slots, the Q_OBJECT macro provides the meta object information that is associated with given class.

As stated in the documentation:

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.

Suppose we have the following class:

class Class : public QObject {
public:
  Class() {}
};

Without Q_OBJECT, the following metaobject system features (among others) will not work for Class:

qobject_cast<Class>() - due to missing metadata
QObject::tr() - due to missing metadata
slots and invokables first declared in Class, when invoked or looked up by name - none of QMetaObject methods will work for these methods, neither will the Qt 4 connect - due to missing metadata
signals - since moc won't generate their implementations and the code won't compile.

You can omit it, of course, but if you ever use these features, you'll need to remember to put the macro into the class's declaration. This is a rather brittle practice and best avoided. The savings are not worth it. So, don't wait - add the Q_OBJECT macro to every class that derives from QObject as a matter of coding policy.

The Q_OBJECT macro should never be used on classes that don't derive from QObject. To add invokables and properties to such classes, use the Q_GADGET macro instead.

C++ – Repeating Q_DISABLE_COPY in QObject derived classes

The error message that might be printed from attempting to copy the derived class might refer to QObject instead of your code, so the error might appear to be confusing. For example, using Visual Studio 2012 to compile this code

class MyClass : public QObject
{

};

int main(int argc, char *argv[])
{
    Q_INIT_RESOURCE(application);

    MyClass obj1;
    MyClass obj2(obj1);

    QApplication app(argc, argv);
    app.setOrganizationName("QtProject");
    app.setApplicationName("Application Example");
    MainWindow mainWin;
    mainWin.show();
    return app.exec();
}

results in this error (and a bunch of references to QObject).

error: C2248: 'QObject::QObject' : cannot access private member declared in class 'QObject'

Changing MyClass to

class MyClass : public QObject
{
private:
    Q_DISABLE_COPY(MyClass)
public:
    MyClass();
};

results in a much more user friendly group of errors that refer to MyClass, starting with

error: C2248: 'MyClass::MyClass' : cannot access private member declared in class 'MyClass'

I think the second error message is easier to understand for somebody that is new to Qt.

The MyClass definition is also self-documenting if Q_DISABLE_COPY is included in the class definition for anybody reading the code.

Another reason to repeat the definition in derived classes is to protect your code from future bugs if the implementation of QObject is changed to no longer use Q_DISABLE_COPY(). While this is unlikely, by documenting this requirement the Qt developers left themselves a small amount of wiggle room if they ever decide to change QObject.

Best Answer

Related Solutions

C++ – When should Q_OBJECT be used

C++ – Repeating Q_DISABLE_COPY in QObject derived classes

Related Topic