[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