1869615fc9
QChar should not be convertible from any integral type except from char16_t, short and possibly char (since it's a direct superset). David provided the perfect example: if (str == 123) { ~~~ } compiles, with 123 implicitly converted to QChar (str == "123" was meant instead). But similarly one can construct other scenarios where QString(123) gets accidentally used (instead of QString::number(123)), like QString s; s += 123;. Add a macro to revert to the implicit constructors, for backwards compatibility. The breaks are mostly in tests that "abuse" of integers (arithmetic, etc.). Maybe it's time for user-defined literals for QChar/QString, but that is left for another commit. [ChangeLog][Potentially Source-Incompatible Changes][QChar] QChar constructors from integral types are now by default explicit. It is recommended to use explicit conversions, QLatin1Char, QChar::fromUcs4 instead of implicit conversions. The old behavior can be restored by defining the QT_IMPLICIT_QCHAR_CONSTRUCTION macro. Change-Id: I6175f6ab9bcf1956f6f97ab0c9d9d5aaf777296d Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> |
||
---|---|---|
.. | ||
qbytearray | ||
qbytearrayapisymmetry | ||
qbytearraylist | ||
qbytearraymatcher | ||
qbytearrayview | ||
qbytedatabuffer | ||
qchar | ||
qcollator | ||
qlatin1string | ||
qlocale | ||
qregularexpression | ||
qstring | ||
qstring_no_cast_from_bytearray | ||
qstringapisymmetry | ||
qstringbuilder | ||
qstringconverter | ||
qstringiterator | ||
qstringlist | ||
qstringmatcher | ||
qstringtokenizer | ||
qstringview | ||
qtextboundaryfinder | ||
.prev_CMakeLists.txt | ||
CMakeLists.txt | ||
text.pro |