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é
Hi André
That's out of the dilemma that we want both a machine readable notation for
parented pointers and following the C++ core guideline. I have no strong
opinion here, I just want to give an advice how the QParentedPointer is
meant to use (like I have used it in the past)
What is clear for me is the normal borrowing case:
voidOther::doSomethingWithThePointer(QObject* pObject); // does not not store
And the weak reference case:
voidOther::setPointerForLater(QPointer<QObject*> pObject); // allow to store,
use after null check
What I have read in this thread is that we don't want to change this
recommendation and see QParentedPointer everywhere.
But where to borrow from? We don't have access to the original owned pointer
inside the QObject. We can useQObject::children() to borrow all at once. Or
as the usual practice make a second copy of the pointer in the inherited Object
where we can "borrow" the already borrowed child pointer (Not recommended by
the C++ Core Guidelines). Here comes the super-power of QParentedPointer in.
classParent::QObject {
...
QParentedPointer<Child> m_child; // <- It is allowed to store without QPointer,
because its a reference to the pointer we own anyway.
Child* m_child; // this is ambiguous, because it can be a legacy owned object
or a not allowed storage of a borrowed pointer. (don't use)
}
..
m_child = makeChildObject<Child>();
..
m_other->doSomethingWithThePointer(m_child);
Conclusion, we have no use case for copy a second QParentedPointer<Child> from
m_child or move m_child out of Parent
.
Does that make sense?
Best regards,
Daniel
--
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
