Once in a while I check how the compilers are behaving in such and such situations to make sure that when I wrote code it gets properly optimized. Today I was surprised as I tried to put a break point of a variable and it looked like the compiler wasn't using it. Indeed, the optimizer 100% removed the variable from the final code. Quite interesting since trying to reverse engineer this assembly language would probably end up using a goto statement... (ouch!)

The code goes more or less like this:

  found = false;
  for(idx = 0; idx < max; ++idx) {
    ... do something ...
    if(condition == true) {
      found = true;
      break;
    }
    ... do something else ...
  }
  if(!found) {
    ...
  }

This is the only place where the variable found is used. (This is an important point because some optimization won't be possible if you reuse the same variable over and over again in the same function.)

As you can notice, if the loop ends without finding anything, then the if() block after the loop is executed. To the contrary, if the condition inside the loop is true and the found variable is set to true, then the if() block can be skipped. In other words, the break statement can actually be transformed into a goto AFTER the if() block. This means the variable is not required. Rewritten with a goto, the code would look like this:

  for(idx = 0; idx < max; ++idx) {
    ... do something ...
    if(condition == true) {
      goto got_it;
    }
    ... do something else ...
  }
  // when not found
  ...
got_it:

And as you can see, the need for the found variable can easily be eliminated. Note that when the if() block is true, it can simply be moved right before the break state and similarly, you do not in anyway need the found variable!