[Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings
Smith Martin
Martin.Smith at theqtcompany.com
Mon Oct 19 09:14:55 CEST 2015
>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.com at qt-project.org <development-bounces+martin.smith=theqtcompany.com at qt-project.org> on behalf of Thiago Macieira <thiago.macieira at intel.com>
Sent: Monday, October 19, 2015 8:21 AM
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 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 at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
More information about the Development
mailing list