[Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings
Marc Mutz
marc.mutz at kdab.com
Mon Oct 19 11:23:38 CEST 2015
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
More information about the Development
mailing list