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
