1

As all we know: the sequence of evalutation is determined by the priority and associativity. For this example,the associativity determined that a+b,then the result plus c. This is what ANSI C compliant compiler do(leave out the optimization).But will it be evaluated like foregoing manner in the title? In what compiler? In K&R C?

l4rmbr
  • 1,227
  • 7
  • 22
  • 1
    Homework? Just the way it's worded, and the curiosity about K&R C leaves me wondering. – jason Apr 07 '11 at 14:09

6 Answers6

4

Let me throw this at you:

Operator Precedence vs Order of Evaluation

Community
  • 1
  • 1
Sadique
  • 22,572
  • 7
  • 65
  • 91
2

The compiler is free to rearrange things, as long as the end result is the same.

For example:

1 + b + 1

Can easily be transformed to:

b + 2
Lindydancer
  • 25,428
  • 4
  • 49
  • 68
  • 2
    For integers, yes. For floating point, no. It's possible that `1+b+1` is *b* while `b+2` is *b+2*. – R.. GitHub STOP HELPING ICE Apr 07 '11 at 14:30
  • 2
    For that matter, signed integer arithmetic isn't associative either if the implementation raises a signal for overflow or clamps to the range `[MIN,MAX]`, both of which are legal. In this case you'd be OK, though, `1 + b + 1` overflows if and only if `b+2` does. – Steve Jessop Apr 07 '11 at 14:36
1

The structure of the equation in mathematical terms (in a+(b*c) we talk about b*c being evaluated "first") is not necessarily related to the order the compiler will evaluate the arguments

The actual order of execution in this instance is undefined IIRC. C only guarantees that the order of expressions separated by sequence points remains unchanged, and the + operator is not a sequence point.

Most compilers will do what you expect - generating code that will evaluate a then b then c

tobyodavies
  • 27,347
  • 5
  • 42
  • 57
  • I'm sorry but I want to konw what "undefined IIRC" is short for? – l4rmbr Apr 07 '11 at 14:27
  • 1
    @larmbr: "IIRC = If I Remember Correctly". Toby's right, order of execution here is unspecified. Even if `a`, `b`, `c` are all volatile variables, meaning that their order of access is "observable behavior", they might be read in any order. All that's required is that the result is the same result you'd get by respecting the precedence/associativity rules. – Steve Jessop Apr 07 '11 at 14:41
1

n1256:

6.5 Expressions
...
3 The grouping of operators and operands is indicated by the syntax.74) Except as specified later (for the function-call (), &&, ||, ?:, and comma operators), the order of evaluation of subexpressions and the order in which side effects take place are both unspecified.
...
74) The syntax specifies the precedence of operators in the evaluation of an expression, which is the same as the order of the major subclauses of this subclause, highest precedence first. Thus, for example, the expressions allowed as the operands of the binary + operator (6.5.6) are those expressions defined in 6.5.1 through 6.5.6. The exceptions are cast expressions (6.5.4) as operands of unary operators (6.5.3), and an operand contained between any of the following pairs of operators: grouping parentheses () (6.5.1), subscripting brackets [] (6.5.2.1), function-call parentheses () (6.5.2.2), and the conditional operator ?: (6.5.15).

Within each major subclause, the operators have the same precedence. Left- or right-associativity is indicated in each subclause by the syntax for the expressions discussed therein.

Emphasis mine. The expression a + b + c will be evaluated as (a + b) + c; that is, the result of c will be added to the result of a + b. Both a and b must be evaluated before a + b can be evaluated, but a, b, and c can be evaluated in any order.

John Bode
  • 119,563
  • 19
  • 122
  • 198
0
a + b + c == c + b + a

The order does not matter.

It is called operator precedence

David Basarab
  • 72,212
  • 42
  • 129
  • 156
  • 5
    except when a, b or c are expressions that have side effects. – tobyodavies Apr 07 '11 at 14:10
  • 2
    @tobyodavies: if they have side effects and the side effects inffluence the result, the result is **undefined behaviour**; if the side effects don't inffluence the result, the order does not matter – pmg Apr 07 '11 at 14:13
  • 3
    It's associativity, not precedence and for operator+ it's left to right. For floating point arithmetic the order of evaluation DOES matter. – Adam Bowen Apr 07 '11 at 14:14
  • @pmg correct, and yet this is still a common thing to see in C/C++ code. The standard does not guarantee what happens, most compilers try to do sensible things in this case. – tobyodavies Apr 07 '11 at 14:15
  • 1
    What Adam says - floating point arithmetic is *not* associative, so the left-to-right associativity of addition is important and so is the order of terms. For instance, `FLOAT_MAX + FLOAT_MIN + BIGNUMBER` isn't the same as `FLOAT_MAX + BIGNUMBER + FLOAT_MIN`, where `BIGNUMBER` is some number nearly as big as `FLOATMAX`. – Steve Jessop Apr 07 '11 at 14:16
  • @amit I was assuming a b and c were placeholders for expressions, not actual variables. talking about order of execution is completely meaningless without potential side effects. – tobyodavies Apr 07 '11 at 14:17
  • @David yeah,I know it's matter of operator precedence. But if a+b results in overflow ,while a+c not.. This seems not so simple as it looks like! And because of this latent loophole,should compiler ban the operation to do c+b+a ,when I bid it to do a+b+c? – l4rmbr Apr 07 '11 at 14:20
  • @Steve and Adam: see my comment for a possibly-simpler case where floating point is not associative. – R.. GitHub STOP HELPING ICE Apr 07 '11 at 14:31
0

I'll try and highlight the difference between what you consider to be the order of evaluation and what the compiler considers it to be.

Mathematically we say that in the expression a + b * c, the multiplication is evaluated before the addition. Of course it must be because we need to know what to add to a.

However, the compiler doesn't necessarily have to consider evaluating the expression b * c before it evaluates a. You might think that because multiplication has a higher precedence, then the compiler will look at that part of the expression first. Actually, there is no guarantee about what the compiler will decide to do first. It may evaluate a first, or b, or c. This behaviour is unspecified by the standard.

To demonstrate, let's look at the following code:

#include <iostream>

int f() { std::cout << "f\n"; return 1; }
int g() { std::cout << "g\n"; return 2; }
int h() { std::cout << "h\n"; return 3; }

int main(int argc, const char* argv[])
{
  int x = f() + g() * h();
  std::cout << x << std::endl;
  return 0;
}

Each function, f(), g() and h(), simply outputs the name of the function to the standard output and then returns 1, 2 or 3 respectively.

When the program starts, we initalise a variable x to be f() + g() * h(). This is exactly the expression we looked at earlier. The answer will of course be 7. Now, naively you might assume that multiplication happens first, so it'll go there and it'll do g(), then multiply it by h(), then it'll do f() and add it to the previous result.

Actually, compiling this with GCC 4.4.5 shows me that the functions are executed in the order that they appear in the expression: f(), then g(), then h(). This isn't something that will necessarily happen the same in all compilers. It completely depends on how the compiler wants to do it.

If you're performing operations that are associative or commutative then the compiler is also free to swap around the mathematical groupings in the expression, but only if the result will be exactly the same. The compiler must be careful not to do any regroupings that may cause overflows to happen which wouldn't have happened anyway. As long as the result is as defined by the standard, the compiler is free to do what it likes.

Joseph Mansfield
  • 108,238
  • 20
  • 242
  • 324