Thiago Macieira wrote: > On Sunday 09 August 2015 03:26:33 Kevin Kofler wrote: >> Marc Mutz wrote: >> > On Friday 07 August 2015 19:41:07 Kuba Ober wrote: >> >> How about making such traits explicitly necessary? People would then >> >> have to learn about them. As a user, I wouldn't mind - the compiler >> >> would pick it all up for me. >> > >> > An option for Qt 6, but for Qt 5, it would be a source-incompatible >> > change. >> >> Or, since we're already discussing source-incompatible changes, how about >> defaulting to Q_MOVABLE_TYPE? It's the common case, and if you screw up, >> you'll notice it crash and burn pretty quickly. > > No can do.
Care to elaborate? This would be a source-incompatible change for a Qt 6. It would apply to Qt containers and Qt containers only. Nothing says that Qt needs to follow STL conventions and contracts. And as I wrote, a complex type erroneously treated as movable will trigger a noticeable crash, whereas the opposite will just be slow and go unnoticed. For the lifetime of Qt 5 (which I hope will be long!), this change is of course not possible due to the source incompatibility. > Please see the C++17 proposal of destructive moves instead. It took 4 years for Qt to agree to require a limited subset of C++11, so, realistically, C++17 features are not likely to end up used (everywhere, at least) before at least 2021. I guess it will also require good compiler optimization to be as effective as a memmove operating on the whole vector. (Basically, the compiler needs to detect that you are memmoving a whole vector and convert it to a memmove.) Kevin Kofler _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development