[Development] QUIP 6: removing top-level const from return types
marc.mutz at kdab.com
Tue May 23 11:00:19 CEST 2017
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:
pix = splash.pixmap();
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;
(string % builder % expression).toUpper()
QString QString::toUpper() const &
which always allocates a new buffer, while with
QString resolved() const;
QString QString::toUpper() &&
which in many cases can re-use the buffer allocated for *this to store the
result and leave *this empty.
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
KDAB - The Qt, C++ and OpenGL Experts
More information about the Development