return value optimization

[Ankush Bansal]

Rahul Rajat Singh wrote:

"it might break something" (WT Elephant?)

Yes it might break original coder's heart :laugh: I once saw this in production code: :laugh:

bool func(bool check)
{
if(check)
{
if(check)
{
//Double check to be 100% sure
}
}
}

[Jochen Arndt]

The comment is wrong: It must be 200% ;)

[Ankush Bansal]

yes indeed :laugh::rose:

[BobJanova]

It can literally be replaced by 'return retval = flag'. If retval isn't local, changing it to 'return flag' might break something, though it's awful code if that's the case.

[Mohibur Rashid]

but the better code would be if(flag) //skipping creating the ! result return true; return false; [edit] i thought it is better :))))))))))))))))))))))))))))))))))))) [/edit]

[BobJanova]

No, "return flag" is better than this. More words is worse if they add nothing.

[Rahul Rajat Singh]

IMHO, return flag; is still better than this.

[Mohibur Rashid]

oh fuck, i didnt notice the stupidity :))))) sorry guys

[Rahul Rajat Singh]

Its ok. If only this realization would have came to the original developer of this code :-)

[BobJanova]

I guess this coder had seen the double check synchronisation pattern, e.g.

X getSynchronisedSingleCopyOfX(){
if(x == null){
lock(this){
if(x == null) x = new X();
}
}
return x;
}

... (commonly used in singleton instantiation) and didn't understand what the real benefit of the double check in that case was. Or maybe he was just an idiot :-\

[BillW33]

Yes, you must not change the sacred elephant code or you will anger the coding spirits. ;) If they fear making changes to the code then they need unit tests to prove that the code still works after changes. Also, if the code is so brittle that it may break after a small improvement then it needs reviewed and replaced with better code.

Just because the code works, it doesn't mean that it is good code.

[Vasily Tserekh]

haah ai was laughing for about a minute, i remember now i was programming in c++ and i received the following message:"suspicious pointer conversion"

[jsc42]

Actually,

return flag

could be wrong. flag could be a non-Boolean value (e.g. 0 or "" or [not so well known so a major gotcha] '\n' which have a Boolean equivalent of false; whereas most other values have a Boolean equivalent of true). So, to return false for ! flag and true for flag, you should use

return ! ! flag;

. This is a useful trick: the 2nd

!

converts flag (in this case) to a Boolean and negates it (true -> false and false -> true) then the 1st

!

negates it back to what its Boolean equivalent was.

[BobJanova]

Good point, although using a variable name of 'flag' for something which wasn't a boolean would be deserving of headline mention in this forum! Can't you just cast to boolean instead of using !!?

[jsc42]

BobJanova wrote:

Can't you just cast to boolean instead of using !!?

Yes, you could. Casting could be done using

return Boolean(flag);

Note that

return new Boolean(flag);

would return a Boolean object whereas without the new keyword, you'd be casting to a Boolean primitive. Greater clarity could be effected by using the triadic operator:

return flag ? true : false;

or you could use short circuiting, viz

return flag && true;

but using ! ! flag is more succinct. (I noticed yesterday a piece of jQuery that used !1 for false - I wouldn't go that far in obfuscation).