Constant-correctness in C++ is not something that you can practically do half-way. You either do it everywhere and always or you don't do it unless some library you're interfacing with forces your hand. I'm in the former camp, and I think that this is a choice with right and wrong answers. Doing it is right.
As a result I've gotten into the habit of typing
const after method signatures almost without thinking, so that sometimes the linter has to remind me that I'm changing a object's state in a method marked as constant. In doing so I recently stumbled on a oddity of Qt's Designer tool.
There is a difference between having something and knowing where to find it
The interesting thing about the Designer component of Qt Creator is that it generates code of a
separate UI object (which you are expected to
not edit) and a skeleton widget object for you to flesh out. That skeleton includes a
pointer-member to manage the UI object (and of course, Designer generates the requisite c'tor and d'tor behavior to make that safe).
If I use Qt Creator to generate a minimal
QWidget the header file it writes looks like this:
#ifndef FORM_H
#define FORM_H
#include
namespace Ui {
class Form;
}
class Form : public QWidget
{
Q_OBJECT
public:
explicit Form(QWidget *parent = nullptr);
~Form();
private:
Ui::Form *ui;
};
#endif // FORM_H
If I write a method for this class
From::changeSubWidget(QWidget*) const, I won't be able to change the pointer
this->ui, but I
will be able to change the properties of any subwidgets contained in the
UI::Form object at the other end of the pointer..
Of course this has nothing to do with Designer
per se and everything to do with the having a pointer or reference member. More over there are places where this is definitely a feature rather than a bug.
Philosophy
In my personal universe a method of the widget class that changes the UI
should not be marked
const even if the particular implementation you've chosen (or let the designer chose) allows it. Because (a) it's not really sensible (the widget that the user sees on their screen is changing) and (b) it locks you into a group of implementation stratigies (you can't later decide to pull all those UI elements into your class proper, which is admittedly not a big issue in Qt).
