On 2019-05-17 19:47, Scott Bloom wrote:
[...]
Im just going to throw out my 2 bits on this....
Please don’t underestimate (and Im not hearing Thiago say this) the
pain, of breaking source compatibility. Even on Major (5->6) version
changes.
[...]QCanvas[...]QWebKit[...]
When the Qt team, decides to make these changes, it hurts a lot of
developers, who have to justify to their company, I need to spend X
number of months figuring out a solution, to replicate code that was
already working fine...
These are real pain points, yes, because higher-level features, for
which there are no replacements, have been remove from the core domain
of Qt: UIs.
I fully agree with you on that one.
From a utopic point of view, Id be fine with, if every Qt container,
and class that has been "mostly" implemented in STL, or the native
language was thrown out.. But as I tell my employees, just because its
in the language now, doesn’t mean we should go through our 2.5 million
lines of code, and re-write every one to use modern C++...
I disagree here with you here, though. You have had nine years now for
realising that QList is a bad container to use in your code
From
https://marcmutz.wordpress.com/2010/07/29/sneak-preview-qlist-considered-harmful/
(2010):
Run, don’t walk, and fix your new API to not use QList,
or mark your new types as movable (details are in the
patch). Alas, both changes are binary incompatible, so
you can’t do them if you need your code to stay BC.
This might be one of the reasons why QPair and QVector
aren’t “fixed” yet: doing so would change the layout
of the QList instantiated with them :(.
But, at least for new code, there’s no excuse anymore:
Just apply the patch.
You've had anywhere between eight years to manually and now to
automatically run clang-tidy on your code to port at least those
variables that name QList to auto, isolating you from the fallout that a
QList removal would have. If you still use QList in your code today,
then, I'm sorry, it's your own fault. You follow the development list,
so the same is true for Q_FOREACH, for you.
You can also use the Qt containers, but restrict yourself to the
STL-compatible subset of the API. And then the transition is as easy as
s/QVector/std::vector/. That has been possible since Qt 3.0.
So, this case differs greatly from the two instances of feature removal
you mentioned above in that you had literally years of time to prepare a
coding style that would all but isolate you from the exact type of
container used. The STL containers exist in standard form since 1998,
and since then you had time to port your own code away from Qt
containers, further isolating you from one of the most
code-churn-producing subsystems of Qt: containers. If you've been with
Qt since Qt 3 or Qt 2, you know what I mean. And if you have not learned
from Qt 2 -> Qt 3 or Qt 3 -> Qt 4 w.r.t. to containers, then - sorry -
again: your own fault. Had you ported to STL, your code would stay
unchanged.
I'm playing devil's advocate here. In reality, yes, I want the rebase of
Qt onto modern C++, for a great many reasons, but I'm also always
looking for a way how to do that without disruptive changes. But that
requires that Qt users compile with deprecated warnings enabled and fix
their code small steps at a time. There are not many libraries that keep
SC for so long as Qt does. But very long is not forever, and change will
come one way or another. The good news is that C++11 allows you to
insulate your code in many ways (auto, unordered_*), and this is
precisely why we can now take this step.
To replace out every container, that works today? And in the process,
break probably billions of lines of existing Qt code, which would have
to be re-written using the new containers??? Please don’t.... Even
for 6.0... Some form of transition would be great.
Upon reading the recent mails in this thread, one could have noticed
that this whole subthread started with an unrelated topic: _not_ making
QList an alias to QVector. I'd prefer the discussion to pick up on that
technical point, even though I appreciate that it's easier to just
generally vent FUD in a bike-shedding frenzy than to seriously consider
technical issues such as how we can remove QList with minimal
disruption.
@all:
I will no longer reply to the Views subthread, because it has gone
off-track, as usual. Please give your valued input on a way forward
regarding QList removal (QList subthread).
Have a nice weekend,
Marc
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
