On Thu, 16 May 2019 at 11:24, Иван Комиссаров <abba...@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 _______________________________________________ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
