[Development] Question about QCoreApplicationData::*_libpaths

[Ziller Eike]

> On Jan 19, 2016, at 10:40 PM, Marc Mutz <marc.mutz at 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.mutz at 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.mutz at kdab.com <mailto:marc.mutz at 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 at qt-project.org <mailto:Development at 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