function 调用的顺序。 它是编译器还是取决于情况？

Question

It came to my attention the following fact : order of function evaluation, for example in a sum, is unspecified in the standard, and can therefore be performed in any order.

This raises the question: is it compiler dependent, optimization dependent, or potentially even execution dependent (I doubt it, it may involve reshuffling of the code, but in today's multicore environments, I guess some compilers may see a chance for optimization in this lack of specification, by implicitly performing the two calls in parallel)?

Edit : I want to clarify. The fact that order is unspecified in the standard, does not imply it's unspecified for a particular compiler (which may choose to make it specified in the documentation, I assume). Unspecified behavior may make you non-portable, but the compiler may behave consistently according to a given rule. I am interested in knowing, purely for academic curiosity, if this specification is actually made by compilers (eg in the manual) and if yes, if this choice is consistent or may be altered by compiler options or other factors. Example, take gcc. How does it behave? is it consistent?

Answer 1

It's unspecified - what more can we say? As you should never write code that depends on the order (because the compiler certainly could change it), the question is of academic interest only. If you are really interested in what your specific compiler gets up to, examine the emitted machine code in the scenarios that interest you.

Answer 2

It can't interleave function calls (in cases where you can tell the difference) because there are sequence points at calling and returning from a function.

Other than that, the compiler can evaluate parts of an expression in any order it sees fit. The standard explicitly states that it doesn't prescribe an order, except what follows from the operators used in the expression.

Answer 3

Answering your second question:

Edit: I want to clarify. The fact that order is unspecified in the standard, does not imply it's unspecified for a particular compiler (which may choose to make it specified in the documentation, I assume). Unspecified behavior may make you non-portable, but the compiler may behave consistently according to a given rule. I am interested in knowing, purely for academic curiosity, if this specification is actually made by compilers (eg in the manual) and if yes, if this choice is consistent or may be altered by compiler options or other factors. Example, take gcc. How does it behave? is it consistent?

I have never seen this documented for any compiler. Doing so would limit the options for future versions of the compiler, without giving much value to the users of the current version. If you have a particular need for a specific evaluation order, you can always get that by adding a few extra semicolons!

Code isn't optimized one statement at a time, but over the whole function or even larger parts if code is inlined. How you evaluate a particular statement depends on the surrounding code. Perhaps one value has already been computed and used in a preceding statement? It may already be present in a CPU register and can be reused.

Or perhaps one of the subexpressions can be reused later, if it is computed last? That an affect the evaluation order, as can the calling convention used for a specific call.

It is anyway generally a bad idea to code against the specifics of a particular compiler. You never know when you will have to port to another one.