Content deleted Content added
Stevebroshar (talk | contribs) →Expression evaluation order: order is backwards from precedence |
Stevebroshar (talk | contribs) →Expression evaluation order: in some sense everything this a note :) but it's more useful to categorize it than lump everything into a general category |
||
Line 696:
|}
===
Although this table is adequate for describing most evaluation order, it does not describe a few details. The [[ternary operator]] allows any arbitrary expression as its middle operand, despite being listed as having higher precedence than the assignment and comma operators. Thus <code>a ? b, c : d</code> is interpreted as <code>a ? (b, c) : d</code>, and not as the meaningless <code>(a ? b), (c : d)</code>. So, the expression in the middle of the conditional operator (between <code>'''?'''</code> and <code>''':'''</code>) is parsed as if parenthesized. Also, the immediate, un-parenthesized result of a C cast expression cannot be the operand of <code>sizeof</code>. Therefore, <code>sizeof (int) * x</code> is interpreted as <code>(sizeof(int)) * x</code> and not <code>sizeof ((int) * x)</code>.
===Chained expressions===
The precedence table determines the order of binding in chained expressions, when it is not expressly specified by parentheses.
* For example, <code>++x*3</code> is ambiguous without some precedence rule(s). The precedence table tells us that: {{mono|x}} is 'bound' more tightly to {{mono|++}} than to {{mono|*}}, so that whatever {{mono|++}} does (now or later—see below), it does it ONLY to {{mono|x}} (and not to <code>x*3</code>); it is equivalent to (<code>++x</code>, <code>x*3</code>).
Line 705 ⟶ 706:
* Abstracting the issue of precedence or binding, consider the diagram above for the expression 3+2*y[i]++. The compiler's job is to resolve the diagram into an expression, one in which several unary operators (call them 3+( . ), 2*( . ), ( . )++ and ( . )[ i ]) are competing to bind to y. The order of precedence table resolves the final sub-expression they each act upon: ( . )[ i ] acts only on y, ( . )++ acts only on y[i], 2*( . ) acts only on y[i]++ and 3+( . ) acts 'only' on 2*((y[i])++). It is important to note that WHAT sub-expression gets acted on by each operator is clear from the precedence table but WHEN each operator acts is not resolved by the precedence table; in this example, the ( . )++ operator acts only on y[i] by the precedence rules but binding levels alone do not indicate the timing of the postfix ++ (the ( . )++ operator acts only after y[i] is evaluated in the expression).
===Naming===
Many operators specified by a sequence of
The binding of operators in C and C++ is specified (in the corresponding Standards) by a factored language grammar, rather than a precedence table. This creates some subtle conflicts. For example, in C, the syntax for a conditional expression is:▼
===Binding===
▲The binding of operators in C and C++ is specified
<syntaxhighlight lang="c">logical-OR-expression ? expression : conditional-expression</syntaxhighlight>
while in C++ it is:
Line 718 ⟶ 722:
which is a valid expression.<ref>{{cite web |title=C Operator Precedence - cppreference.com |url=https://en.cppreference.com/w/c/language/operator_precedence |website=en.cppreference.com |access-date=10 April 2020}}</ref><ref>{{Cite web|url=https://stackoverflow.com/questions/13515434/does-the-c-c-ternary-operator-actually-have-the-same-precedence-as-assignment/13515505|title=Does the C/C++ ternary operator actually have the same precedence as assignment operators?|website=Stack Overflow|access-date=2019-09-22}}</ref>
<syntaxhighlight lang="cpp"> int a = 1, b = 2, weirdVariable = (++a, b), d = 4; </syntaxhighlight> ===Criticism of bitwise and equality operators precedence===
| |||