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

[Marc Mutz]

On Sunday 18 October 2015 22:55:23 Thiago Macieira wrote:
> 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, plus other cases under discussion). Similar case for 
> > return values. If that doesn't look like a radical change to you...
> 
> Return values must always be QString, never QStringView. Returning a view
> is  like returning a reference and goes against Qt's library code policy.

That's like saying that functions musn't return a QStringRef. But see 
QXmlStreamReader, which uses that to (apparently) good effect.

I also mentioned the case where a plugin returns some static data as a QString 
coming from a QStringLiteral. You yourself mentioned that that's going boom 
when the plugin is unloaded. If the plugin instead returned a QStringView, 
then callers wishing to store the result would have toString() it, making a 
deep copy and insulating themselves from the plugin being unloaded, while 
users wishing to just do some mix-and-matching with the string could avoid the 
copy by keeping the returned data in a QStringView.

People should stop being so afraid of a string deep copy. It's a no-op for 
SSO'ed strings and according to Herb Sutter's benchmark on average doesn't 
matter for all other strings. Here's where safety and performance could 
actually go hand-in-hand for once.

Safety? Yes, the above QStringLiteral problem and also, as you know (and it's 
even documented) that Qt doesn't implement CoW correctly:

  QString s1 = "foo";
  QString::iterator it = s1.begin();
  QString s2 = s1;
  *it = 'b';
  // oops: s2 == "boo", too!

I would like to see proof that ref-counted strings are actually worth it, even 
in the unsafe Qt implementation, considering that the C++ world slowly moves 
away from them.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Smith Martin]

>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 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. For the names that have to be saved, the QStringView can be passed to 
the tree node constructor, and only one QString gets built.

martin

From: development-bounces+martin.smith=theqtcompany@qt-project.org 
 on behalf of 
Thiago Macieira 
Sent: Sunday, October 18, 2015 10:55 PM
To: development@qt-project.org
Subject: Re: [Development] RFC: Proposal for a semi-radical change in Qt
APIs taking strings

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, plus other cases under discussion). Similar case for
> return values. If that doesn't look like a radical change to you...

Return values must always be QString, never QStringView. Returning a view is
like returning a reference and goes against Qt's library code policy.

--
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

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

[Thiago Macieira]

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

Re: [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@qt-project.org 
 on behalf of 
Thiago Macieira 
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

Re: [Development] Updating the minimal supported version of libxcb

[Александр Волков]

16.10.2015 18:18, Paeglis Gatis пишет:
>> Another question is what to do with the bundled libraries?
> The -qt-xcb switch is there to reduce run-time dependencies. There always 
> will be somebody who wants
> to run the latest Qt version on some old linux distribution.
>
> Also I think it was decided that in Qt5 we can remove support for 
> -no-x11extenssion-name switches in the Qt
> configure script. There is always -qt-xcb available if your distro does not 
> provide the required dependencies. And it does not add any value not to 
> compile-in the extension code. It should be a runtime decision, if X server 
> has an extension available, we use it.
>

If someone wants to run the latest Qt on some old distro, then he can 
build missing libraries
xcb-util, xcb-util-image, xcb-util-keysyms, xcb-util-renderutil, 
xcb-util-wm.
They all build well even with libxcb 1.5.

Actually xcb-randr, xcb-render, xcb-shape, xcb-shm, xcb-sync and 
xcb-xfixes were bundled to
bundle these xcb-util* libraries. It was reasonable when they were not 
present in distros,
but now it's bad because a Qt-based app can also use system xcb libs. 
And who knows
what bugs this mix of bundled and system libs can produce.

Bundling libxcb libraries also complicates using them from different 
platform plugins.
The xcb plugin and the offscreen plugin use glxconvenience functions 
which depend on
libXrender. We could avoid this dependency by rewriting the code to use 
xcb-render and
linking with the shared system library, but...

So if we really want to support people with libxcb 1.5, the we can still 
patch the bundled xcb-xkb,
but IMO dropping other bundled xcb libs is a good thing.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Smith Martin]

>That's like saying that functions musn't return a QStringRef. But see
>QXmlStreamReader, which uses that to (apparently) good effect.

That's a good point, but the other points you raise are just arguing by finding 
fault with Qt. I think fully supporting QStringView has to be justified by 
showing a way to include it in the library so that it can be used safely.

martin


From: development-bounces+martin.smith=theqtcompany@qt-project.org 
 on behalf of 
Marc Mutz 
Sent: Monday, October 19, 2015 11:23 AM
To: development@qt-project.org
Subject: Re: [Development] RFC: Proposal for a semi-radical change in Qt
APIs taking strings

On Sunday 18 October 2015 22:55:23 Thiago Macieira wrote:
> 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, plus other cases under discussion). Similar case for
> > return values. If that doesn't look like a radical change to you...
>
> Return values must always be QString, never QStringView. Returning a view
> is  like returning a reference and goes against Qt's library code policy.

