[Development] Oslo, we have a problem</apollo 13> [char8_t]
marc at kdab.com
Sat Jul 6 16:09:36 CEST 2019
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
>> 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
> 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?
> Anyway, QByteArray has *Latin1* text-manipulation functions (toUpper
> 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:
> 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.
More information about the Development