> On 24 May 2019, at 10:19, Mutz, Marc via Development > <development@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@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@qt-project.org > https://lists.qt-project.org/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
