Repeating Q_DISABLE_COPY in QObject derived classe

问题:

In Qt there is a macro that allows declaring private copy constructurs and assignment operators for classes: http://qt-project.org/doc/qt-5.0/qtcore/qobject.html#Q_DISABLE_COPY

It is said that this macro should be used for all QObject (especially QWidget) derived classes.

I understand how this works and why it is useful.

What I do not understand: Is there any reason to repeat Q_DISABLE_COPY in my QObject derived classes while QObject already contains Q_DISABLE_COPY and through this effectively prevents my derived classes from being copied?

回答1:

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.