Qt QObject Parent‑Child Ownership: Safe Memory Management and Thread‑Affinity Gotchas

The following snippet shows a MainWindow that creates a QTimer and passes this as the parent. No explicit delete for the timer is needed.

// mainwindow.cpp
#include 
#include 
class MainWindow : public QMainWindow {
    Q_OBJECT
public:
    explicit MainWindow(QWidget *parent = nullptr)
        : QMainWindow(parent), timer(new QTimer(this)) {
        connect(timer, &QTimer::timeout, this, &MainWindow::onTick);
        timer->start(1000);
    }
private:
    QTimer *timer;
    void onTick() { /* slot implementation */ }
};

When the MainWindow instance is destroyed (e.g., the user closes the window), Qt’s parent‑child mechanism invokes the timer’s destructor automatically. If you run the program under AddressSanitizer or step through with a debugger, you will see the timer’s destructor executed exactly once, with no explicit delete call in your code.

Thread‑affinity caveat

A child inherits the thread affinity of its parent at the moment it is added to the child list. Consequently, if you move the parent to another thread with moveToThread(), all of its children are moved as well. This behavior is useful for GUI objects that must stay in the GUI thread, but it can surprise developers who expect a child to remain in its original thread after reparenting.

Limitation: not thread‑safe for reparenting

The parent‑child bookkeeping structures are not protected by a mutex. Creating a QObject, calling setParent(), or destroying a parent from multiple threads without external synchronization can corrupt the child list, leading to use‑after‑free or double‑delete bugs. To mitigate this risk:

• Perform all construction and reparenting operations on a single thread (usually the GUI thread).
• If you must change ownership from another thread, post a queued invocation (QMetaObject::invokeMethod with Qt::QueuedConnection) to the owner’s thread.
• Guard raw pointers to children with QPointer so they automatically become null when the child is deleted.

Mixing parent‑child ownership with std::unique_ptr or manual delete on the same object will result in a double free; choose one ownership model per object.

Practical verification

To confirm that the mechanism behaves as described, you can:

1. Build a small test program that creates a parent QObject, allocates a child with new Child(&parent), and destroys the parent.
2. Run the executable under AddressSanitizer or Valgrind; the tool should report no memory leaks and no double‑free errors.
3. Add a QPointer to the child, reparent the child to nullptr before destroying the parent, and verify that the pointer becomes null and the parent’s destructor does not attempt to delete the child again.

These steps rely on Qt’s documented behavior and do not require any special version‑specific features; they work with Qt 5.15 LTS and Qt 6.x.

Actionable closing

Use Qt’s parent‑child ownership as the default lifetime strategy for objects that share a clear containment hierarchy. Remember that the child follows the parent’s thread, so keep thread moves confined to the parent’s thread or use queued calls for cross‑thread changes. Protect any external raw pointers with QPointer and avoid mixing this model with manual delete or smart pointers. By following these guidelines you reduce boilerplate, eliminate many memory‑management bugs, and keep your Qt code both safe and readable.