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 s
>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. I'm rewriting the C++ parsing in qdoc. It calls
On Sunday 18 October 2015 21:27:31 Giuseppe D'Angelo wrote:
> That the proposal is that every single function currently taking a
> QString should instead be changed to take a QStringView instead, unless
> a few exceptional cases (for instance the function is used to store the
> string somehow, p
>If that doesn't look like a radical change to you...
But that's way down the line.
We can add QStringView and overloads that take QStringView without removing the
overloads that take QString.
Then we can deprecate the overloads that take QString.
Fro
Il 18/10/2015 20:30, Smith Martin ha scritto:
After watching the video on string_view, it seems clear we have to offer a QStringView,
so I don't see what is "semi-radical" about your proposal.
That the proposal is that every single function currently taking a
QString should instead be changed
After watching the video on string_view, it seems clear we have to offer a
QStringView, so I don't see what is "semi-radical" about your proposal.
martin
From: development-bounces+martin.smith=theqtcompany@qt-project.org
on behalf of
Marc Mutz
Sen
Hi Martin
After watching https://youtu.be/H9gAaNRoon4 I got a much better picture of
string view. I really recommend to watch it. My understanding is that
qstringview would be a qt implementation of string view and the conversation
cost would be zero.
I find that very promising because it so
>I have not discovered anything. I merely use the existing tools and found that
>APIs outside the core Qt string classes largely ignore them, and probably
>rightfully so, since there's a combinatorical explosion when you combine
>QLatin1String, QString, QStringRef, QChar, const char*, QByteArray
