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

[Konstantin Ritt]

вс, 7 июл. 2019 г., 12:58 André Hartmann <aha_1980 at gmx.de>:

> Hi Thiago,
>
>  > But QByteArray is encoding-indeterminate since it can carry any type.
>
> Correct, it is often used as "generic raw data array", e.g. in QFile,
> Q*Socket, QSerialPort, QCanBusFrame etc. Here we really need to treat
> the data as-is, without interpretation.
>
>  > Arguably, toUpper() and toLower() should be removed, since
>  >
>  >      QByteArray(u8"Résumé").toLower()
>  > is mojibake.
>
> I vote against that. If you got the "raw" data from a device as
> described above, you might want to do .toHex().toUpper() which is fully
> valid.
>

I'd argue against validity of the `ba.toHex().toUpper()` example, as it
brings false impression that you're operating on a string, where in fact
your intention is to re-code the binary data from one encoded form to
another encoded form (ASCII in this case, and one would have to
`QString::fromLatin1()` it explicitly to manipulate it further).
>From the other hand, `ba.toHex(Uppercase)` enforces the reader to treat it
exactly like an uppercased hex (whatever that means), which is just another
encoding form of the binary data.

As we have string views now, I'd vote for deprecating the string
manipulation methods in QByteArray. I doubt we could make QByteArray a true
vector of bytes now, without breaking lots of the user code, but that could
be a good first step.


Best regards,
Konstantin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190708/dc2c27a5/attachment.html>