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
