On 2019-07-08 04:43, Thiago Macieira wrote:
On Sunday, 7 July 2019 23:26:40 -03 Konstantin Ritt wrote:
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.
We don't have any good 8-bit string manipulation functions outside of
QByteArray. They stay.
The question is whether the Latin1 methods (toUpper(), toLower() and
the free
function qstricmp) should be moved or removed. Those would work really
well in
QLatin1String, but QLatin1String is a view, since it doesn't own the
data.
QLatin1String::toUpper() could return a QByteArray...
What I think when I read this is:
Backed by const char*, never implicit:
- QLatin1String - owner of L1 data [change from today, but not a
breaking one]
- QLatin1StringView - what QLatin1String is now [requires porting, but
it's just s/QLatin1String/QLatin1StringView/g in client code]
Backed by const char8_t*, implicit:
- QUtf8String - owner of UTF-8 data
- QUtf8StringView - view over UTF-8 data
Backed by const char16_t*, implicit (from char16_t*, Q*StringView, NOT
from QByteArray)
- QString - owner of UTF-16 data [as before, possibly using char16_t
internally to avoid the tons of ushort casts]
- QStringView - view over UTF-16 data
Backed by const std::byte*, implicit:
- QByteArray - owner of std::byte data, no string-like functions
[breaking change, but anyway far in the future, as we can't depend on
std::byte, yet]
- QByteArrayView - view over std::byte (uchar, char, ...) data.
QByteArray, QUtf8String and QLatin1String(new) could use the same
backend, for zero-copy transformations between them.
Is this a realistic goal for Qt 7? Last time I proposed
QUtf8String/View, it's usefulness was challenged. I think the advent of
char8_t in C++20 and std::byte in C++17 change the game quite a bit,
though.
I'm also looking at all the relational operators we have between our
string-like classes, and it's ... frightening. Using views to define
relations would allow to cut quite a lot of relational operator
overloads.
Thanks,
Marc
_______________________________________________
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
