C++ Core Guidelines: Rules for Expressions


Today's post is about expressions. You should avoid complicated expressions, know the precedence rules for arithmetic or logical expressions, and know the order of evaluation of expressions. The main reasons for undefined behavior are having the wrong precedence rules for expressions in mind or assuming an evaluation order for expressions that is just wrong or not guaranteed. I know that's a lot to digest. Let's start.


Polynomial expansion

Here are the four rules for today.

The rules for the precedence and the evaluation are not as easy as it sounds. They even change with C++17; therefore, we should start simple.

ES.40: Avoid complicated expressions

What does complicated mean? Here is the original example of the guidelines:


// bad: assignment hidden in subexpression                      (1)
while ((c = getc()) != -1)

// bad: two non-local variables assigned in a sub-expressions   (1)
while ((cin >> c1, cin >> c2), c1 == c2)

// better, but possibly still too complicated                   (1)
for (char c1, c2; cin >> c1 >> c2 && c1 == c2;)

// OK: if i and j are not aliased                               (2)
int x = ++i + ++j;                 

// OK: if i != j and i != k                                     (2)
v[i] = v[j] + v[k];

// bad: multiple assignments "hidden" in subexpressions         (1)
x = a + (b = f()) + (c = g()) * 7;

// bad: relies on commonly misunderstood precedence rules       (1)
x = a & b + c * d && e ^ f == 7;

// bad: undefined behavior                                      (3)
x = x++ + x++ + ++x;


I added a few (numbers) to it. First, all expressions having a (1) are bad style and should not pass a code review. For example, do you know what is happening here: x = a & b + c * d && e ^ f == 7;. Of course, you have to look up the precedences of the operators. I will come to it in the following rule. The expression (2) may be acceptable if the conditions hold. i and j must be disjunct, and the indices i,j, and i,k must be pairwise disjunct.

(3) is undefined behavior, because it is not defined which x will be evaluated first. Why? The argument is that the final semicolon ";" is a sequence point, and now we have the guarantee that all side effects from the previous evaluations in the sequence are complete.

With C++17, the rules for operator precedence changed: left-to-right for expressions except for right-to-left in assignments. I will write about it in ES.43.


Rainer D 6 P2 540x540Modernes C++ Mentoring

Be part of my mentoring programs:





Do you want to stay informed about my mentoring programs: Subscribe via E-Mail.

ES.41: If in doubt about operator precedence, parenthesize

On the one hand, the guidelines say: If you doubt operator precedence, use parenthesis (1). On the other hand, they state: You should know enough not to need parentheses here (2):


const unsigned int flag = 2;
unsigned int a = flag;

if (a & flag != 0)  // bad: means a&(flag != 0)         (1)

if (a < 0 || a <= max) {  // good: quite obvious        (2)
    // ...


Okay. For an expert, expression (1) may be obvious, but for a beginner, expression (2) may be a challenge. 

I have only two tips in mind according to the guidelines:

  1. If in doubt about precedence, use parentheses. Do not forget the beginners!
  2. Keep this precedence table from cppreference.com under your pillow.


I will jump right to the rules ES.43 and ES.44 and write about the rule ES.42 in my next post. With C++17, the order of evaluation of expressions changed.

ES.43: Avoid expressions with undefined order of evaluation

In C++14, the following expression has undefined behavior. 

v[i] = ++i;   //  the result is undefined


This will not hold for C++17. With C++17, the order of evaluation of the last code snippet is right to left; therefore, the expression has well-defined behavior.

Here are the additional guarantees we have with C++17:

  1. Postfix expressions are evaluated from left to right. This includes function calls and member selection expressions.
  2. Assignment expressions are evaluated from right to left. This includes compound assignments.
  3. Operands to shift operators are evaluated from left to right. 

This was the wording of the original proposal. They also provided a few examples. Here are they:

a(b1, b2, b3)        // (1)
b @= a
a << b
a >> b


How should you read these examples? Quite simple. First, a will be evaluated, then b, c, and d.

Expression (1) is a bit tricky. With C++17, we can only guarantee that the function is evaluated before its arguments, but the order of the evaluation of the arguments is still unspecified.

I know the last sentence was not easy. Let's elaborate a little bit more.

ES.44: Don’t depend on order of evaluation of function arguments

In the last years,  I saw many errors because developers assumed that the order of the evaluation of function arguments is left to right. Wrong! You have no guarantees!

#include <iostream>

void func(int fir, int sec){
    std::cout << "(" << fir << "," << sec << ")" << std::endl;

int main(){
    int i = 0;
    func(i++, i++);


Here is my proof. The output from Gcc and clang differs:

  • Gcc:




  • clang


With C++17, this behavior didn't change. The order of evaluation is unspecified. But at least the order of evaluating the following expressions is specified with C++17.


f1()->m(f2());          // evaluation left to right  (1)
cout << f1() << f2();   // evaluation left to right  (2)

f1() = f(2);            // evaluation right to left  (3)


Here is the reason why:

(1): Postfix expressions are evaluated from left to right. This includes function calls and member selection expressions.

(2): Operands to shift operators are evaluated from left to right.

(3): Assignment expressions are evaluated from right to left.

Only to remind you. With C++14, the last three expressions have undefined behavior.

What's next?

Admittedly, this was quite a challenging post but a challenge you must overcome to become a good programmer. The main topic of my next post will be about cast operations.




Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Animus24, Jozo Leko, John Breland, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Kris Kafka, Mario Luoni, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Daniel Hufschläger, Alessandro Pezzato, Bob Perry, Satish Vangipuram, Andi Ireland, Richard Ohnemus, Michael Dunsky, Leo Goodstadt, John Wiederhirn, Yacob Cohen-Arazi, Florian Tischler, Robin Furness, Michael Young, Holger Detering, Bernd Mühlhaus, Matthieu Bolt, Stephen Kelley, Kyle Dean, Tusar Palauri, Dmitry Farberov, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, Wolfgang Fütterer, Matthias Grün, Phillip Diekmann, Ben Atakora, Ann Shatoff, and Rob North.


Thanks, in particular, to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, John Nebel, Mipko, Alicja Kaminska, and Slavko Radman.



My special thanks to Embarcadero CBUIDER STUDIO FINAL ICONS 1024 Small


My special thanks to PVS-Studio PVC Logo


My special thanks to Tipi.build tipi.build logo


My special thanks to Take Up Code TakeUpCode 450 60



I'm happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions.

Bookable (Online)


Standard Seminars (English/German)

Here is a compilation of my standard seminars. These seminars are only meant to give you a first orientation.

  • C++ - The Core Language
  • C++ - The Standard Library
  • C++ - Compact
  • C++11 and C++14
  • Concurrency with Modern C++
  • Design Pattern and Architectural Pattern with C++
  • Embedded Programming with Modern C++
  • Generic Programming (Templates) with C++


  • Clean Code with Modern C++
  • C++20

Contact Me

Modernes C++,


Stay Informed about my Mentoring



English Books

Course: Modern C++ Concurrency in Practice

Course: C++ Standard Library including C++14 & C++17

Course: Embedded Programming with Modern C++

Course: Generic Programming (Templates)

Course: C++ Fundamentals for Professionals

Course: The All-in-One Guide to C++20

Course: Master Software Design Patterns and Architecture in C++

Subscribe to the newsletter (+ pdf bundle)

All tags

Blog archive

Source Code


Today 3866

Yesterday 4344

Week 40744

Month 20990

All 12099199

Currently are 151 guests and no members online

Kubik-Rubik Joomla! Extensions

Latest comments