D28478: [FileProtocol] change statx stat_dev() to return makedev(major, minor)

[David Faure]

dfaure added a comment.


  In D28478#645702 <https://phabricator.kde.org/D28478#645702>, @ahmadsamir wrote:
  
  > I meant something like:
  >  const int i = foo();
  
  
  int is a very bad example for this reasoning. It's cheaper to copy an int than to use a reference. That's not the case for a non-POD type like UDSEntry.
  
  > the return from foo() is copied into i and then it's gone.
  >  const int &i = foo();
  >  the return from foo() will be stored in a temporary, and it will stay around until i goes out of scope.
  
  Yes.
  
  > So, there's only one "copy" of the return from foo() around, I'd rather take the one stored in i
  
  Yes. The other copy I was referring to is the one that happens *inside* the implementation of foo(), if it doesn't return a const ref and you do "return m_someMember;"
  
  Some people optimize this by using a local const ref, some people return a const ref from foo(). Either one works, but doing both is dangerous, like here.
  In general I'd say the best way is to return a value. Like Qt does everywhere.
  Here I'm a bit unsure (about changing the return type in KF6, can't be done before anyway) because outside unittests we're not supposed to use exec() so there's no risk.

REPOSITORY
  R241 KIO

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

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