Scope and destruction of parent-child model QObjects

[TauCeti]

Hello,
I have a question about the scope and the destruction of QT Objects and the parent-child model to manage QObject resources:

void ClassA::Method1()
{
   QProgressBar* ProgressBar = new QProgressBar();	
}
void ClassA::Method2()
{
    tableWidget->setItem(0, 0, new QTableWidgetItem(text));
}
void ClassA::Method3()
{
    QStandardItemModel *model = new QStandardItemModel(1, 1,this);
}

It is clear for me, that adding 'this' to the objects like in Method 3 results in:
when ClassA gets deleted, Object will be deleted too.

1. What causes the deletion of a QT class (related to parent/child)?
2. What about Method1 and Method2? Do I have to add a 'this' or
   use delete somewhere?

Generally, is it more safe to rely on 'this' or should a manual 'delete' be used?

3. Is std::unique_ptr or std::shared_ptr compatible with OQbjects?

Thanks for help.

[VRonin]

What causes the deletion of a QT class (related to parent/child)?

The parent keeps a list of its children. Passing a parent pointer to a QObject constructor or calling QObject::setParent makes the children append itself to the list held by the parent. When the parent destructor is run it goes through the list of children and calls delete on them (QObjectPrivate::deleteChildren)

---

What about Method1 and Method2?

Method 1 is a memory leak, method 2 is not because it's explicitly stated in the docs: "The table takes ownership of the item." meaning QTableWidget::setItem adds the item to the list of children of the QTableWidget.

---

Generally, is it more safe to rely on 'this' or should a manual 'delete' be used?

@VRonin said in Interfaces, abstract, concrete classes and QObject:

This is the flowchart I normally follow, it covers 99% of the cases:

• is it a QObject?
  • yes
    • can you give it a parent? (for example moveToThread() prevents the parent-child relationship)
      • yes: use a normal pointer and set the parent
      • no: connect the deleteLater() slot to some signal
  • no
    • can multiple places share ownership of the object or pass ownership from one another? (e.g. in containes)
      • yes: use std::shared_ptr
      • no: use std::unique_ptr

If you need to use the pointer in a function that should not manage ownership but just access (read/write) the object (this covers 90% of use cases) then use a raw pointer argument (use std::unique_ptr::get() or std::shared_ptr::get() to retrieve the raw pointer from smart pointers)

---

Is std::unique_ptr or std::shared_ptr compatible with OQbjects?

They are, there is nothing fancy about smart pointers

[JKSH]

@VRonin said in Scope and destruction of parent-child model QObjects:

What causes the deletion of a QT class (related to parent/child)?

The parent keeps a list of its children. Passing a parent pointer to a QObject constructor or calling QObject::setParent makes the children append itself to the list held by the parent. When the parent destructor is run it goes through the list of children and calls delete on them (QObjectPrivate::deleteChildren)

Additional reading: https://doc.qt.io/qt-5/objecttrees.html

[kshegunov]

@TauCeti said in Scope and destruction of parent-child model QObjects:

Is std::unique_ptr or std::shared_ptr compatible with OQbjects?

@VRonin said in Scope and destruction of parent-child model QObjects:

They are, there is nothing fancy about smart pointers

Using std::shared_ptr (or QSharedPointer for that matter) with QObjects is good if you enjoy pain often and in copious amounts ...