[Development] QString and related changes for Qt 6
thiago.macieira at intel.com
Tue May 12 22:32:32 CEST 2020
On Tuesday, 12 May 2020 02:01:45 PDT Edward Welbourne wrote:
> I largely agree, with the exception of: supporting an 8-bit string view
> type for comparisons (including startsWith(), find()/indexOf() and
> similar) can save client code a factor of two on the size of many string
> literals. I'm fine with limiting its use to the QString(View) API,
> though. So QUtf8View would replace QLatin1String as that 8-bit view
> type, with a much more limited scope.
> While we can simply ask folk to stick a u on the front of their strings,
> doubling the size of each, it would be a kindness to those with lots of
> string literals to allow them to use u8 instead and avoid that doubling.
> Meanwhile, the many situations where data from an outside source arrives
> in UTF-8 make a case for providing a view type that can wrap such data
> and make it "presentable" for interaction with QString(View), tagged
> with the right semantics (i.e. the knowledge that it's UTF-8) in the
> type system.
I think we need some more data before we do that. First of all, char8_t
doesn't exist before C++20. u8"" has existed since C++11, but it didn't
produce char8_t literals until C++20. So we have to be careful with
recommending people use it.
The APIs we add using char8_t, if any, will exist with C++20 only. But for Qt,
everything char is already UTF-8, so we don't need char8_t.
The problem with QUtf8View is how it may be used. Unlike QLatin1String, direct
UTF-16-to-UTF-8 comparisons as easy, so the QString methods that would take
QUtf8View are necessarily slower. If space is a constraint but not runtime, it
might be best to just use QString constructor.
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
More information about the Development