[Development] QList
Giuseppe D'Angelo
giuseppe.dangelo at kdab.com
Mon Mar 27 23:53:05 CEST 2017
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 | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - Qt, C++ and OpenGL Experts
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170327/786445e1/attachment.bin>
More information about the Development
mailing list