>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....@qt-project.org <development-bounces+martin.smith=theqtcompany....@qt-project.org> on behalf of Marc Mutz <marc.m...@kdab.com> Sent: Monday, October 19, 2015 11:23 AM To: development@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.m...@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@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
