All of the back and forth on this issue recently and over the years really make want to ask this question:
Is the promise of SC worth all the potenital pitfalls? There seems to be no end to the discussion with every solution requiriring hair rising compromises. Is it _really_ that impossible to just remove QLIst entirely and force user to choose form a range of classes each tailored for the specific scenario that QList tried to cover? As it is, it seems like we're rapidly heading to a nightmarish scenario worse than any SC breakage, where users will have to looks for problems in a perfectly compiling code. Is the gordian knot of full SC really possible to unravel or is it time to axe it? On Fri, May 24, 2019 at 12:04 PM Lars Knoll <lars.kn...@qt.io> wrote: > > 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 >
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development