What Are the Evaluation Order Guarantees Introduced by C++17

What are the evaluation order guarantees introduced by C++17?

Some common cases where the evaluation order has so far been unspecified, are specified and valid with C++17. Some undefined behaviour is now instead unspecified.

i = 1;
f(i++, i)

was undefined, but it is now unspecified. Specifically, what is not specified is the order in which each argument to f is evaluated relative to the others. i++ might be evaluated before i, or vice-versa. Indeed, it might evaluate a second call in a different order, despite being under the same compiler.

However, the evaluation of each argument is required to execute completely, with all side-effects, before the execution of any other argument. So you might get f(1, 1) (second argument evaluated first) or f(1, 2) (first argument evaluated first). But you will never get f(2, 2) or anything else of that nature.

std::cout << f() << f() << f();

was unspecified, but it will become compatible with operator precedence so that the first evaluation of f will come first in the stream (examples below).

f(g(), h(), j());

still has unspecified evaluation order of g, h, and j. Note that for getf()(g(),h(),j()), the rules state that getf() will be evaluated before g, h, j.

Also note the following example from the proposal text:

 std::string s = "but I have heard it works even if you don't believe in it"
 s.replace(0, 4, "").replace(s.find("even"), 4, "only")
  .replace(s.find(" don't"), 6, "");

The example comes from The C++ Programming Language, 4th edition, Stroustrup, and used to be unspecified behaviour, but with C++17 it will work as expected. There were similar issues with resumable functions (.then( . . . )).

As another example, consider the following:

#include <iostream>
#include <string>
#include <vector>
#include <cassert>

struct Speaker{
    int i =0;
    Speaker(std::vector<std::string> words) :words(words) {}
    std::vector<std::string> words;
    std::string operator()(){
        assert(words.size()>0);
        if(i==words.size()) i=0;
        // Pre-C++17 version:
        auto word = words[i] + (i+1==words.size()?"\n":",");
        ++i;
        return word;
        // Still not possible with C++17:
        // return words[i++] + (i==words.size()?"\n":",");

    }
};

int main() {
    auto spk = Speaker{{"All", "Work", "and", "no", "play"}};
    std::cout << spk() << spk() << spk() << spk() << spk() ;
}

With C++14 and before we may (and will) get results such as

play
no,and,Work,All,

instead of

All,work,and,no,play

Note that the above is in effect the same as

(((((std::cout << spk()) << spk()) << spk()) << spk()) << spk()) ;

But still, before C++17 there was no guarantee that the first calls would come first into the stream.

References: From the accepted proposal:

Postfix expressions are evaluated from left to right. This includes
functions calls and member selection expressions.

Assignment expressions are evaluated from right to left. This
includes compound assignments.

Operands to shift operators are evaluated from left to right. In
summary, the following expressions are evaluated in the order a, then
b, then c, then d:

1. a.b
2. a->b
3. a->*b
4. a(b1, b2, b3)
5. b @= a
6. a[b]
7. a << b
8. a >> b

Furthermore, we suggest the following additional rule: the order of
evaluation of an expression involving an overloaded operator is
determined by the order associated with the corresponding built-in
operator, not the rules for function calls.

Edit note: My original answer misinterpreted a(b1, b2, b3). The order of b1, b2, b3 is still unspecified. (thank you @KABoissonneault, all commenters.)

However, (as @Yakk points out) and this is important: Even when b1, b2, b3 are non-trivial expressions, each of them are completely evaluated and tied to the respective function parameter before the other ones are started to be evaluated. The standard states this like this:

§5.2.2 - Function call 5.2.2.4:

. . .
The postfix-expression is sequenced before each expression in the
expression-list and any default argument. Every value computation and
side effect associated with the initialization of a parameter, and the
initialization itself, is sequenced before every value computation and
side effect associated with the initialization of any subsequent
parameter.

However, one of these new sentences are missing from the GitHub draft:

Every value computation and side effect associated with the
initialization of a parameter, and the initialization itself, is
sequenced before every value computation and side effect associated
with the initialization of any subsequent parameter.

The example is there. It solves a decades-old problems (as explained by Herb Sutter) with exception safety where things like

f(std::unique_ptr<A> a, std::unique_ptr<B> b);

