So unless G++ is doing some sort of whole program analysis, it would have to do the cout << ... first and then evaluate the method and then print out the return value
Evaluation order is implementation-defined. I'm pretty sure all of the arguments are evaluated before any printing is done at all. The code
cout << "asdf:" << b()
is equivalent to
(cout << "asdf:") << b()
, which is equivalent to
cout.operator<<("asdf:").operator<<(b())
`b()` can certainly be evaluated before the first `operator<<` is evaluated. Hell, `b()` can be evaluated before "asdf;" is evaluated. Consider the following code:
int f() {
static int a=0;
return a++;
}
cout << f() << " " << f() << endl;
This prints "0 1" in Clang (at all levels of optimisation), and it prints out "1 0" in gcc (again, at all levels of optimisation). If they're differing on something as simple as this it's clearly allowable by the standard.
Sorta, yes. It can evaluate one of the operator<<'s before doing the timer. The following:
cout << "smarter sum " << N/(1000.0*time.split()) << endl;
Is semantically equivalent to:
operator<<(endl,
operator<<(N/1000.0*time.split(),
operator<<(cout, "smarter sum ")
)
);
The code with the timer in it can be called after the first call to operator<<; all parameters to functions have to be evaluated before the function is called, but there's no order the parameters themselves have to be evaluated in.
Even if they're doing whole program analysis, the fact that oeprator<<() and WallClockTimer.split() are side-effectful and I believe that means that it would be invalid for the compiler to find the current time before the first section of the print statement is finished.
