[Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[Thiago Macieira]

On Monday 19 October 2015 11:23:38 Marc Mutz wrote:
> On Sunday 18 October 2015 22:55:23 Thiago Macieira wrote:
> > On Sunday 18 October 2015 21:27:31 Giuseppe D'Angelo wrote:
> > > That the proposal is that every single function currently taking a
> > > QString should instead be changed to take a QStringView instead, unless
> > > a few exceptional cases (for instance the function is used to store the
> > > string somehow, plus other cases under discussion). Similar case for
> > > return values. If that doesn't look like a radical change to you...
> > 
> > Return values must always be QString, never QStringView. Returning a view
> > is  like returning a reference and goes against Qt's library code policy.
> 
> That's like saying that functions musn't return a QStringRef. But see
> QXmlStreamReader, which uses that to (apparently) good effect.

No, it isn't.

First of all, QStringRef keeps a pointer to the original QString, so it isn't 
as fragile as QStringView. In fact, during the development of the XML stream 
classes, there was a QSubString class that did more or less what QStringView 
would do. It got replaced for a reason.

Second, this falls under the exception of parsing a large block of data and 
getting information about chunks inside.

And besides, it does make code using those classes uglier.

> I also mentioned the case where a plugin returns some static data as a
> QString coming from a QStringLiteral. You yourself mentioned that that's
> going boom when the plugin is unloaded. If the plugin instead returned a
> QStringView, then callers wishing to store the result would have toString()
> it, making a deep copy and insulating themselves from the plugin being
> unloaded, while users wishing to just do some mix-and-matching with the
> string could avoid the copy by keeping the returned data in a QStringView.

I agree on the advantage.

>From what I can see, a Qt6 QStringView is a QString with a null d pointer, 
except that it triggers deep copy everywhere whre it's assigned to a regular 
QString. I'm fine with having the class.

I'm not ok with changing the library code policy.

> People should stop being so afraid of a string deep copy. It's a no-op for
> SSO'ed strings and according to Herb Sutter's benchmark on average doesn't
> matter for all other strings. Here's where safety and performance could
> actually go hand-in-hand for once.

That's not what I am afraid of.

Again, please try writing this method:

class Foo
{
	QUrl url;
public:
	QStringView host() const;
};


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