[Development] parented_ptr

[Ville Voutilainen]

On Fri, 31 Oct 2025 at 12:28, André Somers via Development
<development at qt-project.org> 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.