>The point I'm trying to make
>is that returning a non-owning copy means that something else must own the
>data. That's what goes against the library code policy.
The library code policy is an one that has always made sense in the
pre-string_view world. But if string_view is being added to C++, don't we have
to add it to Qt? And if we add it to Qt, don't we have to support it in all the
Qt classes where it could improve performance?
Won't internet-of-things developers want a library that fully supports
string_view?
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 8:21 AM
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 06:10:41 Smith Martin wrote:
> >Return values must always be QString, never QStringView. Returning a view
> >is like returning a reference and goes against Qt's library code policy.
>
> But an assumption is the user manages the ownership of the underlying
> string, so it seems different.
Are you talking about a class that operates on user-provided data?
In that restricted scenario, it might make sense. The point I'm trying to make
is that returning a non-owning copy means that something else must own the
data. That's what goes against the library code policy.
Example:
QUrl url;
QStringView query() const;
It's not possible to write the query() function.
> I'm rewriting the C++ parsing in qdoc. It
> calls a tokenizer that has a token()function that returns an enum value and
> a lexeme() function that returns a QString. It builds the QString for
> lexeme() each time, when it would be better to return a QStringView, since
> I know the text won't change.
Good, but qdoc is not a library so it's not subject to the library code
policy.
> For the names that have to be saved, the
> QStringView can be passed to the tree node constructor, and only one
> QString gets built.
--
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
