In the expression a + b, is a guaranteed to be evaluated before b, or is the order of evaluation unspecified? I think it is the latter, but I struggle to find a definite answer in the standard.
Since I don't know whether C handles this different from C++, or if evaluation order rules were simplified in C++11, I'm gonna tag the question as all three.
In C++, for user-defined types a + b is a function call, and the standard says:
§5.2.2.8 - [...] The order of evaluation of function arguments is unspecified. [...]
For normal operators, the standard says:
§5.4 - Except where noted, the order of evaluation of operands of individual operators and subexpressions of individual expressions, and the order in which side effects take place, is unspecified. [...]
These haven't been changed for C++11. However, the wording changes in the second one to say that the order is "unsequenced" rather than unspecified, but it is essentially the same.
I don't have a copy of the C standard, but I imagine that it is the same there as well.
It is Unspecified.
Reference - C++03 Standard:
Section 5: Expressions, Para 4:
except where noted [e.g. special rules for && and ||], the order of evaluation of operands of individual operators and subexpressions of individual expressions, and the order in which side effects take place, is Unspecified.
C++0x FDIS section 1.9 "Program Execution" §15 is similar to the corresponding paragraph in C++03, just reworded to accommodate the conceptual change from "sequence points" to "being sequenced":
Except where noted, evaluations of operands of individual operators and of subexpressions of individual expressions are unsequenced.
It is unspecified. C and C++ follow the same logic in selecting sequence points:
https://en.wikipedia.org/wiki/Sequence_point
For C: "Order of operations is not defined by the language. The compiler is free to evaluate such expressions in any order, if the compiler can guarantee a consistent result." [...] "Only the sequential-evaluation (,), logical-AND (&&), logical-OR (||), conditional-expression (? :), and function-call operators constitute sequence points and therefore guarantee a particular order of evaluation for their operands."
Source: http://msdn.microsoft.com/en-us/library/2bxt6kc4.aspx
The way this is organized in that article, it seems to indicate this applies to C++ too, which is confirmed by the answer to this question: Operator Precedence vs Order of Evaluation.
According to the current C standard, C11, it also specifies that the order of evaluation of subexpressions (a and b in this case) is indeterminate. In fact, this order doesn't even have to be the same if the same expression is evaluated multiple times.
From section 6.5:
The grouping of operators and operands is indicated by the
syntax.85) Except as specified later, side effects and
value computations of subexpressions are unsequenced.86)
86) In an expression that is evaluated more than once during the
execution of a program, unsequenced and indeterminately sequenced
evaluations of its subexpressions need not be performed
consistently in different evaluations.
Related
I would very much appreciate it if someone could give a clarification on the sequencing of side effects for assignment statements in C++11. E.g., point me to the relevant standard text that deals with it.
The page on evaluation order on cpprefence.com states the following regarding assignments:
8) The side effect (modification of the left argument) of the built-in assignment operator and of all built-in compound assignment operators is sequenced after the value computation (but not the side effects) of both left and right arguments, and is sequenced before the value computation of the assignment expression (that is, before returning the reference to the modified object)
What is meant by "(but not the side effects)? Are the side effects unsequenced, inderminately sequenced or sequenced after the modification of the left argument (or perhaps even sequenced after the returning of the reference?
As an example when do the post-increment operations take place in:
while (*tgt++= *src++);
It seems clear from evaluation order that the value calculations are performed first, so *tgt and *src are calculated first. But is it known when post-increment side effects occur?
Edit #1:
Undefined behavior and sequence points does to my best understanding not answer my question. In fact it was the start of my descent into the "rabbit hole" that in the end led me to cppreference.com. What I specifically want to know is the definition of sequencing of side effects for the assignment operator in C++11. The question answered in Undefined behavior and sequence points is the relation between sequencing and the concepts of undefined, unspecied behaviour and impementation specific behaviour. Which, by the way, it answers very well.
End of Edit #1
Best regards
What is meant by "(but not the side effects)?
This remark emphasises the fact that the sentence makes no claims about sequencing of side effects.
Are the side effects unsequenced, inderminately sequenced or sequenced after the modification of the left argument (or perhaps even sequenced after the returning of the reference?
This is determined in paragraphs that discuss each specific side effect. For example, the side effect of the postfix increment operator is sequenced after its value computation, and it is stated that an indeterminately-sequenced function call cannot intervene. There are no other claims made about sequencing of this operator that I can find. If there are indeed none, one must conclude it is unsequenced w.r.t. the assignment.
First of all, note that C++17 introduced quite some changes to expression evaluation order.
Let's first see what the current standard draft has to say. I guess relevant here should be [intro.execution]/7
[…] Evaluation of an expression (or a subexpression) in general includes both value computations (including determining the identity of an object for glvalue evaluation and fetching a value previously assigned to an object for prvalue evaluation) and initiation of side effects. […]
and [intro.execution]/10
Except where noted, evaluations of operands of individual operators and of subexpressions of individual expressions are unsequenced. […] The value computations of the operands of an operator are sequenced before the value computation of the result of the operator. […]
and finally [expr.ass]/1
[…] In all cases, the assignment is sequenced after the value computation of the right and left operands, and before the value computation of the assignment expression.
The right operand is sequenced before the left operand. […]
Based on this, I would conclude that in
while (*tgt++ = *src++);
the evaluation of *src is sequenced before the evaluation of *tgt while the side-effects of each increment as well as the assignment are all unsequenced with respect to each other. Since the condition in a while loop is a full-expression, all evaluations and side effects occurring in one iteration of the loop are sequenced before the evaluations and side effects of the next iteration.
As far as I can see, in C++ 11, the evaluations of *src and *tgt were unsequenced with respect to each other but sequenced before the side effect of assignment. The side effects of the increments and the assignment were also unsequenced with respect to each other.
This question already has answers here:
What are the evaluation order guarantees introduced by C++17?
(3 answers)
Closed 2 years ago.
On cppreference I see the following text:
In a function call, value computations and side effects of the initialization of every parameter are indeterminately sequenced with respect to value computations and side effects of any other parameter.
Hovewer, I wasn't able to find any confirmation of this in C++17 standard.
Function parameters, as subexpressions, should comply with [intro.execution.17]:
Except where noted, evaluations of operands of individual operators and of subexpressions of individual
expressions are unsequenced. [ Note: In an expression that is evaluated more than once during the execution
of a program, unsequenced and indeterminately sequenced evaluations of its subexpressions need not be
performed consistently in different evaluations. — end note ] The value computations of the operands of
an operator are sequenced before the value computation of the result of the operator. If a side effect on a
memory location (4.4) is unsequenced relative to either another side effect on the same memory location or a
value computation using the value of any object in the same memory location, and they are not potentially
concurrent (4.7), the behavior is undefined. [ Note: The next section imposes similar, but more complex
restrictions on potentially concurrent computations. — end note ]
Which means, that function parameters calculation should be unsequenced unless it's prohibited by any other points in the standard. I tried to find a substring "indeterminately" in the standard text, and none of 10 occurrences look relevant to function call arguments.
So, the question is: are the function parameters unsequenced or indeterminately sequenced in C++17?
[expr.call]/5 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.
Emphasis mine.
There are lots of questions on concepts of precedence and order of evaluation but I failed to find one that refers to my special case.
Consider the following statement:
if(f(0) && g(0)) {};
Is it guaranteed that f(0) will be evaluated first? Notice that the operator is &&.
My confusion stems from what I've read in "The C++ Programming Language, (Stroustrup, 4ed, 2013)".
In section 10.3.2 of the book, it says:
The order of evaluation of subexpressions within an expression is undefined. In particular, you cannot assume that the expression is evaluated left-to-right. For example:
int x = f(2)+g(3); // undefined whether f() or g() is called first
This seems to apply to all operators including && operator, but in a following paragraph it says:
The operators , (comma), && (logical and), and || (logical or) guarantee that their left-hand operand is evaluated before their right-hand operand.
There is also another mention of this in section 11.1.1:
The && and || operators evaluate their second argument only if necessary, so they can be used to control evaluation order (§10.3.2). For example:
while (p && !whitespace(p)) ++p;
Here, p is not dereferenced if it is the nullptr.
This last quote implies that && and || evaluate their 1st argument first, so it seems to reinforce my assumption that operators mentioned in 2nd quote are exceptions to 1st quote, but I cannot draw a definitive conclusion from this last example either, as the expression contains only one subexpression as opposed to my example, which contains two.
The special sequencing behavior of &&, ||, and , is well-established in C and C++. The first sentence you quoted should say "The order of evaluation of subexpressions within an expression is generally unspecified" or "With a few specific exceptions, the order of evaluation of subexpressions within an expression is unspecified".
You asked about C++, but this question in the C FAQ list is pertinent.
Addendum: I just realized that "unspecified" is a better word in these rules than "undefined". Writing something like f() + g() doesn't give you undefined behavior. You just have no way of knowing whether f or g might be called first.
Yes, it is guaranteed that f(0) will be completely evaluated first.
This is to support behaviour known as short-circuiting, by which we don't need to call the second function at all if the first returns false.
In the expression a + b, is a guaranteed to be evaluated before b, or is the order of evaluation unspecified? I think it is the latter, but I struggle to find a definite answer in the standard.
Since I don't know whether C handles this different from C++, or if evaluation order rules were simplified in C++11, I'm gonna tag the question as all three.
In C++, for user-defined types a + b is a function call, and the standard says:
§5.2.2.8 - [...] The order of evaluation of function arguments is unspecified. [...]
For normal operators, the standard says:
§5.4 - Except where noted, the order of evaluation of operands of individual operators and subexpressions of individual expressions, and the order in which side effects take place, is unspecified. [...]
These haven't been changed for C++11. However, the wording changes in the second one to say that the order is "unsequenced" rather than unspecified, but it is essentially the same.
I don't have a copy of the C standard, but I imagine that it is the same there as well.
It is Unspecified.
Reference - C++03 Standard:
Section 5: Expressions, Para 4:
except where noted [e.g. special rules for && and ||], the order of evaluation of operands of individual operators and subexpressions of individual expressions, and the order in which side effects take place, is Unspecified.
C++0x FDIS section 1.9 "Program Execution" §15 is similar to the corresponding paragraph in C++03, just reworded to accommodate the conceptual change from "sequence points" to "being sequenced":
Except where noted, evaluations of operands of individual operators and of subexpressions of individual expressions are unsequenced.
It is unspecified. C and C++ follow the same logic in selecting sequence points:
https://en.wikipedia.org/wiki/Sequence_point
For C: "Order of operations is not defined by the language. The compiler is free to evaluate such expressions in any order, if the compiler can guarantee a consistent result." [...] "Only the sequential-evaluation (,), logical-AND (&&), logical-OR (||), conditional-expression (? :), and function-call operators constitute sequence points and therefore guarantee a particular order of evaluation for their operands."
Source: http://msdn.microsoft.com/en-us/library/2bxt6kc4.aspx
The way this is organized in that article, it seems to indicate this applies to C++ too, which is confirmed by the answer to this question: Operator Precedence vs Order of Evaluation.
According to the current C standard, C11, it also specifies that the order of evaluation of subexpressions (a and b in this case) is indeterminate. In fact, this order doesn't even have to be the same if the same expression is evaluated multiple times.
From section 6.5:
The grouping of operators and operands is indicated by the
syntax.85) Except as specified later, side effects and
value computations of subexpressions are unsequenced.86)
86) In an expression that is evaluated more than once during the
execution of a program, unsequenced and indeterminately sequenced
evaluations of its subexpressions need not be performed
consistently in different evaluations.
I was just going though my text book when I came across this question:
What would be the value of a after the following expression? Assume the initial value of a = 5. Mention the steps.
a+=(a++)+(++a)
At first I thought this is undefined behaviour because a has been modified more than once. Then I read the question and it said "Mention the steps" so I probably thought this question is right.
Does applying parentheses make an undefined behaviour defined?
Is a sequence point created after evaluating a parentheses expression?
If it is defined,how do the parentheses matter since ++ and () have the same precedence?
No, applying parentheses doesn't make it a defined behaviour. It's still undefined. The C99 standard §6.5 ¶2 says
Between the previous and next sequence point an object shall have its
stored value modified at most once by the evaluation of an expression.
Furthermore, the prior value shall be read only to determine the value
to be stored.
Putting a sub-expression in parentheses may force the order of evaluation of sub-expressions but it does not create a sequence point. Therefore, it does not guarantee when the side effects of the sub-expressions, if they produce any, will take place. Quoting the C99 standard again §5.1.2.3¶2
Evaluation of an expression may produce side effects. At certain
specified points in the execution sequence called sequence points, all
side effects of previous evaluations shall be complete and no side
effects of subsequent evaluations shall have taken place.
For the sake of completeness, following are sequence points laid down by the C99 standard in Annex C.
The call to a function, after the arguments have been evaluated.
The end of the first operand of the following operators: logical AND &&; logical OR ||; conditional ?; comma ,.
The end of a full declarator.
The end of a full expression; the expression in an expression statement; the controlling expression of a selection statement (if
or switch); the controlling expression of a while or do
statement; each of the expressions of a for statement; the
expression in a return statement.
Immediately before a library function returns.
After the actions associated with each formatted input/output function conversion specifier.
Immediately before and immediately after each call to a comparison function, and also between any call to a comparison function and any
movement of the objects passed as arguments to that call.
Adding parenthesis does not create a sequence point and in the more modern standards it does not create a sequenced before relationship with respect to side effects which is the problem with the expression that you have unless noted the rest of this will be with respect to C++11. Parenthesis are a primary expression covered in section 5.1 Primary expressions, which has the following grammar (emphasis mine going forward):
primary-expression:
literal
this
( expression )
[...]
and in paragraph 6 it says:
A parenthesized expression is a primary expression whose type and value are identical to those of the enclosed expression. The presence of parentheses does not affect whether the expression is an lvalue. The parenthesized expression can be used in exactly the same contexts as those where the enclosed expression can be used, and with the same meaning, except as otherwise indicated.
The postfix ++ is problematic since we can not determine when the side effect of updating a will happen pre C++11 and in C this applies to both the postfix ++ and prefix ++ operations. With respect to how undefined behavior changed for prefix ++ in C++11 see Assignment operator sequencing in C11 expressions.
The += operation is problematic since:
[...]E1 op = E2 is equivalent to E1 = E1 op E2 except that E1 is
evaluated only once[...]
So in C++11 the following went from undefined to defined:
a = ++a + 1 ;
but this remains undefined:
a = a++ + 1 ;
and both of the above are undefined pre C++11 and in both C99 and C11.
From the draft C++11 standard section 1.9 Program execution paragraph 15 says:
Except where noted, evaluations of operands of individual operators and of subexpressions of individual expressions are unsequenced. [ Note: In an expression that is evaluated more than once during the execution of a program, unsequenced and indeterminately sequenced evaluations of its subexpressions need not be performed consistently in different evaluations. —end note ] The value computations of the operands of an operator are sequenced before the value computation of the result of the operator. If a side effect on a scalar object is unsequenced relative to either another side effect on the same scalar object or a value computation using the value of the same scalar object, the behavior is undefined.