[intro.execution] - C++17 → C++20

Files changed (1) hide show

tmp/tmpwlpyxb6l/{from.md → to.md} +56 -165

tmp/tmpwlpyxb6l/{from.md → to.md} RENAMED Viewed

@@ -1,121 +1,12 @@
-## Program execution <a id="intro.execution">[[intro.execution]]</a>
-The semantic descriptions in this International Standard define a
-parameterized nondeterministic abstract machine. This International
-Standard places no requirement on the structure of conforming
-implementations. In particular, they need not copy or emulate the
-structure of the abstract machine. Rather, conforming implementations
-are required to emulate (only) the observable behavior of the abstract
-machine as explained below.[^6]
-Certain aspects and operations of the abstract machine are described in
-this International Standard as implementation-defined (for example,
-`sizeof(int)`). These constitute the parameters of the abstract machine.
-Each implementation shall include documentation describing its
-characteristics and behavior in these respects.[^7] Such documentation
-shall define the instance of the abstract machine that corresponds to
-that implementation (referred to as the “corresponding instance” below).
-Certain other aspects and operations of the abstract machine are
-described in this International Standard as unspecified (for example,
-evaluation of expressions in a *new-initializer* if the allocation
-function fails to allocate memory ([[expr.new]])). Where possible, this
-International Standard defines a set of allowable behaviors. These
-define the nondeterministic aspects of the abstract machine. An instance
-of the abstract machine can thus have more than one possible execution
-for a given program and a given input.
-Certain other operations are described in this International Standard as
-undefined (for example, the effect of attempting to modify a `const`
-object).
-[*Note 1*: This International Standard imposes no requirements on the
-behavior of programs that contain undefined behavior. — *end note*]
-A conforming implementation executing a well-formed program shall
-produce the same observable behavior as one of the possible executions
-of the corresponding instance of the abstract machine with the same
-program and the same input. However, if any such execution contains an
-undefined operation, this International Standard places no requirement
-on the implementation executing that program with that input (not even
-with regard to operations preceding the first undefined operation).
-An instance of each object with automatic storage duration (
-[[basic.stc.auto]]) is associated with each entry into its block. Such
-an object exists and retains its last-stored value during the execution
-of the block and while the block is suspended (by a call of a function
-or receipt of a signal).
-The least requirements on a conforming implementation are:
-- Accesses through volatile glvalues are evaluated strictly according to
-  the rules of the abstract machine.
-- At program termination, all data written into files shall be identical
-  to one of the possible results that execution of the program according
-  to the abstract semantics would have produced.
-- The input and output dynamics of interactive devices shall take place
-  in such a fashion that prompting output is actually delivered before a
-  program waits for input. What constitutes an interactive device is
-  *implementation-defined*.
-These collectively are referred to as the *observable behavior* of the
-program.
-[*Note 2*: More stringent correspondences between abstract and actual
-semantics may be defined by each implementation. — *end note*]
-[*Note 3*:
-Operators can be regrouped according to the usual mathematical rules
-only where the operators really are associative or commutative.[^8] For
-example, in the following fragment
-``` cpp
-int a, b;
-...
-a = a + 32760 + b + 5;
-```
-the expression statement behaves exactly the same as
-``` cpp
-a = (((a + 32760) + b) + 5);
-```
-due to the associativity and precedence of these operators. Thus, the
-result of the sum `(a + 32760)` is next added to `b`, and that result is
-then added to 5 which results in the value assigned to `a`. On a machine
-in which overflows produce an exception and in which the range of values
-representable by an `int` is \[`-32768`, `+32767`\], the implementation
-cannot rewrite this expression as
-``` cpp
-a = ((a + b) + 32765);
-```
-since if the values for `a` and `b` were, respectively, -32754 and -15,
-the sum `a + b` would produce an exception while the original expression
-would not; nor can the expression be rewritten either as
-``` cpp
-a = ((a + 32765) + b);
-```
-or
-``` cpp
-a = (a + (b + 32765));
-```
-since the values for `a` and `b` might have been, respectively, 4 and -8
-or -17 and 12. However on a machine in which overflows do not produce an
-exception and in which the results of overflows are reversible, the
-above expression statement can be rewritten by the implementation in any
-of the above ways because the same result will occur.
-— *end note*]
 A *constituent expression* is defined as follows:
 - The constituent expression of an expression is that expression.
 - The constituent expressions of a *braced-init-list* or of a (possibly
@@ -136,40 +27,42 @@ B b = { 5, { 1+1 } };
 The constituent expressions of the *initializer* used for the
 initialization of `b` are `5` and `1+1`.
 — *end example*]
