On October 19, 2015 21:38:51 Thiago Macieira <thiago.macie...@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@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
