1

I am reading the book of CPP-Concurrency-In-Action-2ed-2019. In chapter 5.3.2, the author gives a simple example:

#include <iostream>

void foo(int a, int b)
{
    std::cout << a << ", " << b << std::endl;
}

int get_num()
{
    static int i = 0;
    return ++i;
}

int main()
{
    foo(get_num(), get_num());
}

It says the two times of calling get_num() are in random sequence. And it could output 1, 2 or 2, 1.

But is it the same with below, which is definitely output in a fixed sequence.

int main()
{
    auto a = get_num();
    auto b = get_num();
    foo(a, b);
}

So why does the former output randomly?

JeJo
  • 30,635
  • 6
  • 49
  • 88
f1msch
  • 509
  • 2
  • 12
  • 3
    Because it is not the same. :-) There are cases, like `printf` with variable number of parameters, where evaluating right to left is good, because it leaves the format string on top. The compiler can choose any order it likes, and if **you** prefer a specific order, use version 2. – BoP Jul 14 '23 at 11:04
  • 4
    Minor point: it's not random. It's whatever the compiler decides to do. "I don't know how the compiler determines which one to generate first" is not the same as "it's random". – Pete Becker Jul 14 '23 at 11:30

3 Answers3

4

It boils down to: "These are the rules"

The C++ standard committee decided that they don't want to specify an order. This leaves it up to the compiler to decide which argument to evaluate first. The compiler may decide that the code would be more efficient if b is evaluated before a or the other way around. If the committee would have decided that the arguments need to be evaluated in order, compilers might have to generate less efficient code in certain situations.

chrysante
  • 2,328
  • 4
  • 24
4

The behavior of the first code snippet is due to the reason that the order of evaluation of the function arguments is unspecified. This means the compiler can evaluate the function arguments

foo(get_num(), get_num());

in any order, depending on how they are implemented get the best optimization. Read more related posts:

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
JeJo
  • 30,635
  • 6
  • 49
  • 88
0

In addition to the technical issues described above, there are also political considerations. And, yes, the standards committee is a political animal.

By the time the standards committee was facing this issue, there already were significant compilers in widespread use. Some of them did it one way, and some, the other. If the committee had picked a winner, it would have placed very real burdens on the losers. Not only would they have to rework their compilers, they would also face the issue of what to do about a large installed base of programs that had been created with their compilers. Some of those products would need to be recompiled and reshipped to customers.

So the best thing, politically, was to declare everyone to be a winner! Nobody had to rework their compiler, and nobody had to contact the buyers of its compiler to explain that products created with the compiler might need to be modified, recompiled and reshipped.

tbxfreeware
  • 547
  • 1
  • 9