[Development] Oslo, we have a problem</apollo 13> [char8_t]
thiago.macieira at intel.com
Sat Jul 6 18:59:54 CEST 2019
On Saturday, 6 July 2019 11:09:36 -03 Mutz, Marc via Development wrote:
> > 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:
That's QString, not QByteArray.
But QByteArray is encoding-indeterminate since it can carry any type.
Arguably, toUpper() and toLower() should be removed, since
In fact, QByteArray should use std::byte in functions like data(), but that's
unwieldy and breaks too much compatibility.
> > 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.
I think we need to talk to SG16.
We can add the template overloads to all functions so we can take char,
unsigned char, std::byte and char8_t without complaining. I am with you that
this could result in explosive compile times. But it also does not solve
the problem of what type data() / constData() and the iteration functions
I wouldn't mind a udata() function anyway, since there's a lot of code dealing
with "bytes" as unsigned char. Are we willing to add ubegin() and begin8()
 Please, no one say "Modules!" here, it's not a full solution, even if we
can use them in Qt 6's lifetime.
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
More information about the Development