>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....@qt-project.org
<development-bounces+martin.smith=theqtcompany....@qt-project.org> on behalf of
Thiago Macieira <thiago.macie...@intel.com>
Sent: Monday, October 19, 2015 5:54 PM
To: development@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@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
