On 2019-05-24 09:35, Lars Knoll wrote:
On 23 May 2019, at 13:26, Mutz, Marc via Development
<development@qt-project.org> wrote:
[...]
You said that QList should vanish from Qt API. So we don't care. We'll
have that switch to make QList _be_ QVector for ese of porting, but as
a template alias. There's your zero-copy conversion :) That leaves
users. And I repeat: I'd leave QList alone (as QArrayList, possibly
with always IndirectLayout), and just have implicit deprecated
conversions between QArrayList and QVector. You shouldn't care about
performance of unported code: It's easy to target both Qt 5 and Qt 6
if you use auto for receiving from Qt API. For sending to Qt API, it's
a bit more tricky. You need to ifdef or live with the implicit
conversion in a Qt 6 build, but it's not something that we should
optimize for. Really. Don’t.
Sorry, but no. Larger performance regressions that are not really
visible/cought at compile time can be as large a headache to our users
as the non stable references to data in the container.
Sorry, you're comparing apples and oranges, iow: a performance issue
with a correctness issue. You cannot weigh them against each other. We
need to ensure that user code stays correct _first_, fast _second_. The
first rule of optimisation: Don't do it. The second rule: Don't do it
_yet_. Write correct code first, optimize later. You can't turn that
around. It'd send a catastrophic signal to Qt users.
Here's how I see it: performance problems show up in testing, and are
easily identified by a profiler, a tool that is available on every
platform and everyone knows how to use it. Stability of references
problems are found, if at all, by memory sanitizers, something that much
less people will be familiar with, and, crucially, might hide in
less-well tested code.
I’d argue that it might cause the larger amount of problems as keeping
references to data in the container is something that’s not used very
often. But *everybody* will have tons of conversions between QList and
QVector with your plan for unported code. IMO that’s just as bad.
I disagree. See above. I'd like to add, if I may be so bold, that seeing
just how widespread unintended detaches are _even in Qt code_, are you
_actually_ going to tell me that copying a QVector into a QList is going
to be _noticeable_? It has O(detach) complexity. Yes, in the 5% of code,
it might get slower (if there wasn't an unintended detach to begin
with), but as I said: it's easily identified with the simplest of tools:
a profiler, and in normal testing. The correctness issue may be hiding
in the 95% that is less well maintained.
Please tell me that I misunderstood you and that you are _not_ going to
prefer to optimize for speed of _unported_ code, sacrificing correctness
of the same?
Please?
Thanks,
Marc
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
