[Development] The future of smart pointers in Qt API

[Ville Voutilainen]

On Tue, 4 Feb 2020 at 18:48, Volker Hilsheimer <volker.hilsheimer at qt.io> wrote:
> >>> But that just means that QBoxLayout::addWidget(std::unique_ptr<>) has to behave imho saner in that edge case and actually delete the widgets that were added but never parented. (And I should really implement that to show how it would work.)
> >>
> >>
> >> That seems like a terrible idea. One of the layout’s jobs is to set up the parent/child hierarchy so that you as a developer don’t have to.
> >
> > I don't see how that idea changes that.
>
>
> Iif the layout deletes widgets that were created without parent, instead of adding it to the correct parent, then that’s a change. You have to create widgets with parents, and add them to the layout (which might then add it to another parent, which at the very least introduces unnecessary overhead of ChildAdded/Removed event processing).

Right; the layout shouldn't insta-kill parentless children without
trying to reparent them first.

> >> Do we really want to make it harder for people to write UIs just because the resulting code doesn’t satisfy a C++ idiom?
> > It's not a question of satisfying idioms for the sake of satisfying
> > idioms, it's a question of avoiding bugs that we know
> > based on decades of experience to be difficult to avoid with raw pointers.
> That’s my point:
> I do not believe that the decades of experience we have with QObject’s parent/child model support the claim that it is inferior to using smart-pointers. It’s not something people constantly struggle with.

I have a completely polar opposite experience, it's the main source of
memory leaks and double deletes in Qt application code.
And the only thing we can tell our users is "don't make ownership
mistakes", and for that we have experience from days older
than Qt that tells us that they can't accomplish that lofty goal. Your
experience suggests that this is not something people
constantly struggle with, my experience suggests that it's the #1
top-priority bug in Qt, hands down, no competition.

> >> If you don’t care about the things that QObject/QWidget does for you, then don’t use QObject/QWidget. And if you do use QObject/QWidget and get a consistent object model from it, then I’m really not convinced that adding smart pointers to the API is making the code clearer, or in any way more explicit. It’s not like the ability of using std::unique_ptr means that people no longer have to be familiar with Qt’s basic concepts to use it correctly.
> >
> > Correct, but if code moves a std::unique_ptr into a function call
> > argument, I know that ownership is transferred, by just glancing at
> > the code. With a raw pointer, I don't know that.
>
>
> But ownership isn’t transferred if you call QLayout::addWidget; it is never transferred to the layout object - it might be transferred to the QWidget that the layout operates on.

But perhaps it should be transferred to the layout, and transferred
further when the layout is attached to a parent widget.

> So you read that one line of code and make the wrong assumption. If you delete the layout object before you set it on the parent widget, then you end up with leaks, unless we make the change above where QLayout assumes ownership.

Indeed.

> If you understand Qt (and don’t assume that by understanding some basic C++ concepts you can use any framework), then you see that widgets are added to a layout that is used, and are therefore managed objects.

Managed by what? Also, it seems downright detrimental if understanding
basic C++ concepts is useless with Qt.