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

[Smith Martin]

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