undefined behavior for int i = f1() * f2()

Question

I am confused as to why would this result in an undefined behavior. Let me copy and paste the explanation from the textbook first and then show my own code and program which runs perfectly.

Precedence specifies how the operands are grouped. It says nothing about the order in which the operands are evaluated. In most cases, the order is largely unspecified. In the following expression* int i = f1() * f2();:

*We know that f1 and f2 must be called before the multiplication can be done. After all, it is their results that are multiplied. However, we have no way of knowing whether f1 will be called before f2 or vice versa. For operators that do not specify evaluation order, it is an error for an expression to refer to and change the same object. Expressions that do so have undefined behavior (§ 2.1.2, p. 36). As a simple example, the << operator makes no guarantees about when or how its operands are evaluated. As a result, the following output expression is undefined.

-- C++ Primer - Page 193 by Stanley B. Lippman

So, I tried to apply this by writing my own code and I never get an undefined behavior? Can someone please explain what does this mean?

#include <iostream>

using std::cout;
using std::endl;

int f1() { return (5 + 5 * 4 / 2 - 3); } // 12
int f2() { return (10 + 2 * 10 / 2 - 5); } // 15

int main()
{
    int i = f1() * f2();
    cout << i << endl;
    return 0;
}

Answer 1

You're getting it wrong. The author means IF the order matters, it's unspecified. In your case, the order of evaluation doesn't matter. In fact, the function might as well be constexpr. But if you had something like this:

int i = 0;

int f1() { return (i++) * 3; }
int f2() { return (i++) * 4; }

int main() {
    int a = f1() + f2();
}

Now, if f1 is called first, the result is 4. If f2 is called first, the result is 3. Thus, it's unspecified.

---

I never get an undefined behavior?

You can't really know that by simply running the program.

Answer 2

Your code is fine.

it is an error for an expression to refer to and change the same object

^{(bold mine)}

Your don't change any objects in your expressions, so the rule doesn't apply.

Here's an example of when the rule would apply:

int a = 42;
int i = a++ * a++;

Note that it would not apply if the change happened in a function:

int a = 42;
int foo() {return a++;}
int i = foo() * foo();

That's because the UB only happens when two accesses to an object are unsequenced relative to each other, i.e. can happen in any order including in parallel. This doesn't necessarily mean "in parallel threads", but can also mean "single thread, but processor instructions performing the tasks may be interleaved".

But two function calls on the same thread can't happen in parallel (and can't have their instructions interleaved). Rather, in this case, they are indeterminately sequenced, i.e. one strictly after the other, but it's unspecified which one is first.

Also note that

the << operator makes no guarantees about when or how its operands are evaluated

is no longer true starting from C++17.

Answer 3

From C++ draft standard:

3.64 [defns.undefined] undefined behavior

behavior for which this document imposes no requirements [Note 1: Undefined behavior may be expected when this document omits any explicit definition of behavior or when a program uses an erroneous construct or erroneous data. Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message). Many erroneous program constructs do not engender undefined behavior; they are required to be diagnosed. Evaluation of a constant expression ([expr.const]) never exhibits behavior explicitly specified as undefined in [intro] through [cpp]. — end note]

Thus, almost everything is possible, even predictable behavior for a given implementation.

But, your program does not exhibit any UB. f1 and f2 do not have any border effect, thus the order of their evaluation has no impact.