Dynamical objects (by operator new) in Qt

[wysota]

I do create actions as children of this.

Children and members are two distinct things.

But why does deleting them in the MainWindow destructor not cause a memory fault?

Why would it?

If the action instances were in fact first-class children of the MainWindow instance, shouldn't they have already been deleted by the QObject system before it gets to my destructor?

Think what is the order of destructor calls when using C++ inheritance.

And by "member variable" I meant that the member variable is a QAction *, not QAction.

Here a pointer to an object is a member variable, not the object itself. You can have 10 pointers pointing to the same object and all these can be member variables of different objects. The pointed object doesn't have to be a member variable of any object.

[d_stranz]

Pardon me for using imprecise terminology. I have a bit more than 20 years of C++ experience, and I understand the differences between heap and stack allocated objects, and how pointers and references work. I do remember the order in which destructors are called but if you write semantically correct code it doesn't usually matter.

And IMO, a "member variable" can be a value that is stack-allocated during construction, a reference assigned during construction, or a pointer to a heap-allocated instance created and assigned at any time during the lifetime of an object instance. You imply that it is only the first type. If so, then what do you call a pointer variable that is defined as a member of a class if not a "member variable"?

Nomenclature aside, if I create a pointer to a QObject type using another QObject instance as its parent, store that pointer in a pointer member variable of that class, then delete that pointer in my class destructor, why doesn't that cause a memory fault? Creating that pointer and setting my class instance as its parent presumably stored it away somewhere in Qt's object hierarchy system with a flag that says, "when this parent goes out of scope, delete this child, too". So, if I delete it first, then that leaves a dangling pointer which should cause a memory fault when Qt tries to delete it later. Why not? Is the QObject constructor written in such a way that deleting a QObject instance also removes it from any parent-child relationship it might be in?

If this is true, then is there ever a case in Qt where a call to delete is required, except at the very top of a heap-allocated object hierarchy?

[spherrra]

For example: Qt 4.7 Examles and Demos, OpenGL, Hello GL Example

There are two classes GLWidget and Window. I cite the file window.cpp

