Il 27/03/2017 22:56, Thiago Macieira ha scritto: > On segunda-feira, 27 de março de 2017 11:14:24 PDT Giuseppe D'Angelo wrote: >> If we can't make it an alias, can we start adding extra functions for >> the various QStringRef *ref() methods (in QXmlStreamReader, >> QRegularExpressionMatch, probably elsewhere too), returning QStringView? > > Never return QStringView in our API. It's as bad as returning a const > reference. > > In fact, that's a good rule of thumb: if you could have used a const QString > & > in that function, you can use QStringView. Otherwise, return QString by value.
Why should it bad if what you want return is precisely a "const reference" over QString-like data? Isn't that the whole reason why we have functions returning QStringRef right now (lacking a QStringView)? (And also the reason why QStringView itself returns QStringViews?) Example of use case: a tokenizer operating over QString-like data, returning each token as a QStringView, with no memory allocations -- possibly even noexcept (narrow contract on the source string). Why would I want to return QStrings for this use case and super-pessimize it? Cheers, -- Giuseppe D'Angelo | [email protected] | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts
smime.p7s
Description: Firma crittografica S/MIME
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
