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

[Smith Martin]

>That's like saying that functions musn't return a QStringRef. But see
>QXmlStreamReader, which uses that to (apparently) good effect.

That's a good point, but the other points you raise are just arguing by finding fault with Qt. I think fully supporting QStringView has to be justified by showing a way to include it in the library so that 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 Marc Mutz <marc.mutz at kdab.com>
Sent: Monday, October 19, 2015 11:23 AM
To: development at qt-project.org
Subject: Re: [Development] RFC: Proposal for a semi-radical change in Qt        APIs taking strings

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.

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.

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.

Safety? Yes, the above QStringLiteral problem and also, as you know (and it's
even documented) that Qt doesn't implement CoW correctly:

  QString s1 = "foo";
  QString::iterator it = s1.begin();
  QString s2 = s1;
  *it = 'b';
  // oops: s2 == "boo", too!

I would like to see proof that ref-counted strings are actually worth it, even
in the unsafe Qt implementation, considering that the C++ world slowly moves
away from them.

Thanks,
Marc

--
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development