Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: minor editorial changes

...

Paragraph 15 further states (nonnormative text removed for brevity) the following:

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. 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, and they are not potentially concurrent, the behavior is undefined. ... 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. ... Every evaluation in the calling function (including other function calls) that is not otherwise specifically sequenced before or after the execution of the body of the called function is indeterminately sequenced with respect to the execution of the called function. Several contexts in C++ cause evaluation of a function call, even though no corresponding function call syntax appears in the translation unit. ... The sequencing constraints on the execution of the called function (as described above) are features of the function calls as evaluated, whatever the syntax of the expression that calls the function might be.

...

  • In postfix ++ and -- expressions, the value computation is sequenced before the modification of the operand. ([expr.post.incr], paragraph 1)
  • In logical && expressions, if the second expression is evaluated, every value computation and side effect associated with the first expression is sequenced before every value computation and side effect associated with the second expression. ([expr.log.and], paragraph 2)
  • In logical || expressions, if the second expression is evaluated, every value computation and side effect associated with the first expression is sequenced before every value computation and side effect associated with the second expression. ([expr.log.or], paragraph 2)
  • In conditional ?: expressions, every value computation and side effect associated with the first expression is sequenced before every value computation and side effect associated with the second or third expression (whichever is evaluated). ([expr.cond], paragraph 1)
  • In assignment expressions (including compound assignments), the assignment is sequenced after the value computations of left and right operands , and before the value computation of the assignment expression. ([expr.ass], paragraph 1)
  • In comma , expressions, every value computation and side effect associated with the left expression is sequenced before every value computation and side effect associated with the right expression. ([expr.comma], paragraph 1)
  • When evaluating initializer lists, the value computation and side effect associated with each initializer-clause is sequenced before every value computation and side effect associated with a subsequent initializer-clause. ([dcl.init.list], paragraph 4)
  • When a signal handler is executed as a result of a call to std::raise(), the execution of the handler is sequenced after the invocation of std::raise() and before its return. ([intro.execution], paragraph 6)
  • The completions of the destructors for all initialized objects with thread storage duration within a thread are sequenced before the initiation of the destructors of any object with static storage duration. ([basic.start.term], paragraph 1)
  • In a new-expression, initialization of an allocated object is sequenced before the value computation of the new-expression. ([expr.new], paragraph 18)
  • When a default constructor is called to initialize an element of an array and the constructor has at least one default argument, the destruction of every temporary created in a default argument is sequenced before the construction of the next array element, if any. ([class.temporary], paragraph 4)
  • The destruction of a temporary whose lifetime is not extended by being bound to a reference is sequenced before the destruction of every temporary which that is constructed earlier in the same full-expression. ([class.temporary], paragraph 5)
  • Atomic memory ordering functions can explicitly determine the sequencing order for expressions. ([atomics.order] and [atomics.fences])

...

have defined behavior, and statements such as the following do not:.

Code Block
bgColor#FFcccc
langcpp
// i is modified twice in the same full expression
i = ++i + 1;  

// i is read other than to determine the value to be stored
a[i++] = i;   

Not all instances of a comma in C++ code denote a usage use of the comma operator. For example, the comma between arguments in a function call is not the comma operator. Additionally, overloaded operators behave the same as a function call, with the operands to the operator acting as arguments to a function call.

...

In this noncompliant code example, i is evaluated more than once in an unsequenced manner, and so the behavior of the expression is undefined:.

Code Block
bgColor#FFcccc
langcpp
void f(int i, const int *b) {
  int a = i + b[++i];
  // ...
}

...

These examples are independent of the order of evaluation of the operands and can be interpreted in only one way:.

Code Block
bgColor#ccccff
langcpp
void f(int i, const int *b) {
  ++i;
  int a = i + b[i];
  // ...
}

Alternatively:

Code Block
bgColor#ccccff
langcpp
void f(int i, const int *b) {
  int a = i + b[i + 1];
  ++i;
  // ...
}

...

The call to func() in this noncompliant code example has undefined behavior because the argument expressions are unsequenced:.

Code Block
bgColor#FFcccc
langcpp
extern void func(int i, int j);
 
void f(int i) {
  func(i++, i);
}

...

This compliant solution is appropriate when the programmer intends for both arguments to func() to be equivalent:.

Code Block
bgColor#ccccff
langcpp
extern void func(int i, int j);
 
void f(int i) {
  i++;
  func(i, i);
}

This compliant solution is appropriate when the programmer intends for the second argument to be 1 greater than the first:.

Code Block
bgColor#ccccff
langcpp
extern void func(int i, int j);
 
void f(int i) {
  int j = i++;
  func(j, i);
}

...

The order of evaluation for function arguments is unspecified. This noncompliant code example exhibits unspecified behavior but not undefined behavior:.

Code Block
bgColor#FFcccc
langcpp
extern void c(int i, int j);
int glob;
 
int a() {
  return glob + 10;
}

int b() {
  glob = 42;
  return glob;
}
 
void f() {
  c(a(), b());
}

...

In this compliant solution, the order of evaluation for a() and b() is fixed, and so no unspecified behavior occurs:.

Code Block
bgColor#ccccff
langcpp
extern void c(int i, int j);
int glob;
 
int a() {
  return glob + 10;
}
 
int b() {
  glob = 42;
  return glob;
}
 
void f() {
  int a_val, b_val;
 
  a_val = a();
  b_val = b();

  c(a_val, b_val);
}

...