> > > > On 29 Oct 2025, at 01:42, Ville Voutilainen <[email protected]> > wrote: > > > > On Tue, 28 Oct 2025 at 23:15, Volker Hilsheimer <[email protected]> > wrote: > >>> Precisely so. Our ostensible declaration (and definition) is > >>> > >>> class QObject { > >>> ... > >>> public: > >>> template <class Child, class... Args> > >>> Child* makeChildObject(Args&&... args) > >>> { > >>> return new Child(std::forward<Args>(args)..., this); > >>> } > >>> }; > >>> > >>> and that's all there is to it. > >>> > >>> The reason it's a reach too far to return some > >>> semantically-parented-pointer instead is adoptability. > >>> With this approach, you can just change > >>> > >>> MyType* var = new MyType(foo, bar, someParent); > >>> > >>> to > >>> > >>> MyType* var = someParent->makeChildObject<MyType>(foo, bar); > >>> > >>> and there's no need for heavier refactorings in how that code uses > >>> MyType*. It doesn't need to be refactored to > >>> use a parented_ptr everywhere. > >> > >> > >> The above pattern seems to me to be the most pragmatic approach for an > API addition to Qt. Perhaps also a > QObject::addChild(std::unique_ptr<QObject *> child) which moves the > ownership of the pointer held by child into the callee. > >> > >> > >> I do see that a parented_ptr<> type makes the intent clear to readers, > static analysers, AI tools etc, in the same way that std::move’ing a > std::unique_ptr would. And that type then producing clear failures (compile > time if possible, although in practice it will have to be runtime > assertions) in case of incorrect usage might be practical. But that can be > achieved via explicit declaration of the variable, e.g. > >> > >> parented_ptr<QLineEdit> input = dialog->makeChildWidget<QLineEdit>(); > >> // would assert in ~parented_ptr if ‘input’ doesn’t have a parent > >> > >> > >> This makes the intent clear, while still allowing > >> > >> QLineEdit *input = dialog->makeChildWidget<QLineEdit>(); > > > > Sounds like a plan. Would you do the honors of producing a patch for all > that? > > > > And QParentedPointer instead of parented_ptr, right? :) > > > If “you” is “Volker”, then not in the near future - but hopefully this > conversation has given Daniel some input. > > 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. > > 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. 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 · Add a QObject::addChild(std::unique_ptr<QObject *> child) · 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 My vote is 2. after reading all the helpful comments. What do you think? Best regards, Daniel
-- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
