C++ Core Guidelines: Rules for Expressions

Contents[Show]

Today's post is about expressions. You should avoid complicated expressions, you should know the precedence rules for arithmetic or logical expressions, and you should know the order of evaluation of expressions. Having the wrong precedence rules for expressions in mind or assuming an evaluation order for expressions which is just wrong or not guaranteed are the main reasons for undefined behaviour. 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 so 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 next rule. The expressions (2) may be fine 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 behaviour, 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.

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

On one hand, the guidelines says: If you are in doubt about 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.

OperatorPrecedence

I will right jump to the rules ES.43 and ES.44 and will write about 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 behaviour. 

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 behaviour.

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

  1. Postfix expressions are evaluated from left to right. This includes functions 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.b
a->b
a->*b
a(b1, b2, b3)        // (1)
b @= a
a[b]
a << b
a >> b

 

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

Expression (1) is a bit tricky. With C++17 we have only the 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:

gcc

 

 

  • clang

clang

With C++17, this behaviour didn't change. The order of evaluation is unspecified. But at least, the order of the evaluation of 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 functions 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 behaviour.

What's next?

Admitted, this was a quite a challenging post but a challenge you have to 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: Eric Pederson, Paul Baxter, Carlos Gomes Martinho, and SAI RAGHAVENDRA PRASAD POOSA.




Get your e-book at leanpub:


The C++ Standard Library

 

Concurrency With Modern C++

 

Get Both as one Bundle

cover   ConcurrencyCoverFrame   bundle
With C++11, C++14, and C++17 we got a lot of new C++ libraries. In addition, the existing ones are greatly improved. The key idea of my book is to give you the necessary information to the current C++ libraries in about 200 pages.  

C++11 is the first C++ standard that deals with concurrency. The story goes on with C++17 and will continue with C++20.


I'll give you a detailed insight in the current and the upcoming concurrency in C++. This insight includes the theory and a lot of practice with more the 100 source files.

 

Get my books "The C++ Standard Library" (including C++17) and "Concurrency with Modern C++" in a bundle.


In sum, you get more than 550 pages full of modern C++ and more than 100 source files presenting concurrency in practice.


 

Add comment


My Newest E-Books

Latest comments

Subscribe to the newsletter (+ pdf bundle)

Blog archive

Source Code

Visitors

Today 116

All 776037

Currently are 251 guests and no members online