[Development] QList for Qt 6

[Lars Knoll]

> On 24 May 2019, at 10:19, Mutz, Marc via Development <development at qt-project.org> wrote:
> 
> 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.

Yes, both are different things. But for a user moving from Qt 5 to Qt 6, it mainly matters how he is affected by this. 

And there might be quite a few people who will never hit the problem with stability of references (because storing a reference to a member of the list is not that common), but they will be seeing performance issues because of the implicit (and hidden) conversion.

> 
> 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.

Profilers help with real hot spots. They don’t really help a lot if those things are spread all over your code base.
> 
> 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?

You conveniently didn’t quote the first part of my answer. I didn’t say that. I said I really want to ensure that we get a zero copy conversion between QList and QVector where this doesn’t imply (possible) incorrectness in the code. That’s the case for all types that are smaller than a pointer and movable.

Lars

> 
> Please?
> 
> Thanks,
> Marc
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development