[Qbs] Donation to QBS developers/maintainers/contributes

[Christian Gagneraud]

On Thu, 16 May 2019 at 11:24, Иван Комиссаров <abbapoh at gmail.com> wrote:
>
> In many cases, you don’t need to copy them. For trivial getters, you can return const-ref/span to the internal vector instead of a copy because in many places all we do is iterate over that vector.
>
> The only argument for copies is that it’s impossible to change the implementation from returning a member to some «transformed member» without breaking BC. Well, so far Qbs didn’t do any promises about BC so I don’t think it’s relevant.
>
> This will save us from creating a temp variables or usages of qAsCont to avoid detaching in range-for loops (see this commit https://codereview.qt-project.org/#/c/253792/ to estimate the amount of incorrect usages of Qt containers). Note, that those clutter API as well, especially the need of a temp variable.
>
> I didn’t do any measurements, but quick search for QList in Qbs source code shows a lot of places  where it’s used incorrectly - it stores «big» structures, std::shared_pointers, even all QSharedDataPointer classes are not marked as Q_MOVABLE_TYPE and thus result in extra allocations in QLists…

can QList -> QVector be automated? Or does it has to be done on a case by case?
I have a python script to do "mass but targeted" clang/clazy auto-fixit.

There is https://github.com/KDE/clazy/blob/master/docs/checks/README-inefficient-qlist.md
But it doesn't offer a fixit :(

Concerning the QSharedDataPointer classes are not marked as
Q_MOVABLE_TYPE, could clazy detect/fix these as well?

> My point is - current usage of Qt containers in Qbs should be carefully revisited, switching to more suitable containers (QVector or std::vector/std::deque).

Moving to QVector seems easier, at least as a first test. But we would
need performace regression testing to see if it really speed up
things.

Chris