Order of evaluation of arguments using std::cout
Asked Answered
K

5

18

Hi all I stumbled upon this piece of code today and I am confused as to what exactly happens and more particular in what order :

Code :

#include <iostream>

bool foo(double & m)
{
    m = 1.0;
    return true;
}

int main()
{
    double test = 0.0;
    std::cout << "Value of test is : \t" << test << "\tReturn value of function is : " << foo(test) <<  "\tValue of test : " << test << std::endl;
    return 0;
}

The output is :

Value of test is :      1       Return value of function is : 1 Value of test : 0

Seeing this I would assume that somehow the right most argument is printed before the call to the function. So this is right to left evaluation?? During debugging though it seems that the function is called prior to the output which is what I would expect. I am using Win7 and MSVS 2010. Any help is appreciated!

Kyl answered 10/10, 2011 at 20:49 Comment(0)
O
28

The evaluation order of elements in an expression is unspecified (except some very particular cases, such as the && and || operators and the ternary operator, which introduce sequence points); so, it's not guaranteed that test will be evaluated before or after foo(test) (which modifies it).

If your code relies on a particular order of evaluation the simplest method to obtain it is to split your expression in several separated statements.

Octan answered 10/10, 2011 at 20:52 Comment(3)
Do you know of a trick using || or && to enforce a certain evaluation order in a << chain?Malina
No, but I know of a trick using ; and repeating the stream variable after a newline ;-)Octan
Maybe updating this answer with the changes introduced in the C++17 standard would be helpful for people stumbling upon this in the future: https://mcmap.net/q/673153/-what-is-run-first-inside-a-cout-statement-c-17Ivett
P
22

The answer to this question changed in C++17.

Evaluation of overloaded operators are now sequenced in the same way as for built-in operators (C++17 [over.match.oper]/2).

Furthermore, the <<, >> and subscripting operators now have the left operand sequenced before the right, and the postfix-expression of a function call is sequenced before evaluation of the arguments.

(The other binary operators retain their previous sequencing, e.g. + is still unsequenced).

So the code in the question must now output Value of test is : 0 Return value of function is : 1 Value of test : 1. But the advice "Don't do this" is still reasonable, given that it will take some time for everybody to update to C++17.

Perez answered 16/5, 2018 at 2:14 Comment(0)
G
12

Order of evaluation is unspecified. It is not left-to-right, right-to-left, or anything else.

Don't do this.

Goniometer answered 10/10, 2011 at 20:53 Comment(0)
N
3

The order of evaluation is unspecified, see http://en.wikipedia.org/wiki/Sequence_point

This is the same situation as the example with the operator+ example:

Consider two functions f() and g(). In C and C++, the + operator is not associated with a sequence point, and therefore in the expression f()+g() it is possible that either f() or g() will be executed first.

Nuncia answered 10/10, 2011 at 21:2 Comment(0)
I
1

the c++ reference explains very well why that should never be done (is causing an UB or undefined behaviour) https://en.cppreference.com/w/cpp/language/operator_incdec

#include <iostream>

int main()
{
    int n1 = 1;
    int n2 = ++n1;
    int n3 = ++ ++n1;
    int n4 = n1++;
//  int n5 = n1++ ++;   // error
//  int n6 = n1 + ++n1; // undefined behavior
    std::cout << "n1 = " << n1 << '\n'
              << "n2 = " << n2 << '\n'
              << "n3 = " << n3 << '\n'
              << "n4 = " << n4 << '\n';
}

Notes

Because of the side-effects involved, built-in increment and decrement operators must be used with care to avoid undefined behavior due to violations of sequencing rules.


and in the section related to sequencing rules you can read the following:

Undefined behavior:

1) If a side effect on a scalar object is unsequenced relative to another side effect on the same scalar object, the behavior is undefined.

i = ++i + 2;       // undefined behavior until C++11
i = i++ + 2;       // undefined behavior until C++17
f(i = -2, i = -2); // undefined behavior until C++17
f(++i, ++i);       // undefined behavior until C++17, unspecified after C++17
i = ++i + i++;     // undefined behavior

2) If a side effect on a scalar object is unsequenced relative to a value computation using the value of the same scalar object, the behavior is undefined.

cout << i << i++; // undefined behavior until C++17
a[i] = i++;       // undefined behavior until C++17
n = ++i + i;      // undefined behavior 
Ingleside answered 6/2, 2020 at 13:40 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.