[Development] The future of smart pointers in Qt API

[Ville Voutilainen]

On Wed, 5 Feb 2020 at 00:04, André Pönitz <apoenitz at t-online.de> wrote:
> > > > Managed by what? Also, it seems downright detrimental if understanding basic C++
> > > > concepts is useless with Qt.
> > >
> > > I don't think that's received as much of an insult as you meant it to be
> > > by parts of your audience. Not requiring the verbosity of "basic C++" in
> > > user code is surely a benefit of Qt for me, and if people are appalled by
> > > not getting that with Qt, well, not my problem.
> >
> > Yeah, well, "basic C++" isn't verbose.
> > QVector and QList are slightly above basic C++, since they're templates.
>
> Ok? Then what were you referring to when saying "it seems downright detrimental
> if understanding basic C++ concepts is useless with Qt."? I thought it was
> std::unique_ptr, but that's a template, i.e. no "basic C++" in your definition.

I'm talking about using destructors for releasing resources, and
writing code where
dynamically allocated resources are tied to block-scope objects, thus
making sure
that the scope will not be exited without cleaning up, i.e. not
leaking. std::unique_ptr
is a utility type that helps doing that, but the whole notion of
automatic cleanup
has been in C++ since the dawn of time. We have also had utility types
that assist
in using it for allocated things since c++98, and now we have arguably
better ones
since c++11.  They are better because they make the transfer of ownership saner,
and explicit, and unambiguous, and ubiquitous. Ownership transfer
works the same way
everywhere - pass a moved unique_ptr into a function, and you know you
passed ownership,
and you know that you the caller didn't leak, and you even have fair
amounts of confidence
that the callee will understand that it just acquired the ownership of
the pointed-to object
you passed, and will need to write more code to leak it than in the
case of not leaking it.

It makes programming with pointers very similar to programming with values.

That's what Daniel is trying to get us to interoperate with.

Regardless of whether using such basic C++ concepts makes programmers
magically understand how Qt Widgets
work, at least they might have a better starting point than when
seeing a full line of code looking like

new QLabel(tr("I'm just a static label, I don't need to be stored
anywhere, except I am"), parent);

and thinking, based on their knowledge of basic C++ concepts, that
that Must Be Wrong. As they think
about cases where the result is stored in a variable but not deleted.
Because both of those smell like
common mistakes, but in our style they are The Way to do things. That
causes friction for every programmer
who has been exposed to C++ before being exposed to Qt.

We can certainly scoff at basic C++ concepts. Nokia was very good at
that, thinking that their NIH stuff
was superior.