[Development] Question about QCoreApplicationData::*_libpaths

[Marc Mutz]

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 :)

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.

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> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts