[intro] - C++11 → C++14

Files changed (1) hide show

tmp/tmp4f5hamz0/{from.md → to.md} +84 -58

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

@@ -67,32 +67,24 @@ Terms that are used only in a small portion of this International
 Standard are defined where they are used and italicized where they are
 defined.
 #### 1 argument <a id="defns.argument">[[defns.argument]]</a>
-actual argument
-actual parameter
 \<function call expression\> expression in the comma-separated list
 bounded by the parentheses
 #### 2 argument <a id="defns.argument.macro">[[defns.argument.macro]]</a>
-actual argument
-actual parameter
 \<function-like macro\> sequence of preprocessing tokens in the
 comma-separated list bounded by the parentheses
 #### 3 argument <a id="defns.argument.throw">[[defns.argument.throw]]</a>
-actual argument
-actual parameter
 \<throw expression\> the operand of `throw`
 #### 4 argument <a id="defns.argument.templ">[[defns.argument.templ]]</a>
-actual argument
-actual parameter
 \<template instantiation\> expression, *type-id* or *template-name* in
 the comma-separated list bounded by the angle brackets
 #### 5 conditionally-supported <a id="defns.cond.supp">[[defns.cond.supp]]</a>
@@ -143,28 +135,22 @@ character set of either the source or the execution environment
 The extended character set is a superset of the basic character set (
 [[lex.charset]]).
 #### 14 parameter <a id="defns.parameter">[[defns.parameter]]</a>
-formal argument
-formal parameter
 \<function or catch clause\> object or reference declared as part of a
 function declaration or definition or in the catch clause of an
 exception handler that acquires a value on entry to the function or
 handler
 #### 15 parameter <a id="defns.parameter.macro">[[defns.parameter.macro]]</a>
-formal argument
-formal parameter
 \<function-like macro\> identifier from the comma-separated list bounded
 by the parentheses immediately following the macro name
 #### 16 parameter <a id="defns.parameter.templ">[[defns.parameter.templ]]</a>
-formal argument
-formal parameter
 \<template\> *template-parameter*
 #### 17 signature <a id="defns.signature">[[defns.signature]]</a>
 \<function\> name, parameter type list ([[dcl.fct]]), and enclosing
@@ -479,11 +465,12 @@ 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,
-order of evaluation of arguments to a function). 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.
@@ -498,19 +485,15 @@ 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).
-When the processing of the abstract machine is interrupted by receipt of
-a signal, the values of objects which are neither
-- of type `volatile std::sig_atomic_t` nor
-- lock-free atomic objects ([[atomics.lockfree]])
-are unspecified during the execution of the signal handler, and the
-value of any object not in either of these two categories that is
-modified by the handler becomes undefined.
 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
