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

Files changed (1) hide show

tmp/tmpztxdimn3/{from.md → to.md} +189 -89

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

@@ -4,17 +4,17 @@ 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.[^5]
 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.[^6] 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,
@@ -25,56 +25,56 @@ 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). This International Standard imposes no requirements on the
-behavior of programs that contain undefined behavior.
 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).
-If a signal handler is executed as a result of a call to the `raise`
-function, then the execution of the handler is sequenced after the
-invocation of the `raise` function and before its return. 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.
 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:
-- Access to volatile objects 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. More stringent correspondences between abstract and actual
-semantics may be defined by each implementation.
 Operators can be regrouped according to the usual mathematical rules
-only where the operators really are associative or commutative.[^7] For
 example, in the following fragment
 ``` cpp
 int a, b;
-/*...*/
 a = a + 32760 + b + 5;
 ```
 the expression statement behaves exactly the same as
@@ -111,119 +111,219 @@ 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.
-A *full-expression* is an expression that is not a subexpression of
-another expression. in some contexts, such as unevaluated operands, a
-syntactic subexpression is considered a full-expression (Clause
-[[expr]]). 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 expression for the purposes of this definition. A call to a
-destructor generated at the end of the lifetime of an object other than
-a temporary object is an implicit full-expression. Conversions applied
-to the result of an expression in order to satisfy the requirements of
-the language construct in which the expression appears are also
-considered to be part of the full-expression.
 ``` cpp
 struct S {
-  S(int i): I(i) { }
   int& v() { return I; }
 private:
   int I;
 };
 S s1(1);                   // full-expression is call of S::S(int)
- S s2 = 2;          // full-expression is call of S::S(int)
 void f() {
   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
   { }
 }
 ```
-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.
-Accessing 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 sub-expression) 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. When a
-call to a library I/O function returns or an access to a `volatile`
-object 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*, 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*. The execution of unsequenced
-evaluations can overlap. 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. Indeterminately sequenced
-evaluations cannot overlap, but either could be executed first.
 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.[^8]
 Except where noted, evaluations of operands of individual operators and
-of subexpressions of individual expressions are unsequenced. 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. 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 ([[intro.multithread]]), the behavior is undefined. The next
-section imposes similar, but more complex restrictions on potentially
-concurrent computations.
 ``` cpp
-void f(int, int);
-void g(int i, int* v) {
-  i = v[i++];         // the behavior is undefined
   i = 7, i++, i++;    // i becomes 9
-  i = i++ + 1;        // the behavior is undefined
   i = i + 1;          // the value of i is incremented
-  f(i = -1, i = -1);  // 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. Value computations and side effects
-associated with different argument expressions are unsequenced. 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.[^9] Several contexts in
-C++cause evaluation of a function call, even though no corresponding
-function call syntax appears in the translation unit. 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. 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.

 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,
 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
 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
+  parenthesized) *expression-list* are the constituent expressions of
+  the elements of the respective list.
+- The constituent expressions of a *brace-or-equal-initializer* of the
+  form `=` *initializer-clause* are the constituent expressions of the
+  *initializer-clause*.
+[*Example 1*:
+``` cpp
+struct A { int x; };
+struct B { int y; struct A a; };
+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
+expression for the purposes of this definition. Conversions applied to
+the result of an expression in order to satisfy the requirements of the
+language construct in which the expression appears are also considered
+to be part of the full-expression. For an initializer, performing the
+initialization of the entity (including evaluating default member
+initializers of an aggregate) is also considered part of the
+full-expression.
+[*Example 2*:
 ``` cpp
 struct S {
+  S(int i): I(i) { }       // full-expression is initialization of I
   int& v() { return I; }
+  ~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));
+   };
+   B b[2] = { B(), B() };  // full-expression is the entire initialization
+                           // 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
+glvalue evaluation and fetching a value previously assigned to an object
+for prvalue evaluation) and initiation of side effects. When a call to a
+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*]
 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. 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,
+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*]

Diff to HTML by rtfpessoa