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.sm...@theqtcompany.com>: > I guess we need QStringView for QString and QByteArrayView for QByteArray, > etc. > > martin > > ________________________________________ > From: development-bounces+martin.smith=theqtcompany....@qt-project.org > <development-bounces+martin.smith=theqtcompany....@qt-project.org> on > behalf of Smith Martin <martin.sm...@theqtcompany.com> > Sent: Tuesday, October 20, 2015 9:13 AM > To: Marc Mutz; development@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....@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:26 PM > To: development@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.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 > _______________________________________________ > 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
