D25039: Fix Clazy performance issues, const &

[Ahmad Samir]

ahmadsamir added inline comments.

INLINE COMMENTS

> kossebau wrote in ftp.cpp:1376
> `QUrl::fileName()` returns a value QString, so just
> 
>   const QString filename = empurl.fileName();
> 
> While
> 
>   const QString &filename = empurl.fileName();
> 
> also is fine code IIRC, as I once learned to my surprise,  as the `const QString &` here means to tell the compiler the actual value instance should be hold only until the last use of the variable, not the end of the scope in which the variable exists, this seems also not well known by others, so might only make them confuse.
> Given this is an optimization not needed here, IMHO no need to use this technique here.

IIUC, the compiler will use a temporary object to hold the return of tempurl.fileName().

The temporary is used to initialize filename, and then it's gone:
const QString filename = tempurl.filename();

filename here is a reference-to-const to the temporary object and the temporary will have the same lifetime as the reference (for objects on the stack), so until the end of the scope:
const QString &filename = tempurl.fileName();
c.f. https://herbsutter.com/2008/01/01/gotw-88-a-candidate-for-the-most-important-const/

In my mind it kind of makes more sense to use a reference-to-const when the rvalue (tempurl.fileName()) is not a temporary object, because I am saving nothing by using a reference here since the compiler will create the temporary object and hold it until the end of the scope anyway.

In this particular case, it's probably exactly the same whether the temporary is used to initialize a const non-reference object and then (the temporary) is dropped/gone or the object being initialized is a reference to const to the temporary until the end of the scope...

job->statResult() and job->url() are different because both of them return a reference to const.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D25039

To: meven, #frameworks, dfaure
Cc: ahmadsamir, anthonyfieroni, kossebau, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20191031/69310f90/attachment-0001.html>