[Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings
Smith Martin
Martin.Smith at theqtcompany.com
Tue Oct 20 10:56:24 CEST 2015
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
More information about the Development
mailing list