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

Bubke Marco Marco.Bubke at theqtcompany.com
Mon Oct 19 22:31:53 CEST 2015


On October 19, 2015 21:38:51 Thiago Macieira <thiago.macieira at intel.com> 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 at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Sent from cellphone 



More information about the Development mailing list