Operator precedence — full table: Worked examples

This page is the case-by-case drill room for the precedence table. The parent note taught the rulebook; here we hunt down every kind of expression the rules can produce and work each one to the ground.

Before touching examples, remember the two words the whole topic rests on — build them from zero, exactly like the parent did:

The "level N" key — read this first

Every worked example below says things like "* is level 3." That number is just the row number of the parent table, counted from the tightest-binding operators (row 1) down to the loosest (row 15). Lower number = stronger. Here is the compact legend so you never have to flip back:

Level	Operators (as used below)
1	`()` grouping, `[]`, `->`, `.`, postfix `++ --`
2	unary `+ - ! ~`, prefix `++ --`, `*`(deref), `&`(addr), `sizeof`, `(type)`
3	`*` `/` `%`
4	`+` `-` (binary)
5	`<<` `>>`
6	`<` `<=` `>` `>=`
7	`==` `!=`
8	`&` (bitwise AND)
9	`^` (bitwise XOR)
10	`
11	`&&`
12	`
13	`?:` (ternary)
14	`=` and compound assignments
15	`,` (comma)

The scenario matrix

Every precedence puzzle in C falls into one of these case classes. Each row is a distinct trap the rules can spring. The worked examples below are labelled with the cell they cover, and together they hit every row.

Cell	Case class	The trap it hides	Covered by
A	Different-precedence arithmetic	`*` claims operands before `+`/`-`	Ex 1
B	Equal-precedence, L→R tie	`a-b-c` must go left-first	Ex 2
C	Equal-precedence, R→L tie	assignment / ternary chain right-first	Ex 3, Ex 7
D	Cross-family surprise (bitwise vs equality)	`& ^	`sit below`== !=`
E	Shift vs arithmetic	`+` beats `<<`	Ex 5
F	Unary vs postfix (degenerate 1-operand)	postfix `++` beats unary `-`	Ex 6
G	Real-world word problem	grouping changes a computed quantity	Ex 8
H	Exam twist / undefined-behaviour edge	precedence is irrelevant here	Ex 9
I	Zero / degenerate operand (short-circuit)	second operand never runs	Ex 10
J	Comma operator (lowest precedence)	`a = 1, 2` is not `a = (1,2)`	Ex 11
K	Level-1 postfix cluster (calls, member, `[]`, `++`)	`*p.x`, `f()->b++` group surprisingly	Ex 12
L	Cast `(type)` vs unary / deref	`(int)x + y` casts only `x`	Ex 13

Read the table as a checklist: by Example 13 there is no shape of expression left that can surprise you.

Worked examples

Cell A — different-precedence arithmetic

Figure 1 — parse tree of a + b*c - d. A binary tree: the root is -; its left child is + and right child is the leaf d. The + node has left leaf a and right child *, and that * node (drawn in magenta, sitting deepest) has leaves b and c. Arrows label the magenta * as "binds tightest, done first" and the root - as "binds loosest, done last".

Figure — Operator precedence — full table

The red subtree (3*4) is deepest because it binds tightest; the - sits at the root because it is the loosest operator here and so is applied last.

Cell B — equal precedence, left-to-right

