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
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
