Qt Contributors Summit 2019 Qt 6 Changes / Migration
Jump to navigation
Jump to search
Qt 6 Changes / Migration Session at Qt Contributors Summit 2019
- How can we migration to Qt 6 as easy as possible and start already in Qt 5?
- For example, a unified string theory would be a relevant topic
Prominent Changes
- List/Vector ok in majority of cases (plain replacement)
- QString remains in API since QStringView reveals too much about API; will be possible to construct a readonly QString
- MetaObject indexes change, but should not cause problems except maybe iterating over all
- QVariant: Cannot remove all conversions and magic, extract base class QAny, move QVariant to a new Qt5Support library, ditto QRegExp
- OpenGL extra classes (except context and functions) will be moved to old/new QtOpenGL library -> header only, trivial
- Remove Multiple inheritance of QImage/Pixmap/QPaintDeviceWindow from QPaintDevice and others. , add a templated constructor to QPainter instead, should have minimal impact
- Add new versions of toInt(bool &ok) returning std::optional (C++17), implement old on functions top?
Migration
- u"" string should already be possible in Qt 5 at the cost of one allocation (QStringLiteral?)
- Use clazy as maintained by KDE (Sergio) to port source code
- Modernizing code helps, for example use range-based for
- Almost always auto helps
Some Proposed clazy fixes
- QLatin1String(). etc -> u""
- remove QStringRef::toString(), fix QString::midRef() -> QString::mid() etc
QStringBuilder caveat when using auto
- auto name = xmlStreamReader.name() Ok
- auto name = xmlStreamReader.name() +"B" Wrong, result is a QStringBuilder helper type with references to source strings
Other Topics
- Turn deprecations warnings off/on : Cannot reach a conclusion, ported code will cause warnings in Qt 6 initially
- ABI implications of new property stuff, mixing old and new properties, BC challenges when extending properties? Requires some black magic in C++ 17