• Home
• Syllabus
• Schedule
• Checkin
• Scores
• Homework
  • HW0
  • HW1
  • HW2
  • HW3
  • HW4
  • HW5
  • HW6
  • HW7
  • HW8
• Examples
• Piazza
• Slides
• Other Info

Show Lecture.OrderOfEvaluation as a slide show.

CS253 Order Of Evaluation

Basic Expressions

Consider the expression a+b, which parses as:

        			 ┌───┐
        			 │ + │
        			 └───┘
        			 ⠌   ⠡
        			⠌     ⠡
        		    ┌───┐     ┌───┐
        		    │ a │     │ b │
        		    └───┘     └───┘

Basic Expressions

How does a+b*c parse?

                  ┌───┐                       ┌───┐
                  │ * │                       │ + │
                  └───┘                       └───┘
                  ⠌   ⠡                       ⠌   ⠡
                 ⠌     ⠡                     ⠌     ⠡
             ┌───┐     ┌───┐             ┌───┐     ┌───┐
             │ + │     │ c │             │ a │     │ * │
             └───┘     └───┘             └───┘     └───┘
             ⠌   ⠡                                 ⠌   ⠡
            ⠌     ⠡                               ⠌     ⠡
        ┌───┐     ┌───┐                       ┌───┐     ┌───┐
        │ a │     │ b │                       │ b │     │ c │
        └───┘     └───┘                       └───┘     └───┘

The right-hand side, of course. * has higher precedence than +.

Basic Expressions

Let’s use parentheses. How does (a+b)*c parse?

                  ┌───┐                       ┌───┐
                  │ * │                       │ + │
                  └───┘                       └───┘
                  ⠌   ⠡                       ⠌   ⠡
                 ⠌     ⠡                     ⠌     ⠡
             ┌───┐     ┌───┐             ┌───┐     ┌───┐
             │ + │     │ c │             │ a │     │ * │
             └───┘     └───┘             └───┘     └───┘
             ⠌   ⠡                                 ⠌   ⠡
            ⠌     ⠡                               ⠌     ⠡
        ┌───┐     ┌───┐                       ┌───┐     ┌───┐
        │ a │     │ b │                       │ b │     │ c │
        └───┘     └───┘                       └───┘     └───┘

The left-hand side, of course. Parentheses mean “do this first”.

No

Really

              ┌───┐
              │ * │
              └───┘
              ⠌   ⠡
             ⠌     ⠡
         ┌───┐     ┌───┐
         │ + │     │ c │
         └───┘     └───┘
         ⠌   ⠡
        ⠌     ⠡
    ┌───┐     ┌───┐
    │ a │     │ b │
    └───┘     └───┘

• Parentheses do not mean “do this first”.
• Parentheses mean “group these together”.
• Parentheses determine the shape of the parse tree, not the order of evaluation.
• Of course, the shape of the tree determines the order of evaluation, to some extent.
• In this tree, the + node feeds to the * node, so + must execute before *.
• However, we can evaluate c before the addition, or after.

Really

              ┌───┐
              │ * │
              └───┘
              ⠌   ⠡
             ⠌     ⠡
         ┌───┐     ┌───┐
         │ + │     │ c │
         └───┘     └───┘
         ⠌   ⠡
        ⠌     ⠡
    ┌───┐     ┌───┐
    │ a │     │ b │
    └───┘     └───┘

Possible orders of evaluation:
a, b, c, +, *
a, b, +, c, *
a, c, b, +, *
b, a, c, +, *
b, a, +, c, *
b, c, a, +, *
c, a, b, +, *
c, b, a, +, *

Who Cares?

• So what? It doesn’t matter in which order a, b, and c are fetched.
  • If they’re simple variables, then, no, it doesn’t matter.
  • If they’re expressions with side effects, then it does matter:
    • increment/decrement
    • assignment
    • function calls
      • could change global variables
      • could generate output

Some Operators Are Different

• Some operators have order of evaluation specified:
  • && ||
  • , (in an expression, not as an argument separator)
  • ?:
• Most do not:
  • + - * / %
  • << >> & | ^
  • < > <= >= == !=
  • = += -= *= /= %= <<= >>= &= |= ^=

A user-defined operation (e.g., operator+) does not have order determined, because it’s a function called with two arguments. The order of evaluation of function arguments is unspecified.

Pre-/Post-Increment/Decrement

This example is bad. Don’t do this:

int n = 1;
cout << ++n * ++n << endl;

c.cc:2: warning: operation on 'n' may be undefined
9

Another bad example

Don’t do this, either:

short nums[] = {1, 2, 3, 4};

short *p = nums;
cout << *p++ << ' ';
cout << *p++ << '\n';

p = nums;
cout << *p++ << ' ' << *p++ << '\n';

c.cc:8: warning: operation on 'p' may be undefined
1 2
1 2

Why not?

Why not? Because, in both cases, the variable is being modified twice in the same expression.

• << is an operator, just like + is.
• cout << a << b is one expression.
  • same as (cout << a) << b
    • same as operator<<(operator<<(cout,a), b)
• C++ does not determine the order of execution of the various parts of the expression, except for a few special cases:
  • && || ?:
  • , (the binary comma operator, not function arguments)

Another Example

int a() { cout << 'A'; return 1; }
int b() { cout << 'B'; return 2; }

int main() {
    cout << a()+b() << '\n';    // Might print AB3 or BA3.
    cout << a() << b() << '\n'; // Might print A1B2, AB12, BA12
    return 0;
}

AB3
A1B2

Experiments don’t matter

You cannot determine the “correct” result by experimentation.

• The compiler might do it in one order today, and in a different order tomorrow.
• The next version of the compiler might do it differently.
• It might depend on what other variables have been declared.
• A different compiler might do things in a different order.

How to do it right

Break apart expressions, perhaps using explicit temporaries, to determine the order of evaluation of sub-expressions:

int a() { cout << 'A'; return 1; }
int b() { cout << 'B'; return 2; }

int main() {
    int c = a();        // Will print A
    c += b();           // Will print B
    cout << a();        // Will print A1
    cout << b();        // Will print B2
    return 0;
}

ABA1B2

User: Guest