Hi,
On 30-10-2025 18:20, Daniel Schürmann wrote:
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:
... in separate contributions...
1: Child* QObject::makeChildObject()
with some template magic to automatically set the parent pointer and a
static_assert for pParent == this otherwise
You would not need much magic, but sure. I can see a use case for this one.
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.
Wait... Disallow copy and move? I don't get what the point is then. You
say for the "borrowing case" we want raw pointers (fair enough), but
QParentedPointer itself already _is_ borrowed by definition, no? It is
conceptually owned by the parent the pointer is explicitly advertising
is set. What's the point of this thing if it's not copyable? It would
make their use very limited indeed, perhaps just used as private members
of a class containing some sub items or as temporary variables in a
function that sets up a dialog or something those lines.
Could you explain more clearly why this thing cannot be copyable or movable?
3: QObject::addChild(std::unique_ptr<QObject *> child)
...
Cheers,
André
--
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
