C++ Operator Precedence
The following table lists the precedence and associativity of C++ operators. Operators are listed top to bottom, in descending precedence.
||Suffix/postfix increment and decrement|
||Prefix increment and decrement||Right-to-left|
||Unary plus and minus|
||Logical NOT and bitwise NOT|
||Dynamic memory allocation|
||Dynamic memory deallocation|
||Multiplication, division, and remainder|
||Addition and subtraction|
||Bitwise left shift and right shift|
||For relational operators < and ≤ respectively|
||For relational operators > and ≥ respectively|
||For relational operators = and ≠ respectively|
||Bitwise XOR (exclusive or)|
||Bitwise OR (inclusive or)|
||Ternary conditional[note 2]||Right-to-left|
||Direct assignment (provided by default for C++ classes)|
||Compound assignment by sum and difference|
||Compound assignment by product, quotient, and remainder|
||Compound assignment by bitwise left shift and right shift|
||Compound assignment by bitwise AND, XOR, and OR|
The operand of
sizeofcan't be a C-style type cast: the expression
sizeof (int) * pis unambiguously interpreted as
(sizeof(int)) * p, but not
The expression in the middle of the conditional operator (between
:) is parsed as if parenthesized: its precedence relative to
When parsing an expression, an operator which is listed on some row of the table above with a precedence will be bound tighter (as if by parentheses) to its arguments than any operator that is listed on a row further below it with a lower precedence. For example, the expressions std::cout << a & b and *p++ are parsed as (std::cout << a) & b and *(p++), and not as std::cout << (a & b) or (*p)++.
Operators that have the same precedence are bound to their arguments in the direction of their associativity. For example, the expression a = b = c is parsed as a = (b = c), and not as (a = b) = c because of right-to-left associativity of assignment, but a + b - c is parsed (a + b) - c and not a + (b - c) because of left-to-right associativity of addition and subtraction.
Associativity specification is redundant for unary operators and is only shown for completeness: unary prefix operators always associate right-to-left (delete ++*p is delete(++(*p))) and unary postfix operators always associate left-to-right (a++ is ((a))++). Note that the associativity is meaningful for member access operators, even though they are grouped with unary postfix operators: a.b++ is parsed (a.b)++ and not a.(b++))
Operator precedence is unaffected by operator overloading.
Precedence and associativity are compile-time concepts and are independent from order of evaluation, which is a runtime concept.
The standard itself doesn't specify precedence levels. They are derived from the grammar.
Some of the operators have alternate spellings (e.g., and for
&&, or for
||, not for
Relative precedence of the ternary conditional and assignment operators differs between C and C++: in C, assignment is not allowed on the right-hand side of a ternary conditional operator, so e = a < d ? a++ : a = d cannot be parsed. Many C compilers use a modified grammar where
?: has higher precedence than
=, which parses that as e = ( ((a < d) ? (a++) : a) = d ) (which then fails to compile because
?: is never lvalue in C and
= requires lvalue on the left). In C++,
= have equal precedence and group right-to-left, so that e = a < d ? a++ : a = d parses as e = ((a < d) ? (a++) : (a = d)).
 See also
a = b
a == b
static_cast converts one type to another related type
C documentation for C operator precedence