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 :)
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.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
http://lists.qt-project.org/mailman/listinfo/development
