[Development] parented_ptr

[André Somers]

On 16-10-2025 13:46, Daniel Schürmann wrote:
> Hi André
>
> Nice that you can confirm that there is a demand from others for a 
> solution.
You're not the only one using that warning in their CI, it seems... :-)
>
> > 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?
>
> That's actually the solution I was looking for.
> I love that idea. Thank you.
>
> What type is the returned pointer? I like to have one that has the 
> semantical guarantee of being a child object. This is beneficial to 
> distinguish classic owned pointer member variables from borrowed from 
> the Qt Object tree.
>
> Do you have an idea?
Well, my suggestion would be to not introduce a separate non-owning 
pointer type at all, so it would just return the type itself, just like 
new does. As was already pointed out, a raw pointer should already be 
understood as a non-owning pointer. I personally don't see the worth of 
introducing a special pointer type for instances that were created with 
a QObject-parent. I think it will just cause a lot of confusion and 
headaches for integrating that properly and consistently into Qt, not to 
mention getting it adopted in legacy code bases. I think having CI check 
for naked new() calls in your project, as you already do, would be 
enough, and _that_ doesn't need a new pointer type.
>
> While the code is kind of trivial, the main benefit it the 
> semantically effect that you are able to annotate a pointer as 
> patented in a standardized syntax across code base. You don't have to 
> learn custom solution and a upstream provided version will help to 
> make this approach a recommendation standard style.
>
> > I don't quite see how you expect this to find a place in the current API
>
> The moc generated code may use it for instance.
How? Could you give an example, and explain how it would do something 
new we can actually use?
>
> Getter that return an patented object pointer to another object are 
> borrowed pointers and doing it via a raw pointer is just in the sense 
> of the C++ Core Guidelines.
The pointer you get back from a `->makeChild(...)` would also be 
"borrowed" in this sense: somebody else is taking responsibility for 
cleanup later on. The only difference is, that deleting it is generally* 
safe, as the owner won't try to delete it again.
> We need to consider the case where this pointer will be stored, 
> creating a shared ownership. For this case the QPointer is designed, 
> but it does not have the "patented" semantic.  Maybe we need another 
> pointer for that?

(Assuming you mean "parented", not "patented" above.) It doesn't strike 
me as a good idea to do that. I think it will be quite confusing. The 
way you describe it already creates confusion to me, as "shared 
ownership" in C++ refers to the idea that the last one still having a 
pointer to the payload deletes it on destruction, but that's basically 
the opposite of what happens here, if I understand you correctly.

If you need to monitor if a QObject is still alive, you can already do 
that with QPointer. No need for a new type there.

Cheers,

André