That's like saying that functions musn't return a QStringRef. But see
QXmlStreamReader, which uses that to (apparently) good effect.

I also mentioned the case where a plugin returns some static data as a QString
coming from a QStringLiteral. You yourself mentioned that that's going boom
when the plugin is unloaded. If the plugin instead returned a QStringView,
then callers wishing to store the result would have toString() it, making a
deep copy and insulating themselves from the plugin being unloaded, while
users wishing to just do some mix-and-matching with the string could avoid the
copy by keeping the returned data in a QStringView.

People should stop being so afraid of a string deep copy. It's a no-op for
SSO'ed strings and according to Herb Sutter's benchmark on average doesn't
matter for all other strings. Here's where safety and performance could
actually go hand-in-hand for once.

Safety? Yes, the above QStringLiteral problem and also, as you know (and it's
even documented) that Qt doesn't implement CoW correctly:

  QString s1 = "foo";
  QString::iterator it = s1.begin();
  QString s2 = s1;
  *it = 'b';
  // oops: s2 == "boo", too!

I would like to see proof that ref-counted strings are actually worth it, even
in the unsafe Qt implementation, considering that the C++ world slowly moves
away from them.

Thanks,
Marc

--
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
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

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

[Matthew Woehlke]

On 2015-10-16 19:52, Kurt Pattyn wrote:
> On 17 Oct 2015, at 01:18, Marc Mutz wrote:
>> I find it intolerable that todays software takes 1000x the memory,
>>  1000x the CPU capacity and doesn't get a given jobs done in less
>> wallclock time than software 20 years ago.
>
> These are 'numbers'. Is it like that? Really 1000x the memory, 1000x the CPU 
> capacity?

Er... yes?

An 80286 of yesteryear ran as fast as 25 MHz¹. A modern, 6-core 4 GHz
CPU has a "theoretical" 24 GHz of "computing power". That's almost
exactly 1000x (more, considering the ISA improvements). The same machine
could address up to 16 MiB of RAM. A lot of machines around my office
have 16 GiB of RAM (my home desktop has more; OTOH, many home machines
have less). That's pedantically a factor of 1024x; again, close enough.

Basically, yeah... computers some 10-20 years ago had similar specs as
modern computers - CPU speed in the single to low double digits, memory
in similar ranges - except the numbers were in one 1000/1024-order of
magnitude less units (MHz vs. GHz, MiB vs. GiB). The increase in disk
space is, if anything, even more extreme.

There remains, of course, *some* exaggeration there... modern computers
are, after all, tackling quantities of data that computers 20 years ago
couldn't dream of touching (consider any process run on large clusters,
for example). Even so, it's sobering to think about, especially as a lot
of user software is "prettier" but in many ways not actually *better*,
at least not in proportion to the increase in resource requirements.

(¹ https://en.wikipedia.org/wiki/Intel_80286)

-- 
Matthew

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On Monday 19 October 2015 11:23:38 Marc Mutz wrote:
> On Sunday 18 October 2015 22:55:23 Thiago Macieira wrote:
> > 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, plus other cases under discussion). Similar case for
> > > return values. If that doesn't look like a radical change to you...
> > 
> > Return values must always be QString, never QStringView. Returning a view
> > is  like returning a reference and goes against Qt's library code policy.
> 
> That's like saying that functions musn't return a QStringRef. But see
> QXmlStreamReader, which uses that to (apparently) good effect.

No, it isn't.

First of all, QStringRef keeps a pointer to the original QString, so it isn't 
as fragile as QStringView. In fact, during the development of the XML stream 
classes, there was a QSubString class that did more or less what QStringView 
would do. It got replaced for a reason.

Second, this falls under the exception of parsing a large block of data and 
getting information about chunks inside.

And besides, it does make code using those classes uglier.

> I also mentioned the case where a plugin returns some static data as a
> QString coming from a QStringLiteral. You yourself mentioned that that's
> going boom when the plugin is unloaded. If the plugin instead returned a
> QStringView, then callers wishing to store the result would have toString()
> it, making a deep copy and insulating themselves from the plugin being
> unloaded, while users wishing to just do some mix-and-matching with the
> string could avoid the copy by keeping the returned data in a QStringView.

I agree on the advantage.

>From what I can see, a Qt6 QStringView is a QString with a null d pointer, 
except that it triggers deep copy everywhere whre it's assigned to a regular 
QString. I'm fine with having the class.

I'm not ok with changing the library code policy.

> People should stop being so afraid of a string deep copy. It's a no-op for
> SSO'ed strings and according to Herb Sutter's benchmark on average doesn't
> matter for all other strings. Here's where safety and performance could
> actually go hand-in-hand for once.