f(get_raw_a(), get_raw_a());

would leak if one of the calls get_raw_a() would throw before the other
raw pointer was tied to its smart pointer parameter.

As pointed out by T.C., the example is flawed since unique_ptr construction from raw pointer is explicit, preventing this from compiling.*

Also note this classical question (tagged C, not C++):

int x=0;
x++ + ++x;

is still undefined.

Weird C++14 and C++17 difference in assignment operator

This code is UB prior to C++17, as pointed out in comments, due to C++ evaluation order rules. The basic problem: Order of operations is not order of evaluation. Even something like x++ + x++ is UB.

In C++17, sequencing rules for assignments were changed:

20. In every simple assignment expression E1=E2 and every compound
    assignment expression E1@=E2, every value computation and side-effect
    of E2 is sequenced before every value computation and side effect of
    E1

c++17 evaluation order with operator overloading functions

"As the second one looks like a function call, hence there is no guaranteed evaluation order in the parameters?"

Indeed. [expr.call]/5 contains an example specifically covering the difference between the two cases covered in your question [emphasis mine]:

The postfix-expression is sequenced before each expression in the
expression-list and any default argument. The initialization of a
parameter, including every associated value computation and side
effect, is indeterminately sequenced with respect to that of any other
parameter.

...

Note: If an operator function is invoked using operator notation,
argument evaluation is sequenced as specified for the built-in
operator; see
[over.match.oper].
[ Example:

struct S {
  S(int);
};
int operator<<(S, int);
int i, j;
int x = S(i=1) << (i=2);
int y = operator<<(S(j=1), j=2);

After performing the initializations, the value of i is 2 (see
[expr.shift]), but it is unspecified whether the value of j is
1 or 2.

— end example ]

Order of evaluation with function pointers in C++17

The C++17 rule is, from [expr.call]/8:

The postfix-expression is sequenced before each expression in the expression-list and any default argument. The initialization of a parameter, including every associated value computation and side effect, is indeterminately sequenced with respect to that of any other parameter.

In (T(f))((f=b,0));, (T(f)) is sequenced before the initialization of the parameter from (f=b, 0). All of this is well-defined and the program should print "a". That is, it should behave just like:

auto __tmp = T(f);
__tmp((f=b, 0));

The same is true even if we change your program such that this were valid:

T{f}(f=b, 0); // two parameters now, instead of one

The f=b and 0 expressions are indeterminately sequenced with each other, but T{f} is still sequenced before both, so this would still invoke a.

Filed 91974.

Shift operands sequenced in C++17

Standard is clear about the order of evaluation of the operands of the shift operator.

n4659 - §8.8 (p4):

The expression E1 is sequenced before the expression E2.

There is no undefined behavior in the expression i++ << i, it is well defined. It is a bug in Clang and GCC both.

IF argument evaluation order?

The evaluation order is specified by the standard and is left-to-right. The left-most expression will always be evaluated first with the && clause.

If you want b to be evaluated first:

if(b && a)
{
  //do something
}

If both arguments are methods and you want both of them to be evaluated regardless of their result:

bool rb = b();
bool ra = a();

if ( ra && rb )
{
  //do something
}

Order of evaluation in C++ function parameters

No, there's no such guarantee. It's unspecified according to the C++ standard.

Bjarne Stroustrup also says it explicitly in "The C++ Programming Language" 3rd edition section 6.2.2, with some reasoning:

Better code can be generated in the
absence of restrictions on expression
evaluation order

Although technically this refers to an earlier part of the same section which says that the order of evaluation of parts of an expression is also unspecified, i.e.

int x = f(2) + g(3);   // unspecified whether f() or g() is called first

Why doesn't c++ have a specified order for evaluating function arguements?

Why doesn't C++ do it this way?

For starters, C++ isn't a functional programming language.

And the fastest way to evaluate the arguments depends on the implementation and architecture, so the compiler gets to choose. We don't pay for what we don't use, in C++, so if you need to specify an evaluation order yourself then you can do so explicitly with named variables.

Although, continuing the theme of newer standards leaving behind sacred C++ paradigms, C++17 will sadly add some evaluation order guarantees, ruining all of that.

---

Related Topics