Visual walkthrough — Operator precedence — full table

Before anything, two plain-word promises about the pictures below:

We will build the tree for one expression the whole way through:

$\text{a + b * c - d}$

---

Step 1 — Lay the flat expression on a number line of positions

WHAT. Write the expression as a flat row: four values a b c d with three operators wedged between them: +, *, -. Nothing is grouped yet — this is the raw text the compiler receives.

WHY. A compiler never sees parentheses that aren't typed. It sees a flat stream of tokens. Our whole job is to prove that this flat stream has exactly one legal grouping. Starting flat makes every later decision visible.

PICTURE. Look at the figure: the values sit on a line, each operator is a coloured box pointing down at the two neighbours it could claim. Notice * (orange) and the two additive operators +, - (blue) are still "floating" — none has grabbed yet.

In symbols, the ambiguity we must kill:

$\underset{\text{value}}{\underbrace{\text{a}}}\underset{\text{op, lvl 4}}{\underbrace{\text{+}}}\underset{\text{value}}{\underbrace{\text{b}}}\underset{\text{op, lvl 3}}{\underbrace{\text{*}}}\underset{\text{value}}{\underbrace{\text{c}}}\underset{\text{op, lvl 4}}{\underbrace{\text{-}}}\underset{\text{value}}{\underbrace{\text{d}}}$

Here "lvl 4 / lvl 3" are the precedence levels from the table: smaller number = stronger. So * at level 3 is stronger than + and - at level 4.

---

Step 2 — Rank the operators by strength

WHAT. Sort the three operators by their level number: * is level 3, + and - are both level 4.

WHY. Precedence says the strongest operator forms the innermost (deepest) group — it must be resolved before any weaker operator can touch its result. So we always attack the smallest level number first. This is why we sort before grouping.

PICTURE. The figure stacks the operators like a podium: * stands on the tall step (rank 1, strongest), + and - share the short step (rank 2, tied). The tie between + and - is flagged in red — that tie is exactly where associativity will be needed later.

$\underset{\text{lvl 3, strongest}}{\underbrace{\text{*}}}>\underset{\text{lvl 4, tied}}{\underbrace{\text{+}\text{-}}}$

The > here means "binds tighter than," not "computed earlier in time" — see the sequence-point warning later.

---

Step 3 — The strongest operator grabs first

WHAT. Let * claim its two immediate neighbours, b and c. Draw a node * with b and c hanging below it. The result of that node is now a single bundle we'll call (b*c).

WHY. Because * outranks both + and -, nobody else is allowed to take b or c first. Grabbing the strongest operator first is the mechanical meaning of "higher precedence." This is the innermost, deepest part of the final tree.

PICTURE. In the figure the * node (orange) drops down and wraps b and c in a shaded pod. The rest of the row now reads as three items: a, the bundle (b*c), and d, joined by + and -.

$\text{a + }\underset{\text{one sub-tree, computed as a unit}}{\underbrace{(\text{b*c})}}\text{ - d}$

---

Step 4 — Break the tie with associativity (L→R)

WHAT. Now only + and - remain, and they are tied at level 4. Their associativity is left-to-right, so the leftmost operator (+) binds first. Group a + (b*c) into one bundle.

WHY. When strength is equal, precedence can't decide — the tree could bend left or right. Associativity is the rule that forces one answer. L→R for additive operators means: scan from the left; the first equal-strength operator you meet grabs first and sits deeper. Without this rule, a - b - c would be ambiguous.

PICTURE. The figure shows a left-pointing green arrow sweeping across + and -. It stops at + first, so + sinks below - in the tree. The bundle (a + (b*c)) forms; only - is left floating on top.

$\left(\underset{\text{formed first, leftmost op}}{\underbrace{\text{a + (b*c)}}}\right)\text{-}\text{d}$

---

Step 5 — The last operator closes the tree

WHAT. Only - is left. It takes the big left bundle (a + (b*c)) as its left child and d as its right child. That's the root — the topmost node.

WHY. The weakest operator (or the last one standing after ties are broken) ends up at the top of the tree, because everything it works on had to be resolved first. The root is computed last.

PICTURE. The completed tree: - at the top (root), its left child is the + node, whose left child is a and whose right child is the * node holding b and c; the root's right child is the leaf d. Read bottom-up to evaluate.

$\left(\right(\text{a}+(\text{b}\ast \text{c}))-\text{d})$

Bottom-up evaluation order (deepest first):

$\underset{\text{1st, deepest}}{\underbrace{\text{b*c}}}\to \underset{\text{2nd}}{\underbrace{\text{a + (b*c)}}}\to \underset{\text{3rd, root}}{\underbrace{(\dots )-\text{d}}}$

---

Step 6 — Edge case: when the tie-breaker flips (right-associative)

WHAT. Swap in an expression whose operators are right-associative: a = b = 5. The = operator (level 14) is R→L, the mirror image of Step 4.

WHY. We must show the other case — a reader who only saw L→R would build assignment trees upside-down. R→L exists so that a chained assignment evaluates the rightmost first and feeds its value leftward: b = 5 produces the value 5, which then flows into a.

PICTURE. The figure mirrors Step 4: the arrow now sweeps right-to-left, so the rightmost = binds first and sinks deepest. The tree grows down the right side instead of the left.

$\text{a}=\left(\underset{\text{grabs first, deepest, yields }5}{\underbrace{\text{b}=\text{5}}}\right)$

---

Step 7 — Degenerate case: the famous bit-mask surprise

WHAT. Take x & 1 == 0. Here two operators of different levels fight, and the surprise is which one wins: == (level 7) beats & (level 8) because 7 < 8.

WHY. People expect (x & 1) == 0, but precedence says == binds tighter, so the real tree is x & (1 == 0). This is the single most common precedence bug in C, so it earns its own picture. The bitwise & sits below equality in strength — a genuine trap.

PICTURE. Two trees side by side: on the left, what you wanted — & on top of (x&1)==0; on the right (red), what C actually builds — == deep inside, so 1 == 0 collapses to 0, then x & 0 is always 0. The right tree is stamped "ALWAYS FALSE."

$\underset{\text{C’s tree}}{\underbrace{\text{x \& (1 == 0)}}}=\text{x \& 0}=\underset{\text{always false}}{\underbrace{0}}$

---

The one-picture summary

This final figure lays all three trees on one canvas — the standard L→R build, the R→L assignment mirror, and the bit-mask trap — so you can see at a glance that strength decides depth, and associativity decides which way a tie leans.

Recall Feynman retelling — the whole walkthrough in plain words

Picture a line of numbers with operator-kids standing between them, each wanting to grab the numbers on both sides. The strongest kid grabs first — that's precedence — so * scoops up b and c into a little bundle before anyone else moves. Now two equally strong kids, + and -, are left. They can't both win, so we use a house rule: for + - the kid on the left wins (left-to-right), so + grabs the a and the bundle, leaving - to sit on top and take d last. Reading the finished tree from the bottom up gives you the one true order: multiply, then add, then subtract. Two special cases break the pattern: assignment flips the house rule to "right kid wins," so a = b = 5 fills b first then hands 5 leftward; and the sneaky x & 1 == 0, where == is secretly stronger than &, builds the wrong tree unless you wrap (x & 1) in a parenthesis. Strength sets how deep, ties pick a side — that's the entire rulebook, drawn.

---

Connections

• Operator precedence — full table (parent)
• 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