> On Jan 19, 2016, at 10:40 PM, Marc Mutz <marc.m...@kdab.com> wrote:
>
> On Tuesday 19 January 2016 19:56:38 Mathias Hasselmann wrote:
>> Am 19.01.2016 um 15:21 schrieb Ziller Eike:
>>>> On Jan 19, 2016, at 16:09, Marc Mutz <marc.m...@kdab.com> wrote:
>>>> I doubt many people actively use the fact that Qt containers are cheap
>>>> to copy.
>>>
>>> Each and every developer that uses Qt uses the fact that Qt containers
>>> are cheap to “copy"
>>>
>>> class A
>>> {
>>>
>>> public:
>>> QVector<B> something() const;
>>>
>>> private:
>>> QVector<B> m_something;
>>>
>>> };
>>>
>>> QVector<B> A::something() const
>>> {
>>>
>>> return m_something;
>>>
>>> }
>>
>> Good point Eike, thank you.
>>
>> Marc, wow would one avoid invocation of the copy constructor here?
>> Without handing out pointers or references. Of course.
>
> It's funny how the same people who think nothing of the per-element memory
> allocation of QList suddenly become vehement performance critics when it
> comes
> to CoW :)
Well, passing around a list and doing something based on its elements happens a
lot more than actually constructing lists.
But the point is not that you cannot write efficient code with std containers,
but that changing from CoW to non-CoW _will_ potentially effect basically all
existing Qt based code.
Even if only N% of the uses are actually noticeably effected, these still need
to be found and fixed.
Any fix in the API will require investigating and potentially fixing the
callers of that API. If a Qt-based product is a library, that responsibility is
then
pushed to Qt’s customers’ customers.
We still haven’t even managed to automatically test for performance regressions
in _Qt_, afaik?
I think that the argument that people will notice performance issues that
matter and fix them, and the rest don’t matter or will be found by some tool,
is too optimistic.
> It likely just doesn't matter, the rest of the C++ community has been working
> with containers that don't do CoW for the past 20 years and have survived.
>
> In those cases where it does matter, you'd return by const-&. Or an
> array_view. And no, that doesn't restrict your freedom to implement the
> function in any meaningful way, because you can always keep a caching mutable
> member to hold the result for the next call to the function (memoisation or
> however it's called), without any loss except the space required for the
> member.
That awfully sounds like re-implementing CoW logic by hand everywhere where
someone providing an API thinks it might be worth the effort.
> What about non-arrays? By the time we get around to all this, there will be
> no
> containers other than array-compatible ones left, because nothing else will
> provide the required speed. And if there are, you can write a _view for
> those,
> too.
>
> --
> Marc Mutz <marc.m...@kdab.com <mailto:marc.m...@kdab.com>> | Senior Software
> Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt Experts
> _______________________________________________
> Development mailing list
> Development@qt-project.org <mailto:Development@qt-project.org>
> http://lists.qt-project.org/mailman/listinfo/development
> <http://lists.qt-project.org/mailman/listinfo/development>
--
Eike Ziller, Principle Software Engineer - The Qt Company GmbH
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB
144331 B
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
