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/ <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… 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). > 16 мая 2019 г., в 0:00, Christian Gagneraud <chg...@gmail.com> написал(а): > > On Thu, 16 May 2019 at 09:32, Иван Комиссаров <abba...@gmail.com> wrote: >>> 15 мая 2019 г., в 19:50, André Pönitz <apoen...@t-online.de> написал(а): >>> >>> Getting rid of implicitly shared containers should be a rather obvious move >>> when "performance" is part of any "final picture", coherent or not. >> >> +1 from me, hidden detaches are evil =) > > How do you avoid copy then? Without cluttering an API. > > Chris
_______________________________________________ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
