Are the if-else ... if-else ... if-else block checked in the order in which they were written?

Question

Is there any guarantee that the ifs of the if-else if-else if-else block are checked in the order in which they were written.

I ask about this because I often try to optimize my code by setting the most common cases, and I want to know if some optimizations made by the compiler can change the order in which if is tested.

So, if I write this code:

  if (cond1) // First if (for the case I have the most often) { doSomething1(); } else if (cond2) // Second if (for the second case I have the most often) { doSomething2(); } else if (cond3) // Third if (for the third case I have the most often) { doSomething3(); } else { doElse(); } 

Is there any guarantee that after compilation (for release) the first will be checked, then the second if, then the third if (and finally else is satisfied if none of the conditions were true).

I know that when debugging, ifs are executed in the order I wrote them, but whether it will be true when the program is compiled for release (I mainly use the latest version of g ++ and visual studio).

In addition, since the condition may affect the environment (for example, if (i=a) or if(myfunction()) ), they should be executed as written, but I wonder if there is any optimization that the compiler could do , change the order in which if is tested. Especially if the condition does not have such side effects:

 void test(int a) { if (a == 1) { doSomething1(); } else if (a == 2) { doSomething1(); } else if (a == 3) { doSomething1(); } else { doSomething1(); } } 

Answer 1

From C ++ 03, § 6.4 Marks of choice:

1

  selection-statement:
      if ( condition ) statement
      if ( condition ) statement else statement
      switch ( condition ) statement

[...] If the substitution in the selection command is a single operator and not a compound operator , it is as if rewritten as a compound operator containing the original subtask. [Example:

  if (x) int i; 

can be equivalently rewritten as

  if (x) { int i; } 

[...]

6.4.1 if

1 If condition (6.4) gives true , the first subtask is satisfied. If the else part of the select statement is present and the condition gives false , the second subtask is executed. [...]

From 6.4 1 your sample code is equivalent:

 if (cond1) { doSomething1(); } else { if (cond2) { doSomething2(); } else { if (cond3) { doSomething3(); } else { doElse(); } } } 

Please note: this does not mean that the code is converted to the above, but rather that the two should behave the same.

From 6.4.1, the internal if is satisfied when the condition for the external if is false . If the condition is true , the first branch is executed. Although the standard does not explicitly state that the second branch fails when the condition is true , this is strongly implied by inaction.

According to § 1.9 1:

The semantic descriptions in this International Standard define a parameterized non-deterministic abstract machine. There are no requirements for the structure of the corresponding implementations in this International Standard. In particular, they do not need to copy or emulate the structure of an abstract machine. Rather, appropriate implementations are needed to emulate (only) the observed behavior of an abstract machine, as described below. ⁵⁾

⁵⁾ This provision is sometimes called the “as is” rule, because the implementation can ignore any requirement of this International Standard if the result is as if this requirement were obeying, as far as it can be determined from the observed behavior of the program. For example, the actual implementation should not evaluate part of the expression if it can infer that its value is not used and that no side effects affecting the observed behavior of the program are produced.

Thus, part of the else substitution can be performed if it is free from side effects and the results are discarded, even if the condition turns out to be true . For example, a substation condition may be partially satisfied in a pipeline processor if branch prediction incorrectly predicts that the condition will be false . However, the consequences of this should not be noticeable, therefore (from your point of view) it is as if the substances behave as described in § 6.4.1 and 6.4.1 1.

Answer 2

Is there any guarantee that after compilation (for release) the first will be checked, then the second if, then the third if (and finally else is satisfied if none of the conditions were true).

Yes, but not specifically for if statements, for all of your (single-threaded) code.

C ++ code runs from top to bottom, from start to finish. The only time this may not be the case is when you make asynchronous calls or have multiple threads invoking the same code at the same time.

Answer 3

Not. The only thing that is guaranteed is that the observed behavior is “as if” ifs were evaluated in order. Evaluation conditions may even alternate with the cond2 part preceding cond1, and the other part after cond1 has been evaluated. On the other hand, it is guaranteed that the results will be “as if” ifs were evaluated in order, if some of the conditions have side effects, these side effects will not happen if one of the early ifs was true.

Regarding optimization, by all means conditions first. In practice, the compiler will only move the code, if it knows that the movement will improve the situation, therefore, if the conditions are more or less independent, and the compiler cannot "optimize" their folding parts, then the order will be preserved. If the compiler is exceptionally good and can determine that your order was not optimal (based on the output of the profiler).

Answer 4

yes, conditions are checked in the order of the if, else if else structure. As part of this conditional check, you can slightly adjust the brackets in parentheses.

Answer 5

C ++ compilers are allowed, with some exceptions, to optimize instructions for something, while something else behaves "as if", it has performed unoptimized statements.

The reordering of the if / else tower operators does not behave as if if it was not reordered (unless, of course, the compiler can prove that it will be, for example, when some checks are always true or false and have no side effects).

You absolutely can depend on the order of your if / else tower.