[Qbs] Donation to QBS developers/maintainers/contributes
abbapoh at gmail.com
Thu May 16 01:24:39 CEST 2019
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Qbs