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

[Smith Martin]

>Again, please try writing this method:

Doesn't that example just mean there are some classes that can't have a QStringView API? A class should have a QStringView API if it can be used safely.

martin

________________________________________
From: development-bounces+martin.smith=theqtcompany.com at qt-project.org <development-bounces+martin.smith=theqtcompany.com at qt-project.org> on behalf of Thiago Macieira <thiago.macieira at intel.com>
Sent: Monday, October 19, 2015 5:54 PM
To: development at qt-project.org
Subject: Re: [Development] RFC: Proposal for a semi-radical change in Qt        APIs taking strings

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

_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development