В Qt есть макрос, который позволяет объявлять частные конструкторы копирования и операторы присваивания для классов: http://qt-project.org/doc/qt-5.0/qtcore/qobject.html#Q_DISABLE_COPY
Говорят, что этот макрос следует использовать для всех производных классов QObject (особенно QWidget).
Я понимаю, как это работает и почему это полезно.
Что я не понимаю: есть ли причина повторять Q_DISABLE_COPY в моих производных классах QObject, в то время как QObject уже содержит Q_DISABLE_COPY и благодаря этому эффективно предотвращает копирование моих производных классов?
Сообщение об ошибке, которое может быть напечатано при попытке скопировать производный класс, может ссылаться на QObject вместо вашего кода, поэтому ошибка может показаться запутанной. Например, используя Visual Studio 2012 для компиляции этого кода
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();
}
приводит к этой ошибке (и кучу ссылок на QObject).
ошибка: C2248: ‘QObject :: QObject’: не может получить доступ к приватному члену
объявлен в классе ‘QObject’
Изменение MyClass на
class MyClass : public QObject
{
private:
Q_DISABLE_COPY(MyClass)
public:
MyClass();
};
приводит к гораздо более удобной группе ошибок, относящихся к MyClass, начиная с
ошибка: C2248: «MyClass :: MyClass»: не может получить доступ к приватному члену
объявлен в классе «MyClass»
Я думаю, что второе сообщение об ошибке легче понять кому-то новичку в Qt.
Определение MyClass также самодокументируется, если Q_DISABLE_COPY включен в определение класса для всех, кто читает код.
Еще одна причина повторить определение в производных классах — это защитить ваш код от будущих ошибок, если реализация QObject изменена, чтобы больше не использовать Q_DISABLE_COPY (). Хотя это маловероятно, документируя это требование, разработчики Qt оставили себе немного места для маневра, если они когда-нибудь решат изменить QObject.
Других решений пока нет …