Figure 2 — two rival trees for a - b - c. Left tree (magenta root, C's meaning): ((a-b)-c), so the deepest bracket is a-b. Right tree (violet root, the wrong reading): (a-(b-c)), deepest bracket b-c. Captions read "C's meaning (L→R): = 3" over the left and "wrong (R→L): = 9" over the right, showing the answer flips with the grouping.

Cell C — equal precedence, right-to-left (assignment)

Worked example Ex 3 · Chained assignment

a = b = 5; Forecast: what does a end up holding, and why does the order of the two = matter?

Both = are level 14 → tie. Why? Same-strength operators again defer to associativity.
Assignment is R→L, so group the rightmost first: a = (b = 5). Why? An assignment is an expression that returns the value stored; grouping right-first lets the inner store produce a value the outer = can reuse.
Inner b = 5 stores 5 in b and yields the value 5. Why this step? We evaluate the deepest group first, exactly like arithmetic — and here "evaluating" a store means "do the store, hand back the stored value."
Outer a = 5 stores 5 in a. Why this step? The outer = receives the 5 that bubbled up from the inner assignment.

Verify: final a = 5, b = 5. Both equal 5, exactly as R→L predicts. (If it were L→R, (a = b) = 5 would try to assign to the value a, which is not a storable location — an error.) See the tree below.

Figure 3 — parse tree of a = b = 5. Root = (violet), left leaf a, right child a second = (magenta) whose leaves are b and 5. An arrow marks the inner magenta = as "inner (b=5) done first, yields value 5" and the root as "outer a = 5 last", visualising the right-to-left grouping.

Cell D — cross-family surprise (bitwise below equality)

Worked example Ex 4 · The bit-mask trap

x & 1 == 0 with x = 6 Forecast: you want "is x's lowest bit zero?" — will this code answer that?

Rank the operators: == is level 7, & (bitwise AND) is level 8. Why this step? Because 7 < 8, == is stronger — this is the single most infamous surprise in the table (see Bitwise Operators).
Group the stronger one first: x & (1 == 0). Why? == claims 1 and 0 before & can touch them.
1 == 0 is false → 0. Why this step? Deepest group first: the comparison 1==0 resolves to the integer 0 in C.
6 & 0 = 0 (AND with all-zero bits clears everything). Why this step? Bitwise AND keeps a bit only where both operands have a 1; 0 has no 1s, so nothing survives. Result: always 0 / false, no matter what x is.
Fix: (x & 1) == 0. Why does this fix it? Grouping parentheses are outside the ranking entirely (they wall off a sub-tree), so x & 1 is forced to finish first, computing the lowest bit; only then does == 0 test that bit. This restores the meaning we actually wanted. Now (6 & 1) == 0 → 0 == 0 → true.

Verify: buggy form 6 & (1==0) = 6 & 0 = 0. Fixed form (6 & 1) == 0 = 0 == 0 = 1. The two forms give opposite truth values — proof the parentheses matter. See the two trees below.

Figure 4 — buggy vs fixed bit-mask trees. Left (violet root, "BUG"): x & (1==0), where == is the deeper node, so x gets ANDed with the comparison result. Right (magenta root, "FIX"): (x & 1) == 0, where & is now the deeper node, so the lowest bit is extracted before the equality test. Captions: "BUG: x & (10) → 0" and "FIX: (x & 1)0 → 1".

Cell E — shift versus arithmetic

Figure 5 — parse tree of 1 << 2 + 3. Root << (violet), left leaf 1, right child + (magenta) with leaves 2 and 3. An arrow tags the + node "+ groups first (level 4 < 5), so 2+3 = 5", and a caption reads "1 << (2+3) = 1 << 5 = 32".

Cell F — unary versus postfix (degenerate single-operand)

Worked example Ex 6 ·

int a = 5; int b = -a++; Forecast: what are b and a afterward?

Two operators fight over a: postfix ++ (level 1) and unary - (level 2). Why this step? This is the "degenerate" case — only one operand (a) but two operators clawing at it.
Level 1 < level 2, so postfix ++ binds tighter: group -(a++). Why? Postfix modification sticks to its variable more tightly than a unary sign.
a++ is postfix: it yields the old value 5, then schedules a to become 6. Why this step? Postfix means "use the current value now, update the variable afterward" — the yielded value is the pre-increment one.
Apply unary - to the yielded 5: b = -5. Why this step? The - operates on the value 5 that a++ handed up, not on the new a. After the statement, a = 6.

Verify: b = -5, a = 6. The sign hit the old value; the increment still happened. Both facts hold together. See the tree below.

Figure 6 — vertical chain for -a++. Three stacked nodes: top unary - (violet), middle postfix ++ (magenta), bottom leaf a. Arrows explain that ++ binds tightest (level 1) so a++ yields the old value 5, and then - negates that 5 giving b = -5 while a becomes 6.

Cell C (again) — ternary chain, right-to-left

Worked example Ex 7 ·

x = a ? b : c ? d : e; with a=0, b=1, c=1, d=8, e=9 Forecast: guess x — treat it as if/else-if/else.

?: (ternary, level 13) is R→L. Why this step? Right-associativity is what makes a chain read as nested else-branches instead of a tangle. See The Ternary Conditional Operator.
Group rightmost first: a ? b : (c ? d : e). Why? The trailing ?: becomes the "else" clause of the leading one.
Evaluate a: a = 0 (false), so take the else branch (c ? d : e). Why this step? A ternary first tests its condition; a zero condition means "take the part after the colon."
Evaluate c: c = 1 (true), so take d. Why this step? Inside the else-branch we run a fresh ternary; its true condition selects the value before its colon, d. Result x = 8.

Verify: reads as if a → 1 else (if c → 8 else 9). With a=0, c=1, we land on d = 8. x = 8. See the tree below.

Figure 7 — nested ternary tree. Root ternary "?: a" (violet) with left leaf b and right child a second ternary "?: c" (magenta) whose branches are d and e. Arrows note "a=0 false → take else branch" pointing at the inner ternary and "c=1 true → d = 8" pointing at leaf d; caption "a ? b : (c ? d : e) (R→L) → x = 8".

Cell G — real-world word problem

Worked example Ex 8 · Averaging three sensor readings

A junior writes the average of s1=10, s2=20, s3=30 as avg = s1 + s2 + s3 / 3; Forecast: does avg equal 20 (the true mean)? Guess first.

Rank: / is level 3, + is level 4. Why this step? Division is stronger, so it seizes an operand before the additions run.
Group / first: s1 + s2 + (s3 / 3) = 10 + 20 + (30/3). Why? Only s3 and 3 are captured by /; the additions are left waiting.
30/3 = 10, then 10 + 20 + 10 = 40. Why this step? Deepest group first (30/3=10), then the two + run left-to-right: 10+20=30, 30+10=40. So avg = 40 — nonsense for a mean.
Fix: avg = (s1 + s2 + s3) / 3; → (60)/3 = 20. Why does this fix it? The parentheses wall off the whole sum as one finished operand, so the / receives 60 (the total) instead of just s3; dividing the total by 3 is exactly the definition of a mean.

Verify: buggy 10 + 20 + 30/3 = 40; fixed (10+20+30)/3 = 20. The correct mean is 20, so the parentheses are mandatory.

Cell H — exam twist / precedence is a red herring

Worked example Ex 9 · Trick question: "Use precedence to evaluate

i = i++ + 1; for i=3." Forecast: the exam wants you to compute a number. Should you?

Precedence does give a shape: postfix ++ (level 1) binds first, then + (level 4), then = (level 14): i = ((i++) + 1). Why this step? To show that grouping alone looks harmless.
But i is both modified (by ++) and read/written (by =) with no sequence point between. Why this matters? C's rules say such a read-and-modify collision is undefined behaviour — see Sequence Points and Undefined Behaviour.
Therefore no numeric answer is correct: the compiler is free to produce anything. Why this step? Undefined behaviour is not "some particular wrong number" — it is "the standard imposes no requirement at all," so we cannot compute a value.
Fix: split it into i++; then i = i + 1;. Why does this fix it? The ; at the end of i++; is a sequence point — it guarantees the increment fully completes (and i's new value is settled) before the next statement reads i. With the modify and the read no longer sharing one expression, the collision disappears and the behaviour becomes fully defined.

Verify: the shape is i = ((i++)+1), which is well-formed grouping, yet the program's value is undefined — so the honest answer is "no defined result," not a number.

Cell I — zero / degenerate operand (short-circuit)

Worked example Ex 10 ·

result = a || b && c; with a=1, b=0, c=1 Forecast: is b && c ever computed here?

Rank: && is level 11, || is level 12. Why this step? && is stronger, so — "AND before OR", like multiply before add.
Group && first: a || (b && c) = 1 || (0 && 1). Why? The && claims b and c before || sees them.
|| evaluates its left operand a first. a = 1 (true). Why? Logical OR short-circuits: if the left side is true, the whole thing is already true. See Logical Operators and Short-circuit Evaluation.
Because the left was true, (b && c) is never evaluated at all. Why this step? Short-circuit means C literally skips computing the right operand once the answer is settled — this is a rule about evaluation, layered on top of the grouping. result = 1.

Verify: 1 || (anything) = 1, so result = 1 and the right subtree is skipped. Even if we did evaluate it, 0 && 1 = 0, and 1 || 0 = 1 — same answer, confirming the short-circuit changed effort, not the value.

Cell J — the comma operator (lowest precedence of all)

Worked example Ex 11 ·

int a; a = 1, 2; versus a = (1, 2); Forecast: what does a hold in each version? Most people say 2 for the first — check it.

Rank: the comma operator , is level 15 — looser than everything, including = (level 14). Why this step? Because , is the weakest, it groups last, so it does not wrap the 1 and 2 into one operand for =.
Group = first (it is stronger): (a = 1), 2. Why? The assignment a = 1 binds tighter than the comma, so it forms its own sub-expression on the left of the comma.
Evaluate left to right (the comma operator is L→R): first do a = 1, storing 1 in a; then evaluate 2 and discard it. Why this step? The comma operator's whole job is "evaluate the left, throw its value away, then evaluate the right and hand that up as the result." So the statement's value is 2, but a was set to 1.
Now the parenthesised version a = (1, 2);: grouping walls off (1, 2) first, which evaluates 1, discards it, yields 2; then a = 2. Why this step? Here the comma lives inside the parentheses, so its result (2) becomes the right-hand side of =.

Verify: a = 1, 2; leaves a == 1; a = (1, 2); leaves a == 2. Opposite results from one moved bracket — the comma trap in full.

Figure 8 — comma trap, two trees. Left ("a = 1, 2;"): root is , (violet), whose left child is the = node (orange) with leaves a and 1, and whose right leaf is 2; caption "a = 1, 2; → a == 1", with an arrow noting "= binds tighter than , so a=1 happens". Right ("a = (1,2);"): root is = (magenta) with left leaf a and right child a , node (violet) over leaves 1 and 2; caption "a = (1, 2); → a == 2".

Cell K — the level-1 postfix cluster (calls, member, subscript, postfix `++`)

Worked example Ex 12 · Pointer-and-member trap:

*p.x and the counter idiom f()->b++ Forecast: in *p.x, does the * dereference p, or the whole p.x? And in f()->b++, what gets incremented?

Assume a struct S { int *x; }; and a pointer struct S *p initialised so that p->x points at an int holding 7. Also a function f() returning a struct T *, where struct T { int b; };.

*p.x — rank the players. Member access . is level 1; dereference * is level 2. Why this step? The level-1 cluster (., ->, [], function-call (), postfix ++/--) binds tighter than every unary prefix operator, including *.
So it groups as *(p.x), not (*p).x. Why? . grabs p and x first, forming p.x; only then does * dereference that result. (This is a classic bug: to dereference the pointer field of a pointer you must write (*p).x or use the shorthand p->x.)
f()->b++ — rank the players. Function call (), member-arrow ->, and postfix ++ are all level 1, and level 1 is L→R. Why this step? Equal precedence → associativity decides, and left-to-right means we bind starting from the left edge.
Group L→R: ((f())->b)++. Why? First f() runs (call binds first), yielding a struct T *; then ->b selects that struct's member b; then postfix ++ increments that member (yielding its old value, then adding 1 to b). It is not f()->(b++) in any surprising way — but crucially it is not ++ applied to f()'s pointer.

Verify (concept): *p.x ≡ *(p.x) (member wins over deref); f()->b++ ≡ ((f())->b)++ (all level-1, left-to-right). Neither reading dereferences or increments the "outer" thing a beginner expects — the level-1 cluster always resolves innermost-to-the-left first. If you truly want "dereference p, then take .x", you must parenthesise: (*p).x.

The safe habit: whenever a prefix * meets a ./->/[]/()/postfix ++, the postfix cluster wins — parenthesise if you meant otherwise.

Cell L — the cast `(type)` versus unary and dereference

Worked example Ex 13 · How far does a cast reach?

(int)x + y and (double)x / y Forecast: in (int)x + y, is it ((int)x) + y or (int)(x + y)? With x = 3.9, y = 2 (both double), what number comes out of (double)x / y? (Trick: x is already double.)

Rank the cast. The cast operator (type) is a unary operator at level 2 — same row as unary -, !, sizeof, and dereference *. Why this step? Being unary and level 2, a cast binds to just the single operand immediately to its right, not to a whole sum.
(int)x + y. The cast (level 2) is stronger than binary + (level 4). Why? Lower level number wins, so the cast claims only x: it groups as ((int)x) + y, not (int)(x + y). Only x is converted to int; then that int is added to y.
Cast vs dereference (both level 2, R→L). In (int)*p, the level-2 operators tie, and level 2 is right-to-left, so it groups (int)(*p): dereference first, then cast the pointed-to value. Why this step? Right-associativity of the unary row means the operator closest to the operand (here *, on the right) binds first, then the cast wraps the result — which is exactly the sensible reading.
The (double)x / y sanity check. Group as ((double)x) / y (cast beats /). With x = 3.9 already a double, (double)3.9 = 3.9, then 3.9 / 2 = 1.95. Why show it? To prove the cast only touches x and the division still uses the real values — the cast did nothing new here because x was already double, but it did stop at x rather than swallowing x / y.

Verify: with x = 7.8, y = 4 (doubles) as a cleaner integer-cast case, (int)x + y = (int)7.8 + 4 = 7 + 4 = 11 — the cast truncated only x to 7. And (double)3.9 / 2 = 1.95. Both confirm the cast binds tighter than + and / and reaches only one operand. See Type Casting and Conversions for how the truncation itself works.

Recall Self-test the whole matrix

Ex 1 — a + b*c - d with a=2,b=3,c=4,d=1 groups and evaluates to what? ::: ((2 + (3*4)) - 1) = 13. Ex 2 — the value C guarantees for 10 - 4 - 3? ::: 3 (left-associative), not 9. Ex 3 — after a = b = 5, what is a? ::: 5 (right-associative assignment). Ex 4 — what does 6 & 1 == 0 evaluate to? ::: 0 (because == outranks &, giving 6 & 0). Ex 5 — value of 1 << 2 + 3? ::: 32 (+ beats <<, so 1 << 5). Ex 6 — after b = -a++ with a=5, what are b and a? ::: b = -5, a = 6. Ex 7 — value of 0 ? 1 : 1 ? 8 : 9? ::: 8. Ex 8 — value of s1 + s2 + s3/3 with 10,20,30, and the correct mean? ::: bug gives 40; correct mean needs parentheses → 20. Ex 9 — value of i = i++ + 1? ::: undefined behaviour — no valid numeric answer. Ex 10 — value of 1 || 0 && 1, and is 0 && 1 evaluated? ::: 1; and no, it is short-circuited away. Ex 11 — a after a = 1, 2; versus a = (1, 2);? ::: 1 in the first, 2 in the second. Ex 12 — how do *p.x and f()->b++ group? ::: *(p.x) (member beats deref) and ((f())->b)++ (all level-1, L→R). Ex 13 — value of (int)7.8 + 4, and does the cast reach y? ::: 11; the cast binds only x (level 2 > +), so y is untouched.

Connections

Operator precedence — full table (index 5.1.5)
Expressions and Statements in C
Bitwise Operators
Logical Operators and Short-circuit Evaluation
Sequence Points and Undefined Behaviour
Type Casting and Conversions
The Ternary Conditional Operator

Worked examples — Operator precedence — full table