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é
--
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
