On 2019-07-06 14:58, Thiago Macieira wrote:
On Saturday, 6 July 2019 07:43:39 -03 Mutz, Marc via Development wrote:
So, if GCC is right, we have no way of adapting our API to not break
in
C++20. So we need to decide what to break:
a) using 0 for nullptr, or
b) using u8"Hello" at all
When discussing with SG16 folks, the idea was that u8"Hello" would be
an
internal, indeterminate type and would cast to either const char8_t[]
or const
char[] depending on the context. In case of no context (i.e.,
templates, auto)
or of both choices being available, char8_t wins.
Is this not how it's implemented?
Apparently not.
Anyway, QByteArray has *Latin1* text-manipulation functions (toUpper
and
toLower), its split(char) function will happily split on indivdual
bytes of an
UTF-8 multibyte sequence, so adding char8_t overloads seems just wrong
to me.
const char* in Qt is always assumed to be UTF-8-encoded. You need to use
QLatin1String to have it interpreted as Latin-1:
https://doc.qt.io/qt-5/qstring.html#QString-8
https://doc.qt.io/qt-5/qstring.html#QString-7
What did you try to use QByteArray with that showed problems?
Just QByteArray(u8"Hello") already fails when compiled with -std=c++2a.
And this is also why we need to fix it. The same compiles fine in C++17,
and does the expected thing.
Thanks,
Marc
_______________________________________________
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
