[Qbs] Donation to QBS developers/maintainers/contributes

[Иван Комиссаров]

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 <chgans at gmail.com> написал(а):
> 
> On Thu, 16 May 2019 at 09:32, Иван Комиссаров <abbapoh at gmail.com> wrote:
>>> 15 мая 2019 г., в 19:50, André Pönitz <apoenitz at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qbs/attachments/20190516/7b94b671/attachment-0001.html>