There's a widget declaration order to follow?

Question

Is there a order to declare widgets in Qt5(perhaps 4 too) ?

Consider the following pieces of code:

(just the a piece of the header to help me explain)

class ConfigDialog : public QDialog
{
    Q_OBJECT

    QGroupBox userAuthBox;
    QGridLayout userAuthLayout;
    QVBoxLayout dialogLayout;

    QLabel userLabel;
    QLabel passLabel;
    QLineEdit userEdit;
    QLineEdit passEdit;
};

this works as expected but just changing to (reordering declarations):

class ConfigDialog : public QDialog
{
    Q_OBJECT

    QLabel userLabel;
    QLabel passLabel;
    QLineEdit userEdit;
    QLineEdit passEdit;
    QGroupBox userAuthBox;
    QGridLayout userAuthLayout;
    QVBoxLayout dialogLayout;
};

this works also, but when the ConfigDialog goes out of scope happen a segfault.

I've saw this on other scenarios too, but always changing the order fix this.

Answer 1

My guess would be: you make your QGroupBox a parent of some of the other widgets.

Qt has a concept of parent-child relationship between QObjects. The parent is responsible for deleting its children when it itself is destroyed; it is assumed that those children were allocated on the heap with new.

Further, data members of a C++ class are constructed in the order they are listed in the class, and are destroyed in the reverse order.

Let's say userAuthBox is made a parent of userLabel (via setParent call, in your case executed by addWidget). In the first case, userLabel is destroyed first, and notifies its parent of this fact, whereupon userAuthBox removes it from its list of child widgets, and doesn't attempt to delete it.

In the second case, userAuthBox is destroyed first, and uses delete on its pointer to userLabel. But of course userLabel was not in fact allocated with new. The program then exhibits undefined behavior.

Answer 2

TL;DR: Yes! The order of declarations has a strictly defined meaning in C++. A random order will not work, as you've happened to notice.

You're not showing all the code. What is important is that one of the widgets is a child of the group box. Suppose you had:

class ConfigDialog : public QDialog
{
  // WRONG
  Q_OBJECT
  QLabel userLabel;
  QGroupBox userAuthBox;
  QGridLayout userAuthLayout;
  QVBoxLayout dialogLayout;
public:
  ConfigDialog(QWidget * parent = 0) :
    QDialog(parent),
    dialogLayout(this),
    userAuthLayout(&userAuthBox) {
    // Here userLabel is parent-less.
    Q_ASSERT(! userLabel.parent());
    userAuthLayout.addWidget(&userLabel, 0, 0);
    // But here userLabel is a child of userAuthBox
    Q_ASSERT(userLabel.parent() == &userAuthBox);
  }
};

The default destructor will invoke the destructors in the following order - it literally is as if you wrote the following valid C++ code in the destructor.

1. dialogLayout.~QVBoxLayout() - OK. At this point, the dialog is simply layout-less. All the child widgets remain.
2. userAuthLayout.~QGridLayout() - OK. At this point, the group box is simply layout-less. All the child widgets remain.

3. userAuthBox.~QGroupBox() - oops. Since userLabel is a child of this object, the nested userAuthox.~QObject call will execute the eqivalent of the following line:

   delete &userLabel;
   

   Since userLabel was never allocated using new, you get undefined behavior and, in your case, a crash.

Instead, you should:

1. Declare child widgets and QObjects after their parents.

2. Use C++11 value initialization if possible, or initializer lists in the constructor to indicate to the maintainer that there is a dependency between the children and the parents.

See this answer for details and a C++11 and C++98 solution that will force the mistakes to be caught by all popular modern static C++ code analyzers. Use them if you can.