C++ is rich in built-in operators. There are different kinds of operators:
- – Arithmetic: , , , , . . .
- * Comparison: , , . . .
- * Logic: and
- – Bitwise: , ≪ and ≫, , , and
- Assignment: , , . . .
- Program flow: function call, , and
- Memory handling: and
- Access: , , , , . . .
- Type handling: , , , . . .
- Error handling:
This section will give an overview of the operators. Some operators are better described elsewhere in the context of the appropriate language feature; e.g., scope resolution is best explained together with namespaces. Most operators can be overloaded for user types; i.e., we can decide which calculations are performed when one or multiple arguments in an expression are our types.
At the end of this section (Table 1–8), you will find a concise table of operator precedence. It might be a good idea to print or copy this page and pin it next to your monitor; many people do so and almost nobody knows the entire priority list by heart. Neither should you hesitate to put parentheses around sub-expressions if you are uncertain about the priorities or if you believe it will be more understandable for other programmers working with your sources. If you ask your compiler to be pedantic, it often takes this job too seriously and prompts you to add surplus parentheses assuming you are overwhelmed by the precedence rules. In Section C.2, we will give you a complete list of all operators with brief descriptions and references.
1.3.1 Arithmetic Operators
Table 1–2 lists the arithmetic operators available in C++. We have sorted them by their priorities, but let us look at them one by one.
Table 1–2: Arithmetic Operators
The first kinds of operations are increment and decrement. These operations can be used to increase or decrease a number by 1. As they change the value of the number, they only make sense for variables and not for temporary results, for instance:
In short, the increment and decrement operations need something that is modifiable and addressable. The technical term for an addressable data item is Lvalue (see Definition C–1 in Appendix C). In our code snippet above, this is true for only. In contrast to it, is constant and is not addressable.
Both notations—prefix and postfix—have the effect on a variable that they add or subtract 1 from it. The value of an increment and decrement expression is different for prefix and postfix operators: the prefix operators return the modified value and postfix the old one, e.g.:
At the end, both and are 4. However in the calculation of , the old value of was used while the first addition used the already incremented value of .
In general, it is better to refrain from using increment and decrement in mathematical expressions and to replace it with and the like or to perform the in/decrement separately. It is easier for human readers to understand and for the compiler to optimize when mathematical expressions have no Side Effects. We will see quite soon why (§1.3.12).
The unary minus negates the value of a number:
The unary plus has no arithmetic effect on standard types. For user types, we can define the behavior of both unary plus and minus. As shown in Table 1–2, these unary operators have the same priority as pre-increment and pre-decrement.
The operations and are naturally multiplication and division, and both are defined on all numeric types. When both arguments in a division are integers, then the fractional part of the result is truncated (rounding toward zero). The operator yields the remainder of the integer division. Thus, both arguments should have an integral type.
Last but not least, the operators and between two variables or expressions symbolize addition and subtraction.
The semantic details of the operations—how results are rounded or how overflow is handled—are not specified in the language. For performance reasons, C++ leaves this typically to the underlying hardware.
In general, unary operators have higher priority than binary. On the rare occasions that both postfix and prefix unary notations have been applied, prefix notations are prioritized over postfix notations.
Among the binary operators, we have the same behavior that we know from math: multiplication and division precede addition and subtraction and the operations are left associative, i.e.:
is always interpreted as
Something really important to remember: the order of evaluation of the arguments is not defined. For instance:
In this example, associativity guarantees that the first addition is performed before the second. But whether the expression or is computed first depends on the compiler implementation. Thus, might be either or . Furthermore, we cannot assume that the result is the same on a different platform. In general, it is dangerous to modify values within expressions. It works under some conditions, but we always have to test it and pay enormous attention to it. Altogether, our time is better spent by typing some extra letters and doing the modifications separately. More about this topic in Section 1.3.12.
With these operators, we can write our first (complete) numeric program:
When the arguments of a binary operation have different types, one or both arguments are automatically converted (coerced) to a common type according to the rules in Section C.3.
The conversion may lead to a loss of precision. Floating-point numbers are preferred over integer numbers, and evidently the conversion of a 64-bit to a 32-bit yields an accuracy loss; even a 32-bit cannot always be represented correctly as a 32-bit since some bits are needed for the exponent. There are also cases where the target variable could hold the correct result but the accuracy was already lost in the intermediate calculations. To illustrate this conversion behavior, let us look at the following example:
This leads on the author’s platform to
In the case of we lose accuracy due to the intermediate conversions, whereas was computed correctly. This is admittedly an artificial example, but you should be aware of the risk of imprecise intermediate results.
The issue of inaccuracy will fortunately not bother us in the next section.
1.3.2 Boolean Operators
Boolean operators are logical and relational operators. Both return values as the name suggests. These operators and their meaning are listed in Table 1–3, grouped by precedence.
Table 1–3: Boolean Operators
Greater than or equal to
Less than or equal to
Not equal to
Binary relational and logical operators are preceded by all arithmetic operators. This means that an expression like is evaluated as if it were written . Conversely, the unary operator for logic negation is prioritized over all binary operators.
In old (or old-fashioned) code, you might see logical operations performed on values. Please refrain from this: it is less readable and subject to unexpected behavior.
Please note that comparisons cannot be chained like this:
Instead we need the more verbose logical reduction:
In the following section, we will see quite similar operators.
1.3.3 Bitwise Operators
These operators allow us to test or manipulate single bits of integral types. They are important for system programming but less so for modern application development. Table 1–4 lists all operators by precedence.
Table 1–4: Bitwise Operators
Bitwise exclusive OR
Bitwise inclusive OR
The operation shifts the bits of to the left by positions. Conversely, moves ’s bits times to the right. In most cases, 0s are moved in except for negative values in a right shift where it is implementation-defined. The bitwise AND can be used to test a specific bit of a value. Bitwise inclusive OR can set a bit and exclusive OR flip it. These operations are more important in system programming than scientific applications. As algorithmic entertainment, we will use them in §3.6.1.
The value of an object (modifiable lvalue) can be set by an assignment:
When the types do not match, is converted to the type of if possible. The assignment is right-associative so that a value can be successively assigned to multiple objects in one expression:
Speaking of assignments, the author will now explain why he left-justifies the symbol. Most binary operators are symmetric in the sense that both arguments are values. In contrast, assignments have a modifiable variable on the left-hand side. While other languages use asymmetric symbols (e.g., in Pascal), the author uses an asymmetric spacing in C++.
The compound assignment operators apply an arithmetic or bitwise operation to the object on the left side with the argument on the right side; for instance, the following two operations are equivalent:
All assignment operators have a lower precedence than every arithmetic or bitwise operation so the right-hand side expression is always evaluated before the compound assignment:
The assignment operators are listed in Table 1–5. They are all right-associative and of the same priority.
Table 1–5: Assignment Operators
Multiply and assign
Divide and assign
Modulo and assign
Add and assign
Subtract and assign
Shift left and assign
Shift right and assign
AND and assign
Inclusive OR and assign
Exclusive OR and assign
1.3.5 Program Flow
There are three operators to control the program flow. First, a function call in C++ is handled like an operator. For a detailed description of functions and their calls, see Section 1.5.
The conditional operator evaluates the condition , and when it is true the expression has the value of , otherwise . It can be used as an alternative to branches with , especially in places where only an expression is allowed and not a statement; see Section 126.96.36.199.
A very special operator in C++ is the Comma Operator that provides a sequential evaluation. The meaning is simply evaluating first the sub-expression to the left of the comma and then that to the right of it. The value of the whole expression is that of the right sub-expression:
The result of the expression is 65.1 and the computation of the first sub-expression is entirely irrelevant. The sub-expressions can contain the comma operator as well so that arbitrarily long sequences can be defined. With the help of the comma operator, one can evaluate multiple expressions in program locations where only one expression is allowed. A typical example is the increment of multiple indices in a -loop (§188.8.131.52):
When used as a function argument, the comma expression needs surrounding parentheses; otherwise the comma is interpreted as separation of function arguments.
1.3.6 Memory Handling
The operators and allocate and deallocate memory respectively; see Section 1.8.2.
1.3.7 Access Operators
C++ provides several operators for accessing sub-structures, for referring—i.e., taking the address of a variable—and dereferencing—i.e., accessing the memory referred to by an address. Discussing these operators before talking about pointers and classes makes no sense. We thus postpone their description to the sections given in Table 1–6.
Table 1–6: Access Operators
Dereferred member selection
Dereferred member dereference
1.3.8 Type Handling
The operators for dealing with types will be presented in Chapter 5 when we will write compile-time programs that work on types. The available operators are listed in Table 1–7.
Table 1–7: Type-Handling Operators
Run-time type identification
Identification of a type
Size of object
Size of type
Number of arguments
Number of type arguments
Alignment of type
Note that the operator when used on an expression is the only one that is applicable without parentheses. is introduced in C++11; all others exist since 98 (at least).
1.3.9 Error Handling
The operator is used to indicate an exception in the execution (e.g., insufficient memory); see Section 1.6.2.
A very powerful aspect of C++ is that the programmer can define operators for new types. This will be explained in Section 2.7. Operators of built-in types cannot be changed. However, we can define how built-in types interact with new types; i.e., we can overload mixed operations like double times matrix.
Most operators can be overloaded. Exceptions are:
Member selection (may be added in C++17);
Member selection through pointer;
Size of a type or object;
Number of arguments;
Memory alignment of a type or object; and
The operator overloading in C++ gives us a lot of freedom and we have to use this freedom wisely. We come back to this topic in the next chapter when we actually overload operators (wait till Section 2.7).
1.3.11 Operator Precedence
Table 1–8 gives a concise overview of the operator priorities. For compactness, we combined notations for types and expressions (e.g., ) and fused the different notations for and . The symbol represents all computational assignments like , , and so on. A more detailed summary of operators with semantics is given in Appendix C, Table C–1.
Table 1–8: Operator Precedence
1.3.12 Avoid Side Effects!
- “Insanity: doing the same thing over and over again and expecting different results.”
In applications with side effects it is not insane to expect a different result for the same input. To the contrary, it is very difficult to predict the behavior of a program whose components interfere massively. Moreover, it is probably better to have a deterministic program with the wrong result than one that occasionally yields the right result since the latter is usually much harder to fix.
In the C standard library, there is a function to copy a string (). The function takes pointers to the first of the source and the target and copies the subsequent letters until it finds a zero. This can be implemented with one single loop that even has an empty body and performs the copy and the increments as side effects of the continuation test:
Looks scary? Well, it is somehow. However, this is absolutely legal C++ code, although some compilers might grumble in pedantic mode. It is a good mental exercise to spend some time thinking about operator priorities, types of sub-expressions, and evaluation order.
Let us think about something simpler: we assign the value to the -th entry of an array and increment the value for the next iteration:
Looks like no problem. But it is: the behavior of this expression is undefined. Why? The post-increment of guarantees that we assign the old value of and increment afterward. However, this increment can still be performed before the expression is evaluated so that we possibly assign to .
The last example should give you an impression that side effects are not always evident at first glance. Some quite tricky stuff might work but much simpler things might not. Even worse, something might work for a while until somebody compiles it on a different compiler or the new release of your compiler changes some implementation details.
The first snippet is an example of excellent programming skills and evidence that the operator precedence makes sense—no parentheses were needed. Nonetheless, such programming style is not appropriate for modern C++. The eagerness to shorten code as much as possible dates back to the times of early C when typing was more demanding, with typewriters that were more mechanical than electrical, and card punchers, all without a monitor. With today’s technology, it should not be an issue for the digital natives to type some extra letters.
Another unfavorable aspect of the terse copy implementation is the mingling of different concerns: testing, modification, and traversal. An important concept in software design is Separation of Concerns. It contributes to increasing flexibility and decreasing complexity. In this case, we want to decrease the complexity of the mental processes needed to understand the implementation. Applying the principle to the infamous copy one-liner could yield
Now, we can clearly distinguish the three concerns:
It is also more apparent that the incrementing is performed on the pointers and the testing and assignment on their referred content. The implementation is not as compact as before, but it is much easier to check the correctness. It is also advisable to make the non-zero test more obvious ().
There is a class of programming languages that are called Functional Languages. Values in these languages cannot be changed once they are set. C++ is obviously not that way. But we do ourselves a big favor when we program as much as is reasonable in a functional style. For instance, when we write an assignment, the only thing that should change is the variable to the left of the assignment symbol. To this end, we have to replace mutating with a constant expression: for instance, with . A right-hand side expression without side effects helps us to understand the program behavior and makes it easier for the compiler to optimize the code. As a rule of thumb: more comprehensible programs have a better potential for optimization.
The following table lists the precedence and associativity of C operators. Operators are listed top to bottom, in descending precedence.
|1||Suffix/postfix increment and decrement||Left-to-right|
|Structure and union member access|
|Structure and union member access through pointer|
|2||Prefix increment and decrement||Right-to-left|
|Unary plus and minus|
|Logical NOT and bitwise NOT|
|3||Multiplication, division, and remainder||Left-to-right|
|4||Addition and subtraction|
|5||Bitwise left shift and right shift|
|6||For relational operators < and ≤ respectively|
|For relational operators > and ≥ respectively|
|7||For relational = and ≠ respectively|
|9||Bitwise XOR (exclusive or)|
|10||Bitwise OR (inclusive or)|
|13[note 2]||Ternary conditional[note 3]||Right-to-Left|
|Assignment by sum and difference|
|Assignment by product, quotient, and remainder|
|Assignment by bitwise left shift and right shift|
|Assignment by bitwise AND, XOR, and OR|
- ↑The operand of can't be a type cast: the expression is unambiguously interpreted as , but not .
- ↑Fictional precedence level, see Notes below
- ↑The expression in the middle of the conditional operator (between and ) is parsed as if parenthesized: its precedence relative to is ignored.
When parsing an expression, an operator which is listed on some row will be bound tighter (as if by parentheses) to its arguments than any operator that is listed on a row further below it. For example, the expression *p++ is parsed as *(p++), and not as (*p)++.
Operators that are in the same cell (there may be several rows of operators listed in a cell) are evaluated with the same precedence, in the given direction. 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.
Precedence and associativity are independent from order of evaluation.
The C language standard doesn't specify operator precedence. It specifies the language grammar, and the precedence table is derived from it to simplify understanding. There is a part of the grammar that cannot be represented by a precedence table: an assignment-expression is not allowed as the right hand operand of a conditional operator, so e = a < d ? a++: a = d is an expression that cannot be parsed, and therefore relative precedence of conditional and assignment operators cannot be described easily.
However, many C compilers use non-standard expression grammar where is designated higher precedence than , which parses that expression as e =(((a < d)?(a++): a)= d ), which then fails to compile due to semantic constraints: is never lvalue and requires a modifiable lvalue on the left. This is the table presented on this page.
Note that this is different in C++, where the conditional operator has the same precedence as assignment.
Associativity specification is redundant for unary operators and is only shown for completeness: unary prefix operators always associate right-to-left (sizeof++*p is sizeof(++(*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++).
- C11 standard (ISO/IEC 9899:2011):
- C99 standard (ISO/IEC 9899:1999):
- C89/C90 standard (ISO/IEC 9899:1990):
Order of evaluation of operator arguments at run time.
a = b
a == b