Another related source of bugs is how rounding errors accumulate. Not an operator precedence order issue per se, but a source of surprise when you get a different result after rearranging operands in an arithmetically-equivalent way. Here's a sun.com version of David Goldberg's What Every Computer Scientist Should Know About Floating-Point Arithmetic.

As opposed to what many people seem to think, b is NOT assigned before incrementing a when we write int b = a++;. It is assigned the former value of a, but later in the timeline than the actual increment of a.

Therefore, it does not contradict what precedence tells you.

To convince you, here is a little example that convinced me:

int a = 1;
int b = a++ + a++;

At the end, b equals 3, not 2, and a is also 3. What happens because of precedence is:

• the left a++ is evaluated first, incrementing a, but still evaluated to the former value 1 by definition of the operator
• the right a++ is evaluated, reading the new value 2 (proving that the first increment already happened), incrementing it to 3, but still evaluating to 2
• the sum is calculated 1 + 2, and assigned to b

This is because you should see a++ as both an instruction and an expression.

• the instruction increments a
• the expression evaluates to the former value of a

It's the same kind of things as in b = a, which also is an instruction and an expression:

• the instruction assigns the value of a to b
• the expression evaluates to the assigned value