If I write f(x)->g(args, ...)
can I rely on a sequence point after f(x)
before the evaluation of args, ...
? I can see arguments both ways:
this
as if I'd written g(f(x), args, ...)
which suggests it's like an argument, and thus unspecified.The ->
operator is not a normal binary operator, since clearly g(...)
cannot be evaluated before f(x)
like it could if I wrote f(x) + g(...)
. I'm surprised I can't find some specific statement about it.
Yes, it matters. The arguments must be given in the order the function expects them.
Pre-C++11 Definitions A sequence point is a point in the execution sequence where all side effects from the previous evaluations in the sequence are complete, and no side effects of the subsequent evaluations started.
Order of evaluation refers to the operator precedence and associativity rules according to which mathematical expressions are evaluated.
Do not depend on the order of evaluation for side effects unless there is an intervening sequence point. If a side effect on a scalar object is unsequenced relative to either a different side effect on the same scalar object or a value computation using the value of the same scalar object, the behavior is undefined.
The answer depends on which version of the C++ standard you are using (or your compiler is using).
C++ 2003 5.2.2 p8 said:
The order of evaluation of arguments is unspecified. All side effects of argument expression evaluations take effect before the function is entered. The order of evaluation of the postfix expression and the argument expression list is unspecified.
This means there is not a sequence point between evaluating f(x)
and args
.
In C++ 2011 the whole concept of sequence points has been replaced (see N1944), and that wording is now just a note:
[ Note: The evaluations of the postfix expression and of the argument expressions are all unsequenced relative to one another. All side effects of argument expression evaluations are sequenced before the function is entered (see 1.9). — end note ]
and 1.9 p15 says
When calling a function (whether or not the function is inline), every value computation and side effect associated with any argument expression, or with the postfix expression designating the called function, is sequenced before execution of every expression or statement in the body of the called function. [ Note: Value computations and side effects associated with different argument expressions are unsequenced. — end note ]
This says the expression f(x)
and the expression args
are sequenced before everything in the body of g
, but that they are unsequenced relative to each other, which is the same as the C++03 rules but worded differently.
C++14 has the same rules as C++11, but as noted in the comment below, the rules changed in C++17.
C++ 2017 8.2.2 [expr.call] p5 says:
The postfix-expression is sequenced before each expression in the expression-list and any default argument. The initialization of a parameter, including every associated value computation and side effect, is indeterminately sequenced with respect to that of any other parameter.
This means for your example the following steps happen in order:
f
is evaluated.x
is evaluated and the parameters of f
are initialized.f(x)
is evaluated.f(x)->g
is evaluated.args
and the other arguments to g
are evaluated and the parameters of g
are initialized (in an unspecified order).f(x)->g(args, ...)
is evaluated.Note, I think that you're asking one question in your title, and another in the body of your question.
Well, it's not really contradictory. To evaluate your function, the following things have to happen (not necessarily in this order).
Now, the rules you've quoted indicate that
However, what is unsequenced is the relationship between (A), (B), and (C), or in your question between (B) and (C) and (D), since they aren't arguments to (F), they could be evaluated afterwards. OR, they could be evaluated prior.
* Interesting question. What happens if g(args, ...) is a static member function. In this case, since the returned pointer from f(x) isn't actually passed in, can it be sequenced earlier? But that's a separate question.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With