[Development] parented_ptr

[Schimkowitsch Robert]

What about a smart pointer that
- Tracks it's QObject using QPointer internally
- In it's destructor, checks if the object still exists
- If so, checks if the object has a parent
--> It has a parent: Don't delete
--> It has no parent: Delete

It will not know if it's parent is managed likewise, so you could still trick it by assigning a parent that itself is never deleted. But that's a bug in the code handling the parent.

In my experience, parents change mostly at the beginning of the lifetime. So it might be an effective way to prevent leaks if e.g. setting the correct parent does not work due to an error.

Kind regards

Robert

> -----Original Message-----
> From: Development <development-bounces at qt-project.org> On Behalf Of
> Igor Khanin
> Sent: Thursday, 16 October 2025 12:23
> To: development at qt-project.org
> Subject: Re: [Development] parented_ptr
>
> CAUTION: External email. Do not click on links or open attachments unless
> you know the sender and that the content is safe.
>
>
> +1
>
> I'm also not sure that a smart pointer wrapper type brings a lot of value; at
> the very least it is highly disruptive to existing code bases.
> The Core C++ guidelines are clear that smart pointers imply ownership of
> some sort, while naked pointers are non-owning; the various pointers to
> QObjects stored as member variables of other QObject sub-classes are
> indeed non-owning so there is no semantics or convention problem there
> IMO.
>
> But I bit more than that - the promise a smart pointer of this kind can make is
> something along the lines of "as long as I'm in scope, the contained QObject
> pointer will at all times have some other object responsible for freeing it"
> can't really be fulfilled by another class - it can check that at creation, but can't
> prevent a object losing its'
> parent via a `setParent(nullptr)`. Only the QObject class itself can enforce that
> I think.
>
> To that extent, it can indeed be useful to have a `make_child` member
> template, or a free-standing `qMakeParented` function template, or
> something else like that - which can hide the "new" call to avoid the problem
> of having new-s without matching delete-s in the code while setting the
> created object in a mode that ensures it can't become parent-less.
>
> Best,
> Igor
>
> On 16/10/2025 12:42, André Somers via Development wrote:
> > Hi,
> >
> > On 15-10-2025 16:30, Daniel Schürmann wrote:
> >> Hello
> >>
> >> My name is Daniel Schürmann and I am one of the core members in the
> >> Mixxx team. We develop the QT based FOSS DJ software Mixxx.
> >>
> >> Since a couple of years we use a custom smart pointer to wrap
> >> pointers to QObjects, where the lifetime is managed by the QT object
> >> tree.
> >>
> >> This is very useful for two reasons:
> >> * In reviews it is clear that there is no explicit delete required,
> >> it eliminates the nowadays exceptional case of new() without delete().
> >> * The pointer asserts that the object has actually a parent and is
> >> not leaked.
> >>
> >> It has proven to be useful and disappointing that it is not available
> >> in all my QT projects. That's why I like to discuss to put it or
> >> anything similar into the QT source itself.
> >>
> >> I have provided some more details in a QT bug here:
> >> https://bug/
> >> reports.qt.io%2Fbrowse%2FQTBUG-
> 141134&data=05%7C02%7Crobert.schimkowi
> >>
> tsch%40andritz.com%7Ccfc97ead271b4b5f229d08de0c9e358e%7C6785298fe
> 8574
> >>
> 64b9b4b807178402632%7C1%7C0%7C638962070891495442%7CUnknown%7
> CTWFpbGZs
> >>
> b3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI
> kFOI
> >>
> joiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2F2fx3qQFuENGV
> ILOCC5C
> >> fGIKZsLgZKCSv9GLYeNAYZ4%3D&reserved=0
> >>
> >> What do you think?
> >>
> > I have seen similar approaches in customer code before, but I don't
> > quite see what parented_ptr itself brings to the table here?
> >
> > You can work around the "no naked new()" rule by creating a custom
> > template function that creates the type explicitly and enforces a
> > non-null parent. I don't understand why you need a new pointer type
> > for that. And for monitoring the validity of pointers to QObjects, we
> > already have QPointer.
> >
> > As the "naked pointer" way of working is ingrained quite deeply into
> > Qt, I don't quite see how you expect this to find a place in the
> > current API either?
> >
> > Perhaps it might be easier or better to add a make_child template
> > method to QObject that returns a new instance of the template type,
> > parented to the object you call it on? So you could do something like:
> >
> > auto button = myDialog->make_child<QPushButton>(tr("Some button"));
> >
> > instead of
> >
> > auto button = new QPushButton(tr("Some button"), myDialog);
> >
> > I think it should be possible to specialize these where needed (like
> > in this case, where the expected parent is actually a QWidget, not a
> > QObject), but I didn't try.
> >
> > Cheers,
> >
> > André
> >
> >
> --
> Development mailing list
> Development at qt-project.org
> https://lists.qt-/
> project.org%2Flistinfo%2Fdevelopment&data=05%7C02%7Crobert.schimkowit
> sch%40andritz.com%7Ccfc97ead271b4b5f229d08de0c9e358e%7C6785298fe8
> 57464b9b4b807178402632%7C1%7C0%7C638962071047684409%7CUnknow
> n%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIl
> AiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdat
> a=S0w01uCD9QiwwkYDRF7ZTxfxPBDloSA8UBoMagciVdI%3D&reserved=0
________________________________

This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system.

ANDRITZ HYDRO GmbH


Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You
________________________________