Am 30.10.25 um 20:55 schrieb Volker Hilsheimer:
On 30 Oct 2025, at 18:20, Daniel Schürmann <[email protected]> wrote:
3: QObject::addChild(std::unique_ptr<QObject *> child)
Will this have a chance to being merged upstream?
In principle, I don’t see a reason why this would not be acceptable.
The devil is in the details; note that the following does not compile:
QObject parent;
QWidget widget;
widget.setParent(&parent);
as QWidget::setParent(QWidget *) shadows QObject::setParent(QObject
*). The equivalent code using addChild
QObject object;
auto child = std::make_unique<QWidget>();
object.addChild(std::move(child));
should also not compile, as a QWidget must only have another widget as
the parent.
(and thinking about it, that’s also something to keep in mind for
QObject::makeChildObject).
And all of that without qobject.h being able to include qwidget.h…
which might make this challenging.
Volker
Hi Volker
I got wind of the devil's scheme, while implementing our plan.
All the discussed ideas of createChild() and addChild() needs in sub
calls, finally call the correct setParent() overload.
This depends on both, the parent and the child class type. C++ can
unfortunately not deduce the type of the "this" pointer in a base class
template.
This is however required to allow the simple form of:
parent.createChild<QObject>(); parent.addChild(std::move(pOther));
My first idea was to overload ceateChild() in QObject and QWidget, but
there are a couple of more setParent() overloads and potential other in
the user code. This IMHO qualifiers that approach.
the workaround is the rather ugly:
parent.createChild<QObject>(&parent);
Due to the redundant parent, which must be equal the code might be the
source of headaches, at least does not simplify the Qt usage what is
desired.
Conclusion: Let's add some free helper functions that allows the C++
Core Guideline semantics anyway.
I will prepare the following:
* QParentedPointer<Child>
* qCreateParented<Child>(args);
* qAddChild(parent, std::unique_ptr<Child>);
I will prepare a PR for this.
Best regards,
Daniel
--
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
