Am Dienstag, 23. Mai 2017, 11:17:32 CEST schrieb Ville Voutilainen: > On 23 May 2017 at 12:00, Marc Mutz <[email protected]> wrote: > >> 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. > > Ok, yeah, I was using constructors, not assignment operators so I > failed to see the > issue. > > So, we are doing this to improve performance of otherwise valid code, > but not making this > change doesn't make anything worse, right?
Someone could have written: const QPixmap (QSplashScreen::*hello)() = &QSlpashScreen::pixmap; or static_assert(std::is_const<decltype(splash->pixmap())>::value); But that's unlikely and just a theoretical construct. I'd say that the risk that this change breaks anything is less than for most of the other changes we do to the API, including adding functions to classes. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
