>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?
martin
________________________________________
From: development-bounces+martin.smith=theqtcompany....@qt-project.org
<development-bounces+martin.smith=theqtcompany....@qt-project.org> on behalf of
Thiago Macieira <thiago.macie...@intel.com>
Sent: Monday, October 19, 2015 9:38 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 18:38:52 Smith Martin wrote:
> >Again, please try writing this method:
> Doesn't that example just mean there are some classes that can't have a
> QStringView API? A class should have a QStringView API if it can be used
> safely.
Right. I'm simply saying that "if it can be used safely" is very, very
restricted.
Suppose you have in v1:
class Foo
{
QString m_data;
public:
QStringView data() const;
};
Which looks fine and works without dangling references. Then in v2, you need to
do this:
class Foo
{
QByteArray m_data;
public:
QStringView data() const;
};
This API here simply cannot exist because the returned value would be a
dangling reference.
Therefore, QStringView returns must be treated like references: only in
exceptional cases.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
_______________________________________________
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
