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.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…