That's not what I am afraid of.

Again, please try writing this method:

class Foo
{
QUrl url;
public:
QStringView host() const;
};


-- 
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

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

[Thiago Macieira]

On Monday 19 October 2015 07:14:55 Smith Martin wrote:
> >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?

I don't think that string_view makes a difference. The point is still the same: 
returning non-owning copies of data implies something else owns it. We haven't 
done that so far and I don't think string_view should change the policy.

> 
> Won't internet-of-things developers want a library that fully supports
> string_view?

-- 
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

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

[Marc Mutz]

On Monday 19 October 2015 21:56:54 Smith Martin wrote:
> >This API here simply cannot exist because the returned value would be a 
> >dangling reference.
> 
> I don't understand. Implicit for using the QStringView data() function is
> knowing that once the QByteArray is set, it is never changed. Then the
> data() function is ok, isn't it?

A QStringView points to QChar* (or ushort*) while a QByteArray only provides 
char*. The fromLatin1() (say) call thus necessary will create a temporary 
QString, which will bind to the returned QStringView, but will already be 
destroyed (taking the data QStringView references with it) when control 
returns to the caller.

This particular mistake is easy to prevent statically, though:

   QStringView(QString &&) = delete;

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Bubke Marco]

On October 19, 2015 21:38:51 Thiago Macieira  wrote:

> On Monday 19 October 2015 18:38:52 Smith Martin wrote:
>> >Again, please try writing this method:
>> Doesn't that example just mean there are some classes that can't have a
>> QStringView API? A class should have a QStringView API if it can be used
>> safely.
>
> Right. I'm simply saying that "if it can be used safely" is very, very 
> restricted.
>
> Suppose you have in v1:
>
> class Foo
> {
>   QString m_data;
> public:
>   QStringView data() const;
> };
>
> Which looks fine and works without dangling references. Then in v2, you need 
> to 
> do this:
>
> class Foo
> {
>   QByteArray m_data;
> public:
>   QStringView data() const;
> };

How can you make a QStringView from a byte array? I know we abuse byte array as 
utf8 class but if you convert it you have no ownership of the created QString. 
Do you do a reinterpret cast? ;-) 

I see QStringView as const QString & but much more explicit and portable. So 
maybe you want to show that people can return a string view of a temporary? We 
can add a error in the clang code model so it should be a non issue. 

I think we should develop and use better tools which warn you about mistakes 
like that. That makes C++ much easier. ;-) 

Today I spoke with Ossi about the integration in gerrit too. So if you have 
enough firewalls we can be much more liberal in what we can use. 

For example the highlighting can show that the parameter is an in or in/out 
parameter so you don't need to use pointers anymore for in/out parameters etc. 
But it is getting off topic. 

> This API here simply cannot exist because the returned value would be a 
> dangling reference.
>
> Therefore, QStringView returns must be treated like references: only in 
> exceptional cases.
>
> -- 
> 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
Sent from cellphone 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On Monday 19 October 2015 18:38:52 Smith Martin wrote:
> >Again, please try writing this method:
> Doesn't that example just mean there are some classes that can't have a
> QStringView API? A class should have a QStringView API if it can be used
> safely.

Right. I'm simply saying that "if it can be used safely" is very, very 
restricted.

Suppose you have in v1:

class Foo
{
QString m_data;
public:
QStringView data() const;
};

Which looks fine and works without dangling references. Then in v2, you need to 
do this:

class Foo
{
QByteArray m_data;
public:
QStringView data() const;
};

This API here simply cannot exist because the returned value would be a 
dangling reference.

Therefore, QStringView returns must be treated like references: only in 
exceptional cases.

-- 
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

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

[Smith Martin]

>Again, please try writing this method:

Doesn't that example just mean there are some classes that can't have a 
QStringView API? A class should have a QStringView API if it can be used safely.

martin


From: development-bounces+martin.smith=theqtcompany@qt-project.org 
 on behalf of 
Thiago Macieira 
Sent: Monday, October 19, 2015 5:54 PM
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 11:23:38 Marc Mutz wrote:
> On Sunday 18 October 2015 22:55:23 Thiago Macieira wrote:
> > 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, plus other cases under discussion). Similar case for
> > > return values. If that doesn't look like a radical change to you...
> >
> > Return values must always be QString, never QStringView. Returning a view
> > is  like returning a reference and goes against Qt's library code policy.
>
> That's like saying that functions musn't return a QStringRef. But see
> QXmlStreamReader, which uses that to (apparently) good effect.

No, it isn't.

First of all, QStringRef keeps a pointer to the original QString, so it isn't
as fragile as QStringView. In fact, during the development of the XML stream
classes, there was a QSubString class that did more or less what QStringView
would do. It got replaced for a reason.

Second, this falls under the exception of parsing a large block of data and
getting information about chunks inside.

