QObject-inherited classes' virtual destructor method

[JonB]

When you create a QObject-based class (e.g. a QWidget-derived class) in Creator it puts in an empty virtual destructor method for you, like:

MyWidget::~MyWidget() {}

I know I would need this if I add e.g. my own member variables (without QObject-parentage) which need destructing. So it may be a nice convenience for the user. Personally I like "if I don't need/use it, I don't define it", so I have one less thing to scroll through.

AFAICS, I get no ill effects if I delete the empty destructor and my class does not have one. Is that right? So long as I don't actually have anything inside it is there any reason why it should nonetheless be defined for e.g. QObject-inherited classes?

[Christian Ehrlicher]

@JonB said in QObject-inherited classes' virtual destructor method:

it is there any reason why it should nonetheless be defined for e.g. QObject-inherited classes?

No, it's imo just added as a convenience as you normally want to clean things up in the dtor.

Whether or not one ought type in override on a virtual destructor I agree is moot

The Qt coding guide imo says it's useless to add 'override' here and therefore not allowed.

[J.Hilk]

I would consider it bad practice. At its core every from QObject derived class has a virtual destructor.
So MyWidget::~MyWidget() {} overrides a destructor, but the macro clearly doesn't mark it as override.

[JonB]

@J-Hilk
Hi. Whether or not one ought type in override on a virtual destructor I agree is moot, but to be clear that is not my question at all. My question is: do you need/ought you define any ~MyWidget() destructor (with or without virtual and/or override) which is going to have an empty body ({})? I know it does no harm, and might be useful as a placeholder/reminder if you are going to add any code into it. But if you are not, and it's going to be empty, is there any good reason in C++ or for a QObject-derived class that you really should have it?

[Christian Ehrlicher]

@JonB said in QObject-inherited classes' virtual destructor method:

it is there any reason why it should nonetheless be defined for e.g. QObject-inherited classes?

No, it's imo just added as a convenience as you normally want to clean things up in the dtor.

Whether or not one ought type in override on a virtual destructor I agree is moot

The Qt coding guide imo says it's useless to add 'override' here and therefore not allowed.

[J.Hilk]

@JonB its probably there to delete the UI-pointer when you decide to create a class with .ui designer extension

[TomZ]

The destructor gets added by the compiler if you don't have it there as text. Much like an empty constructor on a struct or class.

It will be there in the compiled result, but I agree it makes no sense for Creator to have that there.

I do notice that if I inherit QObject, the wizard in QtCreator doesn't create any destructor.
Maybe at some point the qwidget template had something in the destructor ?
I haven't worked with widgets for a long time, not sure.

[J.Hilk]

@TomZ

like I said, it's there in case you select a designer form class in the add new option:

#ifndef TESTFORM_H
#define TESTFORM_H

#include <QWidget>

namespace Ui {
class TestForm;
}

class TestForm : public QWidget
{
    Q_OBJECT

public:
    explicit TestForm(QWidget *parent = nullptr);
    ~TestForm();

protected:
    void changeEvent(QEvent *e);

private:
    Ui::TestForm *ui;
};

#endif // TESTFORM_H

TestForm::TestForm(QWidget *parent)
    : QWidget(parent)
    , ui(new Ui::TestForm)
{
    ui->setupUi(this);
}

TestForm::~TestForm()
{
    delete ui;
}

void TestForm::changeEvent(QEvent *e)
{
    QWidget::changeEvent(e);
    switch (e->type()) {
    case QEvent::LanguageChange:
        ui->retranslateUi(this);
        break;
    default:
        break;
    }
}

[JonB]

@J-Hilk
Yes, as you say, it comes from UI app. I often pick the UI template for a test project so I get the QApplication and necessary Makefile/cmake stuff but then uncheck the "create .ui file" box as I don't want that and create widgets in code. Which leaves me with the empty destructor code. I am now happy that I don't need that unless I want it.