[Development] Feature Freeze Exception: QStringView

[Thiago Macieira]

Em terça-feira, 31 de janeiro de 2017, às 12:07:52 PST, Marc Mutz escreveu:
> No, this is not at all about performance. It's mostly about stream-lining
> the API, and adding flexibility:
> 
> 1. Traditionally, a lot of stuff has been taking QString, and QString only.
> If you're lucky, you get (QChar*, int) on top, so you can use an automatic
> buffer to hold the string data, with all the ugliness at the
>    call site that entails. QStringView takes all that pain and hides it
>    (see https://codereview.qt-> project.org/#/c/183925/2/src/corelib/tools/qtimezoneprivate_win.cpp,unified)
> . It also allows for clearer interfaces, because instead of a QString and an
> int, you can just pass a QStringView, since creating a sub-view suddenly
> costs nothing:

But we still have to have QString overloads in public functions, otherwise 
creating full copies would now suddenly cost something.

> 2. QStringView gives the caller the choice of container for string data.
> This makes Qt much more interoperable with 3rd-party libraries. QStringView
> will make QStringLiteral all but obsolete, since you can now just pass
> u"string" or, on Windows, L"string" to any QStringView-taking function. We
> can trivially define a QStringViewLiteral that uses one of the other,
> depending on platform. I backed that feature out, though, since I fist need
> to verify that we support no compilers anymore that would fall back to
> fromUtf8() for QStringLiteral.

There's an interesting advanage for using QStringView on data alloated by 
CoreFramework / Cocoa or by Win32, but since we don't own the data, we have to 
be very careful. In fact, unlike everything else in Qt, QStringView never owns 
the data and that is a major change in how we think.

It was the cause of Thierry's bug yesterday 
https://codereview.qt-project.org/184004

> 3. And yes, performance. Where today we have to return QString, even where
> we know a maximum size, and even where we don't:  It will allow
>    QLocale::toString() to return something equivalent to char16_t[N], e.g.
>    std::array, in order to not allocate memory just to format numbers,
>    something that has so far eluded any practical solution. For internal
>    functions that return temporary QStrings, we can switch to
> QVarLengthArray, and avoid heap allocations in common cases.

I'll study this when the time comes, but first reaction to:

	using NumberString = char16_t[32];
	NumberString toString(int value, bool *ok = nullptr);

Sounds like an awfully ugly API and prone to errors.

> The last such fundamental change to QtBase was the possibility to connect
> signals to lambdas. Believe me, QStringView has the same caliber.

I don't doubt it. Which is why I need more time to review this.

> delay, but for our users, it means half a year delay. Qt is desperately in
> need of better integration with std C++, and QStringView is hand-down the
> largest such contribution. 

Sorry, but I have yet to see any codebase using std::u16string, so I really 
doubt that QStringView allows us better integration with standard library-
based C++.

> Not having it means people will continue to
> spend^Wwaste time porting stuff to QStringRef, which will later be replaced
> by QStringView. Don#t get me wrong, I love the work Anton and others have
> done in the area. I now just need to grep for QStringRef to find code to
> port to QStringView, but the real value of QStringView lies in where there
> was no QStringRef-overload in the first place, e.g. QColor:
> https://codereview.qt-project.org/184038

Indeed, and it's unfortunate.

> I personally don't care whether it goes into 5.9 or 5.10, but for our users
> and for other contributors, I hope that it makes it into 5.9, since, judging
> from 5.8, a lot of internal performance improvements come into stable
> branches, and we really don't need more QStringRef uses in Qt. esp. in
> public API, where we need to carry it all the way to Qt 6.

Our users have used QString for 25 years and QStringRef for 10, so we another 
6 months is not too big a deal.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center