On Tuesday 23 May 2017 10:44:11 Ville Voutilainen wrote: > On 23 May 2017 at 11:39, Marc Mutz <[email protected]> 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 <[email protected]> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
