[Development] unique_ptr and Qt, Take 2

[Daniel Teske]

Hi,

I was happly ignoring the other threads, since I didn't like the 
temperature of some the responses.

But I guess you force me to write a response not just to you, but 
something that is a bit more general.
> Or... just don't do that?
>
> I can't recall that I've *ever* had problems with QObject ownership.

You, and a few others have made similar arguments, that start from your 
personal experience and since you do not needed something conclude that 
it is not worth doing.

And please don't read the rest of the mail as a attack on you, that's 
not intended. I think it's important to hear from all kind of different 
users, but I need to point out what I perceive as a faulty argument.

It is imho the wrong perspective:

There's a wide spectrum of Qt users.
* Some of which don't want Qt to change [much].
* Some of which want leverage new C++ features while using Qt
* Some of which want Qt to be more like the C++ standard

By arguing from a personal standpoint, you are implicitly ignoring all 
users that aren't like you. A proposal (or the rejection) should be 
based on considering the effect not just on you, but on all kind of 
different users.

Except, just considering current users, would be quite wrong.

Qt needs to continously attract new users, as it otherwise dies with the 
current user base. Those users will mostly - I would assume - come from 
a C++ backgroud. And my experience as a freelancer is that most projects 
I see use at least C++11 and I have no trouble finding projects using 
more modern standards.

But even that, would be the wrong perspective. We are discussing APIs in 
the context of Qt 6, which will be around for a decade. Thus, the 
correct perspective would be to consider which kind of user Qt wants to 
attract and serve in a few years. And I believe that in a few years, 
most people with a C++ background would expect modern apis.

The same perspective error happens from these arguing for deprecation 
and removal, too.

For example, obviously Q_FOREACH is ugly and outdated. It seems some 
argue that the benefit of not having to teach Q_FOREACH is worth the 
major pain and frustration that existing users would experience if it 
just got removed. I can't understand that.

In fact the whole premise of the thread is imho misguided. If the goal 
is making Qt and C++ more interoperable, then deprecation and removal is 
the wrong way to go about it.

The way forward should be to create win-win situations for both those 
that want to make use of modern C++ and those that are quite happy with 
Qt as it is.

For example, I wish Qt 6 would:

* enable templated QObjects. There's a prototype from Olivier, so is 
that possible?
* support move only types in Qt container
* add overloads for all functions taking bool * that make use of 
std::optional
* add overloads for all functions using output parameters. auto [...] = 
foo() is imho ugly, but that's nevertheless better than output parameters
* have great interoprability with ranges

None of that would require making Qt worse for existing users.

> Generally, if you follow three rules:
>
> - If you create an object on the stack, either don't parent it or ensure
> its parent outlives it. (Usually not hard!)
> - If you create an object with `new`, **create** it with a parent.
> - Otherwise use a smart pointer (QScopedPointer or QSharedPointer)¹.
>
> ...you just won't have problems.

And that doesn't need to change with my design at all. You can just 
write the same code as is. To reiterate a point that seems to be a 
source of misunderstanding, in the design I proposed the vast majority 
of objects are never owned by a unique_ptr. Most objects are created 
with a parent.

And there are small benefits that even those that don't want to use 
unique_ptr, can get with minimal effort. For example by using the new 
makeChild function:

parent->makeChild(...);

It's almost impossible to forget to pass a parent parameter. And best of 
all, no one is forced to use that, but it can be adopted at whatever 
pace is best.

And for your last case of holding a QObject in a smart pointer, the 
propsal makes that drastically less akward.

So, I think what I have actually proposed has zero costs to those that 
don't want to use it, while enabling those that e.g. want to make use of 
tooling around memory managment capable of doing so.

daniel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190613/8413e693/attachment.html>