[Development] QList for Qt 6
marc at kdab.com
Fri May 24 10:19:15 CEST 2019
On 2019-05-24 09:35, Lars Knoll wrote:
>> On 23 May 2019, at 13:26, Mutz, Marc via Development
>> <development at 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?
More information about the Development