if - else vs if and returns revisited (not asking about multiple returns ok or not)

Question

With regards this example from Code Complete:

Comparison Compare(int value1, int value2)
{
if ( value1 < value2 )
 return Comparison_LessThan;
else if ( value1 > value2 )
 return Comparison_GreaterThan;
else
 return Comparison_Equal;
}

You could also write this as:

Comparison Compare(int value1, int value2)
{
 if ( value1 < value2 )
  return Comparison_LessThan;

 if ( value1 > value2 )
  return Comparison_GreaterThan;

 return Comparison_Equal;
}

Which is more optimal though? (readability, etc aside)

Answer 1

Readability aside, the compiler should be smart enough to generate identical code for both cases.

Answer 2

It will really depend on your compiler inferring what you are trying to do and placing the "jumps" or not. It is trivial.

Answer 3

In case there is a return statement, there is no difference.

Using else in these cases may just stop you from checking the second condition in case you enter the first if. But the performance difference should be really slow, unless you have a condition that takes long to check.

Answer 4

"Readability, etc aside" I'd expect the compiler to produce identical code from each of them.

You can test that though, if you like: your C++ compiler probably has an option to generate a listing file, so you can see the assembly/opcodes generated from each version ... or, you can see the assembly/opcodes by using your debugger to inspect the code (after you start the executable).

Answer 5

This will generate identical code in just about any compiler... (GCC, visual studio, etc). Compilers work on a little bit different logic then we do. If's become if!... meaning that in both cases it would just fall through to that last return statement.

Edit: More generally, the else statement is just there for the human, it actually doesn't generate anything on most compilers... this is true in your case and just about anything else using the if... else... construct.

Answer 6

The two code samples should compile identically on modern compilers, whether optimizations are turned on or off. The only chance you may encounter something different is if you use an old compiler that doesn't recognize that it's going to write inefficient code (most likely, unused code).

If you're worried about optimizations, you might consider taking a look at the algorithm being used.

Answer 7

The compiler generates identical code. One of the most basic things the compiler does is to build a control graph. Basically, "standing at node X, which nodes can I get to", and then it inserts jump statements for these reachable nodes.

And in your case, the control graph is exactly the same in both cases.

(Of course this is a gross simplification, and the compiler does a lot more before actually generating any actual code)

Answer 8

Readability is the correct answer. Any compiler will produce equivalent code to within a cycle or two, and an optimizer will have no problems parsing and sorting the control flow, either.

That's why readability is more important. Your cost of this code isn't just in writing it and compiling it today. It may have to be maintained in the future by you or someone else. You want your code to be readable so that the next maintainer will not have to waste a lot of time trying to understand it.

<underwear fabric="asbestos"> Not all coding style decisions should be made solely on "efficiency" or cycle count. </underwear> Should you write inefficient code? Of course not. But let the optimizer handle the tiny questions when it can. You're more valuable than that.

Answer 9

Just execute gcc -S to see at generated assembler code, it should be identical. Anyway you could answer yourself by executing each 1000000 times and measuring execution time.