[Development] QList for Qt 6

NIkolai Marchenko enmarantispam at gmail.com
Fri May 24 12:03:14 CEST 2019

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
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.knoll at qt.io> wrote:

> > 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
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190524/4476d7ea/attachment.html>

More information about the Development mailing list