[Development] Feature Freeze Exception: QStringView

[Thiago Macieira]

On terça-feira, 31 de janeiro de 2017 18:53:55 PST Marc Mutz wrote:
> > 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
> 
> This is a bug caused by unclear ownership semantics of QByteArray.
> QStringView has clear ownership semantics, so bugs are much less likely.
> Yes, you have problem with stability of references, but you cannot avoid
> that. Even in Java, an int into a container has the problem that the int
> may get out with the resp. index in the container...

Good point, that's a point in favour of having Q{String,ByteArray}View.

We need to think how that will work with having classes for exclusive 
ownership (not implicitly shared). That's the counterpart of the Views: they 
don't own, but they only have read-only access. I want to provide a solution 
for the mutating operations too.
 
> > 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.
> 
> This does not compile. I was thinking about a QFormattedNumber<T>, which
> would contain a buffer of sufficient size to hold the result, and implicit
> converstions to QString, QStringView.

Ok. And since we don't subscribe to "Almost Always Auto", we won't be bitten 
by:

	auto str = locale.toString(value);
	if (str.startsWith('0'))

> > 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++.
> 
> u"string". The only reason we don't use that, yet, is that MSVC < 2015
> doesn't support it. Let's drop 2013 in 5.10 and we can replace all
> QStringLiterals with char16_t string literals.

The reason we don't really use QStringLiterals is the design of QStringData. 
It has a 16- or 24-byte overhead.

If I had finished[*] my new QString/QVector/QByteArray for 5.0, we could have 
because the overhead would have been much smaller: exactly the same as 
u"string". See how there's no static in:

https://github.com/thiagomacieira/qtbase/blob/master/src/corelib/tools/
qstring.h#L177

[*] actually, I had finished it, and I've kept a series of patches to QtQml and 
the Qt Creator debug dumpers to keep it working. I just didn't want to delay 
5.0 further at the time.

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