And besides, it does make code using those classes uglier.

> I also mentioned the case where a plugin returns some static data as a
> QString coming from a QStringLiteral. You yourself mentioned that that's
> going boom when the plugin is unloaded. If the plugin instead returned a
> QStringView, then callers wishing to store the result would have toString()
> it, making a deep copy and insulating themselves from the plugin being
> unloaded, while users wishing to just do some mix-and-matching with the
> string could avoid the copy by keeping the returned data in a QStringView.

I agree on the advantage.

>From what I can see, a Qt6 QStringView is a QString with a null d pointer,
except that it triggers deep copy everywhere whre it's assigned to a regular
QString. I'm fine with having the class.

I'm not ok with changing the library code policy.

> People should stop being so afraid of a string deep copy. It's a no-op for
> SSO'ed strings and according to Herb Sutter's benchmark on average doesn't
> matter for all other strings. Here's where safety and performance could
> actually go hand-in-hand for once.

That's not what I am afraid of.

Again, please try writing this method:

class Foo
{
QUrl url;
public:
QStringView host() const;
};


--
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

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

[Smith Martin]

>This API here simply cannot exist because the returned value would be a 
>dangling reference.

I don't understand. Implicit for using the QStringView data() function is 
knowing that once the QByteArray is set, it is never changed. Then the data() 
function is ok, isn't it?

martin


From: development-bounces+martin.smith=theqtcompany@qt-project.org 
 on behalf of 
Thiago Macieira 
Sent: Monday, October 19, 2015 9:38 PM
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 18:38:52 Smith Martin wrote:
> >Again, please try writing this method:
> Doesn't that example just mean there are some classes that can't have a
> QStringView API? A class should have a QStringView API if it can be used
> safely.

Right. I'm simply saying that "if it can be used safely" is very, very
restricted.

Suppose you have in v1:

class Foo
{
QString m_data;
public:
QStringView data() const;
};

Which looks fine and works without dangling references. Then in v2, you need to
do this:

class Foo
{
QByteArray m_data;
public:
QStringView data() const;
};

This API here simply cannot exist because the returned value would be a
dangling reference.

Therefore, QStringView returns must be treated like references: only in
exceptional cases.

--
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

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

[Olivier Goffart]

On Monday 19. October 2015 23:26:45 Marc Mutz wrote:
> This particular mistake is easy to prevent statically, though:
> 
>QStringView(QString &&) = delete;

No.

We want this to work:

 if (isValidIdentifier(myVariant.toString()))

with isValidIdentifier taking a QStringView and toString returning a 
temporary.

-- 
Olivier 

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On Tuesday 20 October 2015 00:51:58 Olivier Goffart wrote:
> On Monday 19. October 2015 23:26:45 Marc Mutz wrote:
> > This particular mistake is easy to prevent statically, though:
> > 
> >QStringView(QString &&) = delete;
> 
> No.
> 
> We want this to work:
> 
>  if (isValidIdentifier(myVariant.toString()))
> 
> with isValidIdentifier taking a QStringView and toString returning a 
> temporary.

That can be mitigated by overloading isValidIdentifier with a QString &&. That 
is:

bool isValidIdentifier(QString &);
bool isValidIdentifier(const QStringView );

The first one can delegate to the second, as inside it the id parameter is 
lvalue, not rvalue. That is:

bool isValidIdentifier(QString &) 
{ return isValidIdentifier(QStringView(id)); }

Note that this overload is not necessary for existing APIs where a const 
QString& overload is already present, as that will bind to the rvalue just 
fine.

So is there any case where we'd want a QString&& overload instead of a const 
QString &?

-- 
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

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

[Thiago Macieira]

On Monday 19 October 2015 20:31:53 Bubke Marco wrote:
> On October 19, 2015 21:38:51 Thiago Macieira  
wrote:
> > Right. I'm simply saying that "if it can be used safely" is very, very
> > restricted.
> > 
> > Suppose you have in v1:
> > 
> > class Foo
> > {
> > QString m_data;
> > public:
> > QStringView data() const;
> > };
> > 
> > Which looks fine and works without dangling references. Then in v2, you
> > need to do this:
> > 
> > class Foo
> > {
> > QByteArray m_data;
> > public:
> > QStringView data() const;
> > };
> 
> How can you make a QStringView from a byte array? 

That's exactly the point. It was a tricky question and this is exactly the 
gotcha. You cannot. Therefore, the API must not be permitted, save for 
exceptional cases where you know the internal backing will NEVER EVER change 
(until the next source compatibility change, at the soonest).

So the summary of QStringView is:
 a) never used as return type
 b) used only as a parameter if the function processes the data and never 
 stores it and will never, ever store it (lazy processing)
 c) for existing API, needs to be overloaded with QString

I'm not buying the cost/benefit ratio.

-- 
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