[Development] parented_ptr

[Daniel Schürmann]

> Hi Marc and others

> Just never create a child QObject w/o the final parent, and everything
will be peachy.

This is one of the drivers for initiative we can enforce with
“makeChildObject()” and no  longer encouraged “new Object(this)”.

> Every function that transfers ownership as a raw pointer is worth being
replaced by one taking/returning by unique_ptr. Let the API enforce
ownership transfer instead of letting the reader of the code guess.

I agree. So we should encourage to use pParent->addChild(std::move(pChild))
instead of pChild->setParent(pParent)

> I wouldn't even assert in the destructor. That will fire already when
these things are held as member functions in the "wrong" order.

I am as well against an ASSERT that may crashes the productive build for a
semantical reason. What is the best pattern for Qt?
How about issue a qWarning during the QParentedPointer *constructor* like
we have in QObject::~QObject()? I have good experience with this.

So, let me summarize the latest discussion, to verify if I got it right:


We will introduce:

1: Child* QObject::makeChildObject()

with some template magic to automatically set the parent pointer and a
static_assert for pParent == this otherwise


2: QParentedPointer<Child>

with a non-fatal warning or similar if the parent is null. Disallow copy
and move, because for the borrowing case we want to use raw pointer or
QPointer in line with the C++ core guideline.


3: QObject::addChild(std::unique_ptr<QObject *> child)

Will this have a chance to being merged upstream?

Best regards,

Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20251030/f034e6e8/attachment.htm>