[Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[Иван Комиссаров]

Btw, isn't the QStringView is the same as Range<Container>
{ Container::Iterator begin; Container::Iterator end; } ?
Why we introduce only QStringView/QByteArrayView? Maybe we should think
about adding range API to all containers?

Alexandrescus presentation about ranges:
http://www.slideshare.net/rawwell/iteratorsmustgo

2015-10-20 11:56 GMT+03:00 Smith Martin <Martin.Smith at theqtcompany.com>:

> I guess we need QStringView for QString and QByteArrayView for QByteArray,
> etc.
>
> martin
>
> ________________________________________
> From: development-bounces+martin.smith=theqtcompany.com at qt-project.org
> <development-bounces+martin.smith=theqtcompany.com at qt-project.org> on
> behalf of Smith Martin <Martin.Smith at theqtcompany.com>
> Sent: Tuesday, October 20, 2015 9:13 AM
> To: Marc Mutz; development at qt-project.org
> Subject: Re: [Development] RFC: Proposal for a semi-radical change in
>  Qt      APIs taking strings
>
> I see. But then, if I have QStringView, doesn't that eliminate most of the
> reasons for needing the other string containing classes? If I want the
> efficiency of QStringView, won't QString underneath always be the right
> choice?
>
> In Thiago's example, if I have a QStringView API on my class, would I ever
> want to switch the QString to a QByteArray?
>
> Does using QStringView with QString work as well or better than WByteArray
> et al?
>
> martin
>
> ________________________________________
> From: development-bounces+martin.smith=theqtcompany.com at qt-project.org
> <development-bounces+martin.smith=theqtcompany.com at qt-project.org> on
> behalf of Marc Mutz <marc.mutz at kdab.com>
> Sent: Monday, October 19, 2015 11:26 PM
> To: development at qt-project.org
> Subject: Re: [Development] RFC: Proposal for a semi-radical change in
>  Qt      APIs taking strings
>
> On Monday 19 October 2015 21:56:54 Smith Martin wrote:
> > >This API here simply cannot exist because the returned value would be a
> > >dangling reference.
> >
> > I don't understand. Implicit for using the QStringView data() function is
> > knowing that once the QByteArray is set, it is never changed. Then the
> > data() function is ok, isn't it?
>
> A QStringView points to QChar* (or ushort*) while a QByteArray only
> provides
> char*. The fromLatin1() (say) call thus necessary will create a temporary
> QString, which will bind to the returned QStringView, but will already be
> destroyed (taking the data QStringView references with it) when control
> returns to the caller.
>
> This particular mistake is easy to prevent statically, though:
>
>    QStringView(QString &&) = delete;
>
> 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
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20151020/276318f2/attachment.html>