Use Vector instead of QList...

[Spaced Cowboy]

So I'm seeing a few of these...

when using the new Qt6 creator. I could sort of understand it if QStringList was deprecated, but it seems a little harsh to automatically warn against any use of the class :)

Also, when I do as it asks (I have a zero-warning policy), I still get:

Is this indicative of me doing something fundamentally wrong ? Or is it just a bug that'll be cleared up in a bug fix release - I'm using 6.0.1 if that matters.

[SGaist]

Hi,

I think the code model is getting confused as QVector has become an alias to QList in Qt 6.

[Spaced Cowboy]

Hi, ok thanks for the reply :)

In which case I think it'll clear itself up when they release a fix. For the time being I guess I'll just grate my teeth when I see the yellow triangles :)

[andr]

Sounds like https://github.com/KDE/clazy/blob/master/docs/checks/README-inefficient-qlist-soft.md

The advice is wrong, you shouldn't use this check.

[mrjj]

@andr
Hi
So is it possible to remove that concrete check?
Or you mean just ignore it even if shown ?

[SGaist]

It's valid for Qt5 however it might not yet support Qt6.

[andr]

@mrjj Yes, you can disable it, albeit it's quite clumsy to do so:

Tools -> Options -> Analyzer -> Clang Tools -> Diagnostic Configuration.

There you probably need to "Copy" first the "Default Clang-Tidy and Clazy Checks". Select the copy, and the "Clazy Checks" tab. "inefficient-qlist-soft" hides under "Level 1". The "Filters" box helps searching.

@SGaist: the check is also bogus for Qt 5. The QList(5) indirection for large objects was intentional, it e.g. gave you faster prepend() than in the vector case.

[SGaist]

@andr said in Use Vector instead of QList...:

@SGaist: the check is also bogus for Qt 5. The QList(5) indirection for large objects was intentional, it e.g. gave you faster prepend() than in the vector case.

No it's no bogus. There are numerous cases where in fact QVector would have been the correct choice (yes even in the Qt API), hence that check. QList's implementation has its advantages, not denying that, but it was not activated in the majority of cases. People tend to use QList because it was also used all over Qt's API. See this article for the reason about the changes done in Qt 6. There are also lengthy threads on the development mailing related to the choices made and why they were made.

[andr]

@SGaist: Clazy has no clue about the usage pattern of a particular QList instance. The warning is also created if you exclusively .prepend().

I am very much aware of the QList vs QVector discussions. I am also aware that the "evidence" supporting "problems" with QList(5) were artificial micro-benchmarks, and that this "evidence" was cited over and over for almost a decade to make it "true", ignoring the cases where QList(5) was actually better than QVector, and ignoring the fact that in the majority of cases in real world applications the whole discussion simply does not matter, starting with most QList instances in real world GUI application actually operating on data with size equal sizeof(void*). If you don't believe that, add some logging to the QList constructor to count objects and check yourself with a Qt application of your choice.

[mnbv]

@SGaist said in Use Vector instead of QList...:

... QVector has become an alias to QList in Qt 6.

Wait... really? Because I have a number of applications where profile-guided optimization led me to choosing QVector over QList for significant performance and memory usage improvements when working with large datasets (QList's node allocation on append() is a big hit), they're not getting rid of QVector in 6, are they?

Edit: Oh wait I just read that article about the changes you linked to. Guess it's more like QList is going away. Had a panic moment.

[andr]

@mnbv : In cases your PGO showed a real advantage of QVector over QList you could check the same with std::vector. It's not uniformly better, but usally better in these scenarios as it has less overhead on element write access.