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

[Ahmad Samir]

ahmadsamir added a comment.


  In D28478#645717 <https://phabricator.kde.org/D28478#645717>, @dfaure wrote:
  
  > 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.
  
  
  Yep.
  
  >> 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.
  
  hmm... so one needs to know whether foo() returns a value or a const &; if I don't know for sure, then use a non-ref LHS to be on the safe side.
  
  > 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.
  
  And the docs there say explicitly "call this from a slot connected to result()"...

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/ba8ff6e2/attachment.html>