On Fri, 31 Oct 2025 at 12:28, André Somers via Development <[email protected]> wrote: > > 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.
It needs no magic. Just splice 'this' at the end of the constructor arguments. For things that aren't memory-managed by a parent, don't use this function. > > 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? I don't get it either. It disturbs reasonable uses where you have a non-widget that refers to parented objects, but is itself copyable/movable. -- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
