[Development] QUIP 6: removing top-level const from return types

[Marc Mutz]

On Tuesday 23 May 2017 10:44:11 Ville Voutilainen wrote:
> On 23 May 2017 at 11:39, Marc Mutz <marc.mutz at kdab.com> wrote:
> > On Tuesday 23 May 2017 08:36:00 Lars Knoll wrote:
> >>  (a detach happening on Linux, but not on MSVC)
> > 
> > Don't fall for FUD.
> > 
> > QPixmap does not have functions that are overloaded on const/non-const.
> > Neither does QRegion. Well, except for the special member functions,
> > which is the whole point of the exercise. And for QStringBuilder, the
> > change enabled calling the rvalue overload of toXyz() functions in the
> > first place, which re- use storage, saving an allocation.
> > 
> > To summarize: there is no negative impact of any of these changes. And if
> > MSVC does something stupid, it deserves to continue to be pessimised.
> 
> Maybe, but I have some questions: the review for removing top-level consts
> from QRegion says "It has no effect and inhibits move semantics." How does
> it inhibit move semantics? How is this even a SiC? What _positive_ impact
> do these changes have?

See Olivier's example:

   QPixmap pix;
   pix = splash.pixmap();

with

   const QPixmap pixmap() const;

calls the copy assignment operator, while with

   QPixmap pixmap() const;

it calls, as expected, the _move_ assignment operator.

Similarly, in the QStringBuilder case, when

   const QString resolved() const;

then

   (string % builder % expression).toUpper()

calls

   QString QString::toUpper() const &

which always allocates a new buffer, while with

   QString resolved() const;

it calls

   QString QString::toUpper() &&

which in many cases can re-use the buffer allocated for *this to store the 
result and leave *this empty.

Thanks,
Marc  


-- 
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, C++ and OpenGL Experts