[Development] Oslo, we have a problem</apollo 13> [char8_t]

Thiago Macieira thiago.macieira at intel.com
Sat Jul 6 14:58:53 CEST 2019


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?

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.

What did you try to use QByteArray with that showed problems?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products





More information about the Development mailing list