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

[Smith Martin]

>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