[Development] parented_ptr

[André Somers]

Hi Daniel,

On 29-10-2025 12:00, Daniel Schürmann wrote:
>
>
>
>     > On 29 Oct 2025, at 01:42, Ville Voutilainen
>     <ville.voutilainen at gmail.com> wrote:
>     >
>
>     One thing to consider in this context is if/how we’d like QLayout
>     to be part of this logic. When building a widget UI, QLayout is
>     ultimately responsible for taking core of the correct parent/child
>     relationships etc. Opinions vary on that topic, but I typically
>     create child widgets without parent and rely on the layout. So, we
>     might find out that a QLayout::makeChildWidget makes sense.
>
Maybe...? I mean, does it need it's own, given that it is a QObject already?
>
>
>     Volker
>
>
> that sounds great. I am happy to help. I will need a helping hand 
> since I have no experience with the Qt contribution process.
>
> I am happy that it fits to my summary here:
> https://lists.qt-project.org/pipermail/development/2025-October/046669.html
>
> Listing things we have agreed with incorporated semantics (please 
> correct me or confirm):
>
> QParentedPointer: A new pointer that points to a QObject with some 
> parent != nullptr.
>
> QObject::makeChildObject(): That creates a parented Objects.
I would suggest you split these into separate commits. Neither depends 
on the other, though they _can_ be used together. Full disclosure: I 
still doubt the usefulness of the specific pointer type.
> Borrow case (pChild must not outlive pDialog):
> Child *pChild = pDialog->makeChildObject<Child>()
>
> Member variable case (m_pChild is never dangling because the parent == 
> this)
> QParentedPointer<Child> m_pChild = makeChildObject<Child>()
>
> Open Ideas:
> · Make QParentedPointer<Child> QObject::makeChildObject() protected
No, please don't have your parented pointer be the return type of 
makeChildObject. And making it protected won't work. There are many 
cases where you want to "attach" children to a parent object. Making it 
a protected method will severely limit the usefulness of the method.
> · Add a QObject::addChild(std::unique_ptr<QObject *> child)

Start simple, I would suggest. Do you really think that this will bring 
a lot of value? Introduce the basic version, see how it actually impacts 
your code base and collect feedback, and then see if an overload like 
this really would bring value. One problem I see is that, AFAIK, a 
std::unique_ptr<QObject> is a distinct type from a 
std::unique_ptr<SomethingDerivedFromQObject>, so the signature above 
won't work. Something _like_ this can of course be done, using a 
template and casting, but it won't be as pretty.

> · Ideas around UniqueObjectPtrDeleter() which can be better 
> implemented by Qt Object tree allowing shared ownership
> · makeQSharedPointer / makeQPointer …
>
>
> I think we have two interpretations we need to be explicit on to avoid 
> later discussions:
>
> 1. QParentedPointer: Object has any parent -> there where objections, 
> we already have QPointer()
> 2. QParentedPointer: Object has “this” parent -> some implicit 
> lifetime guarantees

The latter seems really weird. Given that pointers are value types and 
can thus be copied, there is no way to guarantee the pointer belongs to 
the current object. I would object to such a thing.

Cheers,

André

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20251029/009ccb33/attachment.htm>