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
