On Thursday 09 February 2017 18:14:47 Olivier Goffart wrote: > On Donnerstag, 9. Februar 2017 17:32:42 CET Marc Mutz wrote: > > On Thursday 09 February 2017 10:41:05 Marc Mutz wrote: > > > AFAICT, (2) could only possibly affect ICC and VxWorks. > > > > From the change set: > > > > - VxWorks uses GCC 4.8, that's enough. > > - The ICC minimum version since Qt 5.7 (cf. dist/changes-5._6_.0) is v14 > > > > (Unicode string literals were added for 12.1), so enough, too. > > > > For MSVC 2013, we have the wchar_t workaround (assuming all MSVC have > > sizeof(wchar_t) == 2? The ifdefs seem to suggest otherwise...). > > > > So, I'd like to propose this patch for 5.8, then (5.7 being closed and > > 5.6 not requiring enough compiler support). > > If I look at the table from https://codereview.qt-project.org/178906 , it > could be classified as "Using new C++ features" or "Enabling new compiler > features" or "Refactoring: non-test code". Maybe to "Performance: Issue > related to best practices", all of them point to "dev". > Why do you think this change should go in another branch? > > Maybe it could be classified under "Bugs: Other", but i don't think it > fixes a bug.
For the vast majority of configurations, nothing will change. The only platform I'm aware of that that patch would change is QNX < 7. This platform has a compiler (GCC) capable of char16_t, but lacks stdlib support for it, presumably std::u16string etc. But QStringLiteral only needs the u"string" feature, which is a core language feature. So one could say that it's a fix for a serious performance bug for QStringLiteral on QNX. Fixing that allows us to up the guarantees for QStringLiteral: it will be non-allocating and nothrow on all supported platforms. I can rephrase the commit message to degrade this into a QNX-only fix, so it becomes acceptable for 5.8, but the fact that fixing the last platform to still use the fromUtf8() to not do so is, imho, better expressed as "drop the fromUtf8() fallback", because it has ramifications outside QNX code: QStringLiteral(...).constData() is now stable, e.g. Thanks, Marc -- Marc Mutz <[email protected]> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