@@ -578,18 +561,20 @@ 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. 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; }
@@ -640,22 +625,25 @@ 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, the behavior is undefined.
 ``` cpp
 void f(int, int);
 void g(int i, int* v) {
   i = v[i++];         // the behavior is undefined
@@ -705,16 +693,41 @@ execution can be viewed as an interleaving of all its threads. However,
 some kinds of atomic operations, for example, allow executions
 inconsistent with a simple interleaving, as described below. Under a
 freestanding implementation, it is *implementation-defined* whether a
 program can have more than one thread of execution.
 Implementations should ensure that all unblocked threads eventually make
 progress. Standard library functions may silently block on I/O or locks.
 Factors in the execution environment, including externally-imposed
 thread priorities, may prevent an implementation from making certain
 guarantees of forward progress.
 The value of an object visible to a thread *T* at a particular point is
 the initial value of the object, a value assigned to the object by *T*,
 or a value assigned to the object by another thread, according to the
 rules below. In some cases, there may instead be undefined behavior.
 Much of this section is motivated by the desire to support atomic
@@ -864,19 +877,15 @@ or undefined. This states that operations on ordinary objects are not
 visibly reordered. This is not actually detectable without data races,
 but it is necessary to ensure that data races, as defined below, and
 with suitable restrictions on the use of atomics, correspond to data
 races in a simple interleaved (sequentially consistent) execution.
-The *visible sequence of side effects* on an atomic object *M*, with
-respect to a value computation *B* of *M*, is a maximal contiguous
-sub-sequence of side effects in the modification order of *M*, where the
-first side effect is visible with respect to *B*, and for every side
-effect, it is not the case that *B* happens before it. The value of an
-atomic object *M*, as determined by evaluation *B*, shall be the value
-stored by some operation in the visible sequence of *M* with respect to
-*B*. It can be shown that the visible sequence of side effects of a
-value computation is unique given the coherence requirements below.
 If an operation *A* that modifies an atomic object *M* happens before an
 operation *B* that modifies *M*, then *A* shall be earlier than *B* in
 the modification order of *M*. This requirement is known as write-write
 coherence.
@@ -887,13 +896,13 @@ value computation *B* of *M*, and *A* takes its value from a side effect
 stored by *X* or the value stored by a side effect *Y* on *M*, where *Y*
 follows *X* in the modification order of *M*. This requirement is known
 as read-read coherence.
 If a value computation *A* of an atomic object *M* happens before an
-operation *B* on *M*, then *A* shall take its value from a side effect
-*X* on *M*, where *X* precedes *B* in the modification order of *M*.
-This requirement is known as read-write coherence.
 If a side effect *X* on an atomic object *M* happens before a value
 computation *B* of *M*, then the evaluation *B* shall take its value
 from *X* or from a side effect *Y* that follows *X* in the modification
 order of *M*. This requirement is known as write-read coherence.
@@ -901,22 +910,29 @@ order of *M*. This requirement is known as write-read coherence.
 The four preceding coherence requirements effectively disallow compiler
 reordering of atomic operations to a single object, even if both
 operations are relaxed loads. This effectively makes the cache coherence
 guarantee provided by most hardware available to C++atomic operations.
-The visible sequence of side effects depends on the “happens before”
-relation, which depends on the values observed by loads of atomics,
-which we are restricting here. The intended reading is that there must
-exist an association of atomic loads with modifications they observe
-that, together with suitably chosen modification orders and the “happens
-before” relation derived as described above, satisfy the resulting
-constraints as imposed here.
 The execution of a program contains a *data race* if it contains two
-conflicting actions in different threads, at least one of which is not
-atomic, and neither happens before the other. Any such data race results
-in undefined behavior. It can be shown that programs that correctly use
 mutexes and `memory_order_seq_cst` operations to prevent all data races
 and use no other synchronization operations behave as if the operations
 executed by their constituent threads were simply interleaved, with each
 value computation of an object being taken from the last side effect on
 that object in that interleaving. This is normally referred to as
@@ -925,20 +941,29 @@ programs, and data-race-free programs cannot observe most program
 transformations that do not change single-threaded program semantics. In
 fact, most single-threaded program transformations continue to be
 allowed, since any program that behaves differently as a result must
 perform an undefined operation.
 Compiler transformations that introduce assignments to a potentially
 shared memory location that would not be modified by the abstract
 machine are generally precluded by this standard, since such an
 assignment might overwrite another assignment by a different thread in
 cases in which an abstract machine execution would not have encountered
 a data race. This includes implementations of data member assignment
 that overwrite adjacent members in separate memory locations. Reordering
 of atomic loads in cases in which the atomics in question may alias is
-also generally precluded, since this may violate the “visible sequence”
-rules.
 Transformations that introduce a speculative read of a potentially
 shared memory location may not preserve the semantics of the C++program
 as defined in this standard, since they potentially introduce a data
 race. However, they are typically valid in the context of an optimizing
@@ -982,10 +1007,11 @@ Electronic Engineers, Inc.
 All rights in these originals are reserved.
 <!-- Link reference definitions -->
 [atomics]: atomics.md#atomics
 [atomics.lockfree]: atomics.md#atomics.lockfree
 [atomics.order]: atomics.md#atomics.order
 [basic]: basic.md#basic
 [basic.compound]: basic.md#basic.compound
 [basic.def]: basic.md#basic.def

 Standard are defined where they are used and italicized where they are
 defined.
 #### 1 argument <a id="defns.argument">[[defns.argument]]</a>
 \<function call expression\> expression in the comma-separated list
 bounded by the parentheses
 #### 2 argument <a id="defns.argument.macro">[[defns.argument.macro]]</a>
 \<function-like macro\> sequence of preprocessing tokens in the
 comma-separated list bounded by the parentheses
 #### 3 argument <a id="defns.argument.throw">[[defns.argument.throw]]</a>
 \<throw expression\> the operand of `throw`
 #### 4 argument <a id="defns.argument.templ">[[defns.argument.templ]]</a>
 \<template instantiation\> expression, *type-id* or *template-name* in
 the comma-separated list bounded by the angle brackets
 #### 5 conditionally-supported <a id="defns.cond.supp">[[defns.cond.supp]]</a>
 The extended character set is a superset of the basic character set (
 [[lex.charset]]).
 #### 14 parameter <a id="defns.parameter">[[defns.parameter]]</a>
 \<function or catch clause\> object or reference declared as part of a
 function declaration or definition or in the catch clause of an
 exception handler that acquires a value on entry to the function or
 handler
 #### 15 parameter <a id="defns.parameter.macro">[[defns.parameter.macro]]</a>
 \<function-like macro\> identifier from the comma-separated list bounded
 by the parentheses immediately following the macro name
 #### 16 parameter <a id="defns.parameter.templ">[[defns.parameter.templ]]</a>
 \<template\> *template-parameter*
 #### 17 signature <a id="defns.signature">[[defns.signature]]</a>
 \<function\> name, parameter type list ([[dcl.fct]]), and enclosing
 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.
 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
 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; }
 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
 some kinds of atomic operations, for example, allow executions
 inconsistent with a simple interleaving, as described below. Under a
 freestanding implementation, it is *implementation-defined* whether a
 program can have more than one thread of execution.
+A signal handler that is executed as a result of a call to the `raise`
+function belongs to the same thread of execution as the call to the
+`raise` function. Otherwise it is unspecified which thread of execution
+contains a signal handler invocation.
 Implementations should ensure that all unblocked threads eventually make
 progress. Standard library functions may silently block on I/O or locks.
 Factors in the execution environment, including externally-imposed
 thread priorities, may prevent an implementation from making certain
 guarantees of forward progress.
+Executions of atomic functions that are either defined to be lock-free (
+[[atomics.flag]]) or indicated as lock-free ([[atomics.lockfree]]) are
+*lock-free executions*.
+- If there is only one unblocked thread, a lock-free execution in that
+  thread shall complete. Concurrently executing threads may prevent
+  progress of a lock-free execution. For example, this situation can
+  occur with load-locked store-conditional implementations. This
+  property is sometimes termed obstruction-free.
+- When one or more lock-free executions run concurrently, at least one
+  should complete. It is difficult for some implementations to provide
+  absolute guarantees to this effect, since repeated and particularly
+  inopportune interference from other threads may prevent forward
+  progress, e.g., by repeatedly stealing a cache line for unrelated
+  purposes between load-locked and store-conditional instructions.
+  Implementations should ensure that such effects cannot indefinitely
+  delay progress under expected operating conditions, and that such
+  anomalies can therefore safely be ignored by programmers. Outside this
+  International Standard, this property is sometimes termed lock-free.
 The value of an object visible to a thread *T* at a particular point is
 the initial value of the object, a value assigned to the object by *T*,
 or a value assigned to the object by another thread, according to the
 rules below. In some cases, there may instead be undefined behavior.
 Much of this section is motivated by the desire to support atomic
 visibly reordered. This is not actually detectable without data races,
 but it is necessary to ensure that data races, as defined below, and
 with suitable restrictions on the use of atomics, correspond to data
 races in a simple interleaved (sequentially consistent) execution.
+The value of an atomic object *M*, as determined by evaluation *B*,
+shall be the value stored by some side effect *A* that modifies *M*,
+where *B* does not happen before *A*. The set of such side effects is
+also restricted by the rest of the rules described here, and in
+particular, by the coherence requirements below.
 If an operation *A* that modifies an atomic object *M* happens before an
 operation *B* that modifies *M*, then *A* shall be earlier than *B* in
 the modification order of *M*. This requirement is known as write-write
 coherence.
 stored by *X* or the value stored by a side effect *Y* on *M*, where *Y*
 follows *X* in the modification order of *M*. This requirement is known
 as read-read coherence.
 If a value computation *A* of an atomic object *M* happens before an
+operation *B* that modifies *M*, then *A* shall take its value from a
+side effect *X* on *M*, where *X* precedes *B* in the modification order
+of *M*. This requirement is known as read-write coherence.
 If a side effect *X* on an atomic object *M* happens before a value
 computation *B* of *M*, then the evaluation *B* shall take its value
 from *X* or from a side effect *Y* that follows *X* in the modification
 order of *M*. This requirement is known as write-read coherence.
 The four preceding coherence requirements effectively disallow compiler
 reordering of atomic operations to a single object, even if both
 operations are relaxed loads. This effectively makes the cache coherence
 guarantee provided by most hardware available to C++atomic operations.
+The value observed by a load of an atomic depends on the “happens
+before” relation, which depends on the values observed by loads of
+atomics. The intended reading is that there must exist an association of
+atomic loads with modifications they observe that, together with
+suitably chosen modification orders and the “happens before” relation
+derived as described above, satisfy the resulting constraints as imposed
+here.
+Two actions are *potentially concurrent* if
+- they are performed by different threads, or
+- they are unsequenced, and at least one is performed by a signal
+  handler.
 The execution of a program contains a *data race* if it contains two
+potentially concurrent conflicting actions, at least one of which is not
+atomic, and neither happens before the other, except for the special
+case for signal handlers described below. Any such data race results in
+undefined behavior. It can be shown that programs that correctly use
 mutexes and `memory_order_seq_cst` operations to prevent all data races
 and use no other synchronization operations behave as if the operations
 executed by their constituent threads were simply interleaved, with each
 value computation of an object being taken from the last side effect on
 that object in that interleaving. This is normally referred to as
 transformations that do not change single-threaded program semantics. In
 fact, most single-threaded program transformations continue to be
 allowed, since any program that behaves differently as a result must
 perform an undefined operation.
+Two accesses to the same object of type `volatile sig_atomic_t` do not
+result in a data race if both occur in the same thread, even if one or
+more occurs in a signal handler. For each signal handler invocation,
+evaluations performed by the thread invoking a signal handler can be
+divided into two groups *A* and *B*, such that no evaluations in *B*
+happen before evaluations in *A*, and the evaluations of such
+`volatile sig_atomic_t` objects take values as though all evaluations in
+*A* happened before the execution of the signal handler and the
+execution of the signal handler happened before all evaluations in *B*.
 Compiler transformations that introduce assignments to a potentially
 shared memory location that would not be modified by the abstract
 machine are generally precluded by this standard, since such an
 assignment might overwrite another assignment by a different thread in
 cases in which an abstract machine execution would not have encountered
 a data race. This includes implementations of data member assignment
 that overwrite adjacent members in separate memory locations. Reordering
 of atomic loads in cases in which the atomics in question may alias is
+also generally precluded, since this may violate the coherence rules.
 Transformations that introduce a speculative read of a potentially
 shared memory location may not preserve the semantics of the C++program
 as defined in this standard, since they potentially introduce a data
 race. However, they are typically valid in the context of an optimizing
 All rights in these originals are reserved.
 <!-- Link reference definitions -->
 [atomics]: atomics.md#atomics
+[atomics.flag]: atomics.md#atomics.flag
 [atomics.lockfree]: atomics.md#atomics.lockfree
 [atomics.order]: atomics.md#atomics.order
 [basic]: basic.md#basic
 [basic.compound]: basic.md#basic.compound
 [basic.def]: basic.md#basic.def

Diff to HTML by rtfpessoa