Qt Contributors Summit 2019 Qt 6 Changes / Migration

From Qt Wiki
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