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

Reply via email to