Window::Window()
 {
     glWidget = new GLWidget;

Window::Window()
 {
     glWidget = new GLWidget;

To copy to clipboard, switch view to plain text mode 

The object "glWidget" is dynamical. But it is not the object-child of object of the Window. I must so writte

Window::Window()
 {
     glWidget = new GLWidget(this);

Window::Window()
 {
     glWidget = new GLWidget(this);

To copy to clipboard, switch view to plain text mode 

or writte destructor

Window::~Window()
 {
   delete glWidget;

Window::~Window()
 {
   delete glWidget;

To copy to clipboard, switch view to plain text mode 

But it's not in this example. Why?

[d_stranz]

For example: Qt 4.7 Examles and Demos, OpenGL, Hello GL Example

But it's not in this example. Why?

Look at these lines:

QHBoxLayout *mainLayout = new QHBoxLayout;
     mainLayout->addWidget(glWidget);
 
// ...
 
     setLayout(mainLayout);

QHBoxLayout *mainLayout = new QHBoxLayout;
     mainLayout->addWidget(glWidget);

// ...

     setLayout(mainLayout);

To copy to clipboard, switch view to plain text mode 

This first line creates a QHBoxLayout. The second line assigns it as the parent of glWidget. The third line assigns Window as the parent of mainLayout. So, mainLayout is owned by Window, and glWidget is owned by mainLayout. Each of these children will be deleted automatically when Window goes out of scope.

[spherrra]

Ok. Thank you! I understood this. Спасибо

[wysota]

And IMO, a "member variable" can be a value that is stack-allocated during construction, a reference assigned during construction, or a pointer to a heap-allocated instance created and assigned at any time during the lifetime of an object instance. You imply that it is only the first type. If so, then what do you call a pointer variable that is defined as a member of a class if not a "member variable"?

I didn't say anything like that. I said the pointer is a member variable and not the object it points to. If you have "int *x" then the variable which is a memeber of the object that contains it is "x" and not "*x".

Nomenclature aside, if I create a pointer to a QObject type using another QObject instance as its parent, store that pointer in a pointer member variable of that class, then delete that pointer in my class destructor, why doesn't that cause a memory fault?

Because QObject destructor is called after your destructor and the object you delete has time to detach itself from its parent and thus is not deleted again when the parent is deleted. The code is equivalent to:

QObject::~QObject() { qDeleteAll(children); setParent(0); }
void QObject::setParent(QObject *newParent) {
  if(parent()) parent()->children().remove(this); // of course ignoring that children() returns a copy
  m_parent = newParent;
  if(m_parent) m_parent->children().append(this); // of course ignoring that children() returns a copy
}

QObject::~QObject() { qDeleteAll(children); setParent(0); }
void QObject::setParent(QObject *newParent) {
  if(parent()) parent()->children().remove(this); // of course ignoring that children() returns a copy
  m_parent = newParent;
  if(m_parent) m_parent->children().append(this); // of course ignoring that children() returns a copy
}

To copy to clipboard, switch view to plain text mode 

If this is true, then is there ever a case in Qt where a call to delete is required, except at the very top of a heap-allocated object hierarchy?

A call to delete is only required if a QObject-derived (and heap allocated) object has no parent (and is not assigned to some kind of smart pointer). I usually have 0 QObject-related "delete" calls in my programs

Oh... one more thing. Never create QObjects with a parent on the stack (unless they are modal QDialogs which is usually safe). Then you can have double deletions (the behaviour is compiler-dependent).

---

Added after 8 minutes:

This first line creates a QHBoxLayout. The second line assigns it as the parent of glWidget. The third line assigns Window as the parent of mainLayout. So, mainLayout is owned by Window, and glWidget is owned by mainLayout. Each of these children will be deleted automatically when Window goes out of scope.

To be exact:

#include <QtGui>
 
int main(int argc, char **argv){
  QApplication app(argc, argv);
  QWidget *w = new QWidget;
  QHBoxLayout *l = new QHBoxLayout;
  l->addWidget(w);
  qDebug() << ( w->parent() ? w->parent()->metaObject()->className() : "no parent");
  QDialog dlg;
  dlg.setLayout(l);
  qDebug() << ( w->parent() ? w->parent()->metaObject()->className() : "no parent");
  qDebug() << ( l->parent() ? l->parent()->metaObject()->className() : "no parent");
  return 0;
}

#include <QtGui>

int main(int argc, char **argv){
  QApplication app(argc, argv);
  QWidget *w = new QWidget;
  QHBoxLayout *l = new QHBoxLayout;
  l->addWidget(w);
  qDebug() << ( w->parent() ? w->parent()->metaObject()->className() : "no parent");
  QDialog dlg;
  dlg.setLayout(l);
  qDebug() << ( w->parent() ? w->parent()->metaObject()->className() : "no parent");
  qDebug() << ( l->parent() ? l->parent()->metaObject()->className() : "no parent");
  return 0;
}

To copy to clipboard, switch view to plain text mode 

yields:

no parent
QDialog
QDialog

The child widget is reparented to the widget and not to the layout.

[d_stranz]

QObject::~QObject() { qDeleteAll(children); setParent(0); }
void QObject::setParent(QObject *newParent) {
if(parent()) parent()->children().remove(this); // of course ignoring that children() returns a copy
m_parent = newParent;
if(m_parent) m_parent->children().append(this); // of course ignoring that children() returns a copy
}

QObject::~QObject() { qDeleteAll(children); setParent(0); }
void QObject::setParent(QObject *newParent) {
if(parent()) parent()->children().remove(this); // of course ignoring that children() returns a copy
m_parent = newParent;
if(m_parent) m_parent->children().append(this); // of course ignoring that children() returns a copy
}

To copy to clipboard, switch view to plain text mode 

OK, thanks. This is exactly what I was referring to when I asked if deleting a child removed it from its parent's list of children. So my "extra" deletes do no harm (but don't do much good, either). Away with them!

The child widget is reparented to the widget and not to the layout.

Ok, I had known that also, but was trying to keep the explanation more simple.

[wysota]

Ok, I had known that also, but was trying to keep the explanation more simple.

Sure, but in two years from now somebody would put the following post right under yours:

Hi d_stranz, so glad I have found this forum!

I'm a newbie in Qt and a newbie in C++. I have written the following code:

int main(...) {
  QHBoxLayout *l = new QHBoxLayout;
  QWidget *w = new QWidget;
  l->addWidget(w);
  delete l;
}

int main(...) {
  QHBoxLayout *l = new QHBoxLayout;
  QWidget *w = new QWidget;
  l->addWidget(w);
  delete l;
}

To copy to clipboard, switch view to plain text mode 

According to what you have said when "l" is deleted, it should delete "w" but it doesn't! I'm using Qt 5.2.7. Is this a bug in Qt? Should I report it to <whoever owns Qt in two years>?

[d_stranz]

Point taken.

<whoever owns Qt in two years>

That'll be either Google or Microsoft. (or maybe Oracle... no, Ellison couldn't be that greedy).

[wysota]

Or /dev/null. Certainly not Oracle.