-The *immediate subexpressions* of an expression `e` are
-- the constituent expressions of `e`’s operands (Clause [[expr]]),
-- any function call that `e` implicitly invokes,
-- if `e` is a *lambda-expression* ([[expr.prim.lambda]]), the
- initialization of the entities captured by copy and the constituent
- expressions of the *initializer* of the *init-capture*s,
-- if `e` is a function call ([[expr.call]]) or implicitly invokes a
-  function, the constituent expressions of each default argument (
-  [[dcl.fct.default]]) used in the call, or
-- if `e` creates an aggregate object ([[dcl.init.aggr]]), the
- constituent expressions of each default member initializer (
- [[class.mem]]) used in the initialization.
-A *subexpression* of an expression `e` is an immediate subexpression of
-`e` or a subexpression of an immediate subexpression of `e`.
-[*Note 4*: Expressions appearing in the *compound-statement* of a
 *lambda-expression* are not subexpressions of the
 *lambda-expression*. — *end note*]
 A *full-expression* is
-- an unevaluated operand (Clause [[expr]]),
-- a *constant-expression* ([[expr.const]]),
-- an *init-declarator* (Clause [[dcl.decl]]) or a *mem-initializer* (
- [[class.base.init]]), including the constituent expressions of the
   initializer,
 - an invocation of a destructor generated at the end of the lifetime of
-  an object other than a temporary object ([[class.temporary]]), or
 - an expression that is not a subexpression of another expression and
   that is not otherwise part of a full-expression.
 If a language construct is defined to produce an implicit call of a
 function, a use of the language construct is considered to be an
@@ -190,19 +83,18 @@ struct S {
   ~S() noexcept(false) { }
 private:
   int I;
 };
-S s1(1); // full-expression is call of S::S(int)
 void f() {
-  S s2 = 2; // full-expression is call of S::S(int)
-  if (S(3).v()) // full-expression includes lvalue-to-rvalue and
- // int to bool conversions, performed before
-                           // temporary is deleted at end of full-expression
   { }
-  bool b = noexcept(S()); // exception specification of destructor of S
-                           // considered for noexcept
   // full-expression is destruction of s2 at end of block
 }
 struct B {
   B(S = S(0));
 };
@@ -210,18 +102,18 @@ struct B {
                                 // including the destruction of temporaries
 ```
 — *end example*]
-[*Note 5*: The evaluation of a full-expression can include the
 evaluation of subexpressions that are not lexically part of the
 full-expression. For example, subexpressions involved in evaluating
-default arguments ([[dcl.fct.default]]) are considered to be created in
 the expression that calls the function, not the expression that defines
 the default argument. — *end note*]
-Reading an object designated by a `volatile` glvalue ([[basic.lval]]),
 modifying an object, calling a library I/O function, or calling a
 function that does any of those operations are all *side effects*, which
 are changes in the state of the execution environment. *Evaluation* of
 an expression (or a subexpression) in general includes both value
 computations (including determining the identity of an object for
@@ -231,64 +123,63 @@ library I/O function returns or an access through a volatile glvalue is
 evaluated the side effect is considered complete, even though some
 external actions implied by the call (such as the I/O itself) or by the
 `volatile` access may not have completed yet.
 *Sequenced before* is an asymmetric, transitive, pair-wise relation
-between evaluations executed by a single thread (
-[[intro.multithread]]), which induces a partial order among those
-evaluations. Given any two evaluations *A* and *B*, if *A* is sequenced
-before *B* (or, equivalently, *B* is *sequenced after* *A*), then the
-execution of *A* shall precede the execution of *B*. If *A* is not
-sequenced before *B* and *B* is not sequenced before *A*, then *A* and
-*B* are *unsequenced*.
-[*Note 6*: The execution of unsequenced evaluations can
 overlap. — *end note*]
 Evaluations *A* and *B* are *indeterminately sequenced* when either *A*
 is sequenced before *B* or *B* is sequenced before *A*, but it is
 unspecified which.
-[*Note 7*: Indeterminately sequenced evaluations cannot overlap, but
 either could be executed first. — *end note*]
 An expression *X* is said to be sequenced before an expression *Y* if
 every value computation and every side effect associated with the
 expression *X* is sequenced before every value computation and every
 side effect associated with the expression *Y*.
 Every value computation and side effect associated with a
 full-expression is sequenced before every value computation and side
-effect associated with the next full-expression to be evaluated.[^9]
 Except where noted, evaluations of operands of individual operators and
 of subexpressions of individual expressions are unsequenced.
-[*Note 8*: 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 ([[intro.memory]]) 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 ([[intro.multithread]]), the
 behavior is undefined.
-[*Note 9*: The next section imposes similar, but more complex
 restrictions on potentially concurrent computations. — *end note*]
 [*Example 3*:
 ``` cpp
 void g(int i) {
   i = 7, i++, i++;              // i becomes 9
   i = i++ + 1;                  // the value of i is incremented
-  i = i++ + i; // the behavior is undefined
   i = i + 1;                    // the value of i is incremented
 }
 ```
 — *end example*]
@@ -299,21 +190,21 @@ 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. For each function invocation *F*,
 for every evaluation *A* that occurs within *F* and every evaluation *B*
 that does not occur within *F* but is evaluated on the same thread and
 as part of the same signal handler (if any), either *A* is sequenced
-before *B* or *B* is sequenced before *A*.[^10]
-[*Note 10*: If *A* and *B* would not otherwise be sequenced then they
 are indeterminately sequenced. — *end note*]
 Several contexts in C++ cause evaluation of a function call, even though
 no corresponding function call syntax appears in the translation unit.
 [*Example 4*: Evaluation of a *new-expression* invokes one or more
 allocation and constructor functions; see  [[expr.new]]. For another
-example, invocation of a conversion function ([[class.conv.fct]]) can
 arise in contexts in which no function call syntax
 appears. — *end example*]
 The sequencing constraints on the execution of the called function (as
 described above) are features of the function calls as evaluated,
@@ -321,9 +212,9 @@ whatever the syntax of the expression that calls the function might be.
 If a signal handler is executed as a result of a call to the
 `std::raise` function, then the execution of the handler is sequenced
 after the invocation of the `std::raise` function and before its return.
-[*Note 11*: When a signal is received for another reason, the execution
 of the signal handler is usually unsequenced with respect to the rest of
 the program. — *end note*]

+### Sequential execution <a id="intro.execution">[[intro.execution]]</a>
+An instance of each object with automatic storage duration
+[[basic.stc.auto]] is associated with each entry into its block. Such an
+object exists and retains its last-stored value during the execution of
+the block and while the block is suspended (by a call of a function,
+suspension of a coroutine [[expr.await]], or receipt of a signal).
 A *constituent expression* is defined as follows:
 - The constituent expression of an expression is that expression.
 - The constituent expressions of a *braced-init-list* or of a (possibly
 The constituent expressions of the *initializer* used for the
 initialization of `b` are `5` and `1+1`.
 — *end example*]
+The *immediate subexpressions* of an expression E are
+- the constituent expressions of E’s operands [[expr.prop]],
+- any function call that E implicitly invokes,
+- if E is a *lambda-expression* [[expr.prim.lambda]], the initialization
+  of the entities captured by copy and the constituent expressions of
+  the *initializer* of the *init-capture*s,
+- if E is a function call [[expr.call]] or implicitly invokes a
+  function, the constituent expressions of each default argument
+  [[dcl.fct.default]] used in the call, or
+- if E creates an aggregate object [[dcl.init.aggr]], the constituent
+  expressions of each default member initializer [[class.mem]] used in
+  the initialization.
+A *subexpression* of an expression E is an immediate subexpression of E
+or a subexpression of an immediate subexpression of E.
+[*Note 1*: Expressions appearing in the *compound-statement* of a
 *lambda-expression* are not subexpressions of the
 *lambda-expression*. — *end note*]
 A *full-expression* is
+- an unevaluated operand [[expr.prop]],
+- a *constant-expression* [[expr.const]],
+- an immediate invocation [[expr.const]],
+- an *init-declarator* [[dcl.decl]] or a *mem-initializer*
+  [[class.base.init]], including the constituent expressions of the
   initializer,
 - an invocation of a destructor generated at the end of the lifetime of
+  an object other than a temporary object [[class.temporary]] whose
+  lifetime has not been extended, or
 - an expression that is not a subexpression of another expression and
   that is not otherwise part of a full-expression.
 If a language construct is defined to produce an implicit call of a
 function, a use of the language construct is considered to be an
   ~S() noexcept(false) { }
 private:
   int I;
 };
+S s1(1); // full-expression comprises call of S::S(int)
 void f() {
+  S s2 = 2; // full-expression comprises call of S::S(int)
+  if (S(3).v()) // full-expression includes lvalue-to-rvalue and int to bool conversions,
+ // performed before temporary is deleted at end of full-expression
   { }
+  bool b = noexcept(S()); // exception specification of destructor of S considered for noexcept
   // full-expression is destruction of s2 at end of block
 }
 struct B {
   B(S = S(0));
 };
                                 // including the destruction of temporaries
 ```
 — *end example*]
+[*Note 2*: The evaluation of a full-expression can include the
 evaluation of subexpressions that are not lexically part of the
 full-expression. For example, subexpressions involved in evaluating
+default arguments [[dcl.fct.default]] are considered to be created in
 the expression that calls the function, not the expression that defines
 the default argument. — *end note*]
+Reading an object designated by a `volatile` glvalue [[basic.lval]],
 modifying an object, calling a library I/O function, or calling a
 function that does any of those operations are all *side effects*, which
 are changes in the state of the execution environment. *Evaluation* of
 an expression (or a subexpression) in general includes both value
 computations (including determining the identity of an object for
 evaluated the side effect is considered complete, even though some
 external actions implied by the call (such as the I/O itself) or by the
 `volatile` access may not have completed yet.
 *Sequenced before* is an asymmetric, transitive, pair-wise relation
+between evaluations executed by a single thread [[intro.multithread]],
+which induces a partial order among those evaluations. Given any two
+evaluations *A* and *B*, if *A* is sequenced before *B* (or,
+equivalently, *B* is *sequenced after* *A*), then the execution of *A*
+shall precede the execution of *B*. If *A* is not sequenced before *B*
+and *B* is not sequenced before *A*, then *A* and *B* are *unsequenced*.
+[*Note 3*: The execution of unsequenced evaluations can
 overlap. — *end note*]
 Evaluations *A* and *B* are *indeterminately sequenced* when either *A*
 is sequenced before *B* or *B* is sequenced before *A*, but it is
 unspecified which.
+[*Note 4*: Indeterminately sequenced evaluations cannot overlap, but
 either could be executed first. — *end note*]
 An expression *X* is said to be sequenced before an expression *Y* if
 every value computation and every side effect associated with the
 expression *X* is sequenced before every value computation and every
 side effect associated with the expression *Y*.
 Every value computation and side effect associated with a
 full-expression is sequenced before every value computation and side
+effect associated with the next full-expression to be evaluated.[^26]
 Except where noted, evaluations of operands of individual operators and
 of subexpressions of individual expressions are unsequenced.
+[*Note 5*: 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 [[intro.memory]] 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 [[intro.multithread]], the
 behavior is undefined.
+[*Note 6*: The next subclause imposes similar, but more complex
 restrictions on potentially concurrent computations. — *end note*]
 [*Example 3*:
 ``` cpp
 void g(int i) {
   i = 7, i++, i++;              // i becomes 9
   i = i++ + 1;                  // the value of i is incremented
+  i = i++ + i; // undefined behavior
   i = i + 1;                    // the value of i is incremented
 }
 ```
 — *end example*]
 function, is sequenced before execution of every expression or statement
 in the body of the called function. For each function invocation *F*,
 for every evaluation *A* that occurs within *F* and every evaluation *B*
 that does not occur within *F* but is evaluated on the same thread and
 as part of the same signal handler (if any), either *A* is sequenced
+before *B* or *B* is sequenced before *A*.[^27]
+[*Note 7*: If *A* and *B* would not otherwise be sequenced then they
 are indeterminately sequenced. — *end note*]
 Several contexts in C++ cause evaluation of a function call, even though
 no corresponding function call syntax appears in the translation unit.
 [*Example 4*: Evaluation of a *new-expression* invokes one or more
 allocation and constructor functions; see  [[expr.new]]. For another
+example, invocation of a conversion function [[class.conv.fct]] can
 arise in contexts in which no function call syntax
 appears. — *end example*]
 The sequencing constraints on the execution of the called function (as
 described above) are features of the function calls as evaluated,
 If a signal handler is executed as a result of a call to the
 `std::raise` function, then the execution of the handler is sequenced
 after the invocation of the `std::raise` function and before its return.
+[*Note 8*: When a signal is received for another reason, the execution
 of the signal handler is usually unsequenced with respect to the rest of
 the program. — *end note*]

Diff to HTML by rtfpessoa