Source: https://timsong-cpp.github.io/cppwp/n3337/intro
List of Tables [tab] List of Figures [fig] 1 General [intro] 1.1 Scope [intro.scope] 1.2 Normative references [intro.refs] 1.3 Terms and definitions [intro.defs] 1.4 Implementation compliance [intro.compliance] 1.5 Structure of this International Standard [intro.structure] 1.6 Syntax notation [syntax] 1.7 The C++ memory model [intro.memory] 1.8 The C++ object model [intro.object] 1.9 Program execution [intro.execution] 1.10 Multi-threaded executions and data races [intro.multithread] 1.11 Acknowledgments [intro.ack] 2 Lexical conventions [lex] 3 Basic concepts [basic] 4 Standard conversions [conv] 5 Expressions [expr] 6 Statements [stmt.stmt] 7 Declarations [dcl.dcl] 8 Declarators [dcl.decl] 9 Classes [class] 10 Derived classes [class.derived] 11 Member access control [class.access] 12 Special member functions [special] 13 Overloading [over] 14 Templates [temp] 15 Exception handling [except] 16 Preprocessing directives [cpp] 17 Library introduction [library] 18 Language support library [language.support] 19 Diagnostics library [diagnostics] 20 General utilities library [utilities] 21 Strings library [strings] 22 Localization library [localization] 23 Containers library [containers] 24 Iterators library [iterators] 25 Algorithms library [algorithms] 26 Numerics library [numerics] 27 Input/output library [input.output] 28 Regular expressions library [re] 29 Atomic operations library [atomics] 30 Thread support library [thread] Annex A (informative) Grammar summary [gram] Annex B (informative) Implementation quantities [implimits] Annex C (informative) Compatibility [diff] Annex D (normative) Compatibility features [depr] Annex E (normative) Universal character names for identifier characters [charname] Index [generalindex] Index of library names [libraryindex] Index of implementation-defined behavior [impldefindex]
Ecma International, ECMAScript Language Specification, Standard Ecma-262, third edition, 1999.
ISO/IEC 2382 (all parts), Information technology — Vocabulary
ISO/IEC 9899:1999, Programming languages — C
ISO/IEC 9899:1999/Cor.1:2001(E), Programming languages — C, Technical Corrigendum 1
ISO/IEC 9899:1999/Cor.2:2004(E), Programming languages — C, Technical Corrigendum 2
ISO/IEC 9899:1999/Cor.3:2007(E), Programming languages — C, Technical Corrigendum 3
ISO/IEC 9945:2003, Information Technology — Portable Operating System Interface (POSIX)
ISO/IEC 10646-1:1993, Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 1: Architecture and Basic Multilingual Plane
ISO/IEC TR 19769:2004, Information technology — Programming languages, their environments and system software interfaces — Extensions for the programming language C to support new character data types
throw
p
B
D
*p
If a program contains no violations of the rules in this International Standard, a conforming implementation shall, within its resource limits, accept and correctly execute[cpp11 2] that program.
If a program contains a violation of any diagnosable rule or an occurrence of a construct described in this Standard as “conditionally-supported” when the implementation does not support that construct, a conforming implementation shall issue at least one diagnostic message.
If a program contains a violation of a rule for which no diagnostic is required, this International Standard places no requirement on implementations with respect to that program.
constant
width
{ expressionopt }
indicates an optional expression enclosed in braces.
X-name is a use of an identifier in a context that determines its meaning (e.g., class-name, typedef-name).
X-id is an identifier with no context-dependent meaning (e.g., qualified-id).
X-seq is one or more X's without intervening delimiters (e.g., declaration-seq is a sequence of declarations).
X-list is one or more X's separated by intervening commas (e.g., expression-list is a sequence of expressions separated by commas).
struct { char a; int b:5, c:11, :0, d:8; struct {int ee:8;} e; }
a
d
e.ee
b
c
x
If x is a complete object, then x is the complete object of x.
Otherwise, the complete object of x is the complete object of the (unique) object that contains x.
static const char test1 = 'x'; static const char test2 = 'x'; const bool b = &test1 != &test2; // always true
sizeof(int)
const
of type volatile std::sig_atomic_t nor
volatile std::sig_atomic_t
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.
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. NoteMore stringent correspondences between abstract and actual semantics may be defined by each implementation.
int a, b; /*...*/ a = a + 32760 + b + 5;
the expression statement behaves exactly the same as
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
(a + 32760)
int
[-32768,+32767]
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
a + b
a = ((a + 32765) + b);
or
a = (a + (b + 32765));
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 { } }
volatile
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 }
new
A
is performed by the same thread that performed A, or
is an atomic read-modify-write operation.
the value of A is used as an operand of B, unless:
B is an invocation of any specialization of std::kill_dependency ([atomics.order]), or
std::kill_dependency
A is the left operand of a built-in logical AND (&&, see [expr.log.and]) or logical OR (||, see [expr.log.or]) operator, or
&&
||
A is the left operand of a conditional (?:, see [expr.cond]) operator, or
?:
A is the left operand of the built-in comma (,) operator ([expr.comma]);
,
A writes a scalar object or bit-field M, B reads the value written by A from M, and A is sequenced before B, or
for some evaluation X, A carries a dependency to X, and X carries a dependency to B.
Note“Carries a dependency to” is a subset of “is sequenced before”, and is similarly strictly intra-thread.
A performs a release operation on an atomic object M, and, in another thread, B performs a consume operation on M and reads a value written by any side effect in the release sequence headed by A, or
for some evaluation X, A is dependency-ordered before X and X carries a dependency to B.
NoteThe relation “is dependency-ordered before” is analogous to “synchronizes with”, but uses release/consume in place of release/acquire.
A synchronizes with B, or
A is dependency-ordered before B, or
for some evaluation X
A synchronizes with X and X is sequenced before B, or
A is sequenced before X and X inter-thread happens before B, or
A inter-thread happens before X and X inter-thread happens before B.
NoteThe “inter-thread happens before” relation describes arbitrary concatenations of “sequenced before”, “synchronizes with” and “dependency-ordered before” relationships, with two exceptions. The first exception is that a concatenation is not permitted to end with “dependency-ordered before” followed by “sequenced before”. The reason for this limitation is that a consume operation participating in a “dependency-ordered before” relationship provides ordering only with respect to operations to which this consume operation actually carries a dependency. The reason that this limitation applies only to the end of such a concatenation is that any subsequent release operation will provide the required ordering for a prior consume operation. The second exception is that a concatenation is not permitted to consist entirely of “sequenced before”. The reasons for this limitation are (1) to permit “inter-thread happens before” to be transitively closed and (2) the “happens before” relation, defined below, provides for relationships consisting entirely of “sequenced before”.
A is sequenced before B, or
A inter-thread happens before B.
The implementation shall ensure that no program execution demonstrates a cycle in the “happens before” relation. NoteThis cycle would otherwise be possible only through the use of consume operations.
A happens before B and
there is no other side effect X to M such that A happens before X and X happens before B.
The value of a non-atomic scalar object or bit-field M, as determined by evaluation B, shall be the value stored by the visible side effect A. NoteIf there is ambiguity about which side effect to a non-atomic object or bit-field is visible, then the behavior is either unspecified or undefined. NoteThis 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.
memory_order_seq_cst
terminate,
make a call to a library I/O function,
access or modify a volatile object, or
perform a synchronization operation or an atomic operation.
NoteThis is intended to allow compiler transformations such as removal of empty loops, even when termination cannot be proven.
Source: https://timsong-cpp.github.io/cppwp/n4140/intro
If a program contains no violations of the rules in this International Standard, a conforming implementation shall, within its resource limits, accept and correctly execute[cpp14 2] that program.
raise
If there is only one unblocked thread, a lock-free execution in that thread shall complete. NoteConcurrently 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. NoteIt 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.
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. NoteIt 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 “sequential consistency”. However, this applies only to data-race-free 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.
volatile sig_atomic_t
Source: https://timsong-cpp.github.io/cppwp/n4659/intro
List of Tables [tab] List of Figures [fig] 1 Scope [intro.scope] 2 Normative references [intro.refs] 3 Terms and definitions [intro.defs] 4 General principles [intro] 4.1 Implementation compliance [intro.compliance] 4.2 Structure of this document [intro.structure] 4.3 Syntax notation [syntax] 4.4 The C++ memory model [intro.memory] 4.5 The C++ object model [intro.object] 4.6 Program execution [intro.execution] 4.7 Multi-threaded executions and data races [intro.multithread] 4.8 Acknowledgments [intro.ack] 5 Lexical conventions [lex] 6 Basic concepts [basic] 7 Standard conversions [conv] 8 Expressions [expr] 9 Statements [stmt.stmt] 10 Declarations [dcl.dcl] 11 Declarators [dcl.decl] 12 Classes [class] 13 Derived classes [class.derived] 14 Member access control [class.access] 15 Special member functions [special] 16 Overloading [over] 17 Templates [temp] 18 Exception handling [except] 19 Preprocessing directives [cpp] 20 Library introduction [library] 21 Language support library [language.support] 22 Diagnostics library [diagnostics] 23 General utilities library [utilities] 24 Strings library [strings] 25 Localization library [localization] 26 Containers library [containers] 27 Iterators library [iterators] 28 Algorithms library [algorithms] 29 Numerics library [numerics] 30 Input/output library [input.output] 31 Regular expressions library [re] 32 Atomic operations library [atomics] 33 Thread support library [thread] Annex A (informative) Grammar summary [gram] Annex B (informative) Implementation quantities [implimits] Annex C (informative) Compatibility [diff] Annex D (normative) Compatibility features [depr] Index [generalindex] Index of library names [libraryindex] Index of implementation-defined behavior [impldefindex]
If a program contains no violations of the rules in this International Standard, a conforming implementation shall, within its resource limits, accept and correctly execute[cpp17 1] that program.
If a program contains a violation of any diagnosable rule or an occurrence of a construct described in this International Standard as “conditionally-supported” when the implementation does not support that construct, a conforming implementation shall issue at least one diagnostic message.
NoteDuring template argument deduction and substitution, certain constructs that in other contexts require a diagnostic are treated differently; see [temp.deduct].
X-list is one or more X's separated by intervening commas (e.g., identifier-list is a sequence of identifiers separated by commas).
the lifetime of e's containing object has begun and not ended, and
the storage for the new object exactly overlays the storage location associated with e, and
the new object is of the same type as e (ignoring cv-qualification).
struct X { const int n; }; union U { X x; float f; }; void tong() { U u = {{ 1 }}; u.f = 5.f; // OK, creates new subobject of u ([class.union]) X *p = new (&u.x) X {2}; // OK, creates new subobject of u assert(p->n == 2); // OK assert(*std::launder(&u.x.n) == 2); // OK assert(u.x.n == 2); // undefined behavior, u.x does not name new subobject }
unsigned char
std::byte
the lifetime of e has begun and not ended, and
the storage for the new object fits entirely within e, and
there is no smaller array object that satisfies these constraints.
template<typename ...T> struct AlignedUnion { alignas(T...) unsigned char data[max(sizeof(T)...)]; }; int f() { AlignedUnion<int, char> au; int *p = new (au.data) int; // OK, au.data provides storage char *c = new (au.data) char(); // OK, ends lifetime of *p char *d = new (au.data + 1) char(); return *c + *d; // OK } struct A { unsigned char a[32]; }; struct B { unsigned char b[16]; }; A a; B *b = new (a.a + 8) B; // a.a provides storage for *b int *p = new (b->b + 4) int; // b->b provides storage for *p // a.a does not provide storage for *p (directly), // but *p is nested within a (see below)
a is a subobject of b, or
b provides storage for a, or
there exists an object c where a is nested within c, and c is nested within b.
If x is a complete object, then the complete object of x is itself.
Accesses through volatile glvalues are evaluated strictly according to the rules of the abstract machine.
int a, b; /* ... */ 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
[-32768, +32767]
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.
=
struct A { int x; }; struct B { int y; struct A a; }; B b = { 5, { 1+1 } };
5
1+1
e
the constituent expressions of e's operands (Clause [expr]),
any function call that e implicitly invokes,
if e is a lambda-expression, the initialization of the entities captured by copy and the constituent expressions of the initializer of the init-captures,
if e is a function call or implicitly invokes a function, the constituent expressions of each default argument used in the call, or
if e creates an aggregate object, the constituent expressions of each default member initializer ([class.mem]) used in the initialization.
an unevaluated operand,
a constant-expression,
an init-declarator or a mem-initializer, 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, or
an expression that is not a subexpression of another expression and that is not otherwise part of a full-expression.
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
glvalue, 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.
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 }
std::raise
B is an invocation of any specialization of std::kill_dependency, or
A is the left operand of the built-in comma (,) operator;
A strongly happens before X and X strongly happens before B.
NoteIn the absence of consume operations, the happens before and strongly happens before relations are identical. Strongly happens before essentially excludes consume operations.
they are unsequenced, at least one is performed by a signal handler, and they are not both performed by the same signal handler invocation.
volatile std::sig_atomic_t
perform an access through a volatile glvalue, or
If there is only one thread that is not blocked in a standard library function, a lock-free execution in that thread shall complete. NoteConcurrently 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. NoteIt 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 document, this property is sometimes termed lock-free.
termination of the thread of execution,
performing an access through a volatile glvalue, or
completion of a call to a library I/O function, a synchronization operation, or an atomic operation.
CHAR_BIT
<climits>
Source: https://timsong-cpp.github.io/cppwp/n4868/intro
1 Scope [intro.scope] 2 Normative references [intro.refs] 3 Terms and definitions [intro.defs] 4 General principles [intro] 4.1 Implementation compliance [intro.compliance] 4.2 Structure of this document [intro.structure] 4.3 Syntax notation [syntax] 5 Lexical conventions [lex] 6 Basics [basic] 7 Expressions [expr] 8 Statements [stmt.stmt] 9 Declarations [dcl.dcl] 10 Modules [module] 11 Classes [class] 12 Overloading [over] 13 Templates [temp] 14 Exception handling [except] 15 Preprocessing directives [cpp] 16 Library introduction [library] 17 Language support library [support] 18 Concepts library [concepts] 19 Diagnostics library [diagnostics] 20 General utilities library [utilities] 21 Strings library [strings] 22 Containers library [containers] 23 Iterators library [iterators] 24 Ranges library [ranges] 25 Algorithms library [algorithms] 26 Numerics library [numerics] 27 Time library [time] 28 Localization library [localization] 29 Input/output library [input.output] 30 Regular expressions library [re] 31 Atomic operations library [atomics] 32 Thread support library [thread] Annex A (informative) Grammar summary [gram] Annex B (normative) Implementation quantities [implimits] Annex C (informative) Compatibility [diff] Annex D (normative) Compatibility features [depr] Index [generalindex] Index of grammar productions [grammarindex] Index of library headers [headerindex] Index of library names [libraryindex] Index of library concepts [conceptindex] Index of implementation-defined behavior [impldefindex]
If a program contains no violations of the rules in [lex] through [thread] and [depr], a conforming implementation shall, within its resource limits as described in [implimits], accept and correctly execute[cpp20 1] that program.
If a program contains a violation of any diagnosable rule or an occurrence of a construct described in this document as “conditionally-supported” when the implementation does not support that construct, a conforming implementation shall issue at least one diagnostic message.
If a program contains a violation of a rule for which no diagnostic is required, this document places no requirement on implementations with respect to that program.
NoteThis document imposes no requirements on the behavior of programs that contain undefined behavior.
These collectively are referred to as the observable behavior of the program. NoteMore stringent correspondences between abstract and actual semantics can be defined by each implementation.
Source: https://timsong-cpp.github.io/cppwp/n4950/intro
1 Scope [intro.scope] 2 Normative references [intro.refs] 3 Terms and definitions [intro.defs] 4 General principles [intro] 4.1 Implementation compliance [intro.compliance] 4.2 Structure of this document [intro.structure] 4.3 Syntax notation [syntax] 5 Lexical conventions [lex] 6 Basics [basic] 7 Expressions [expr] 8 Statements [stmt.stmt] 9 Declarations [dcl.dcl] 10 Modules [module] 11 Classes [class] 12 Overloading [over] 13 Templates [temp] 14 Exception handling [except] 15 Preprocessing directives [cpp] 16 Library introduction [library] 17 Language support library [support] 18 Concepts library [concepts] 19 Diagnostics library [diagnostics] 20 Memory management library [mem] 21 Metaprogramming library [meta] 22 General utilities library [utilities] 23 Strings library [strings] 24 Containers library [containers] 25 Iterators library [iterators] 26 Ranges library [ranges] 27 Algorithms library [algorithms] 28 Numerics library [numerics] 29 Time library [time] 30 Localization library [localization] 31 Input/output library [input.output] 32 Regular expressions library [re] 33 Concurrency support library [thread] Annex A (informative) Grammar summary [gram] Annex B (normative) Implementation quantities [implimits] Annex C (informative) Compatibility [diff] Annex D (normative) Compatibility features [depr] Annex E (informative) Conformance with UAX #31 [uaxid] Bibliography [bibliography] Index [generalindex] Index of grammar productions [grammarindex] Index of library headers [headerindex] Index of library names [libraryindex] Index of library concepts [conceptindex] Index of implementation-defined behavior [impldefindex]
If a program contains no violations of the rules in [lex] through [thread] and [depr], a conforming implementation shall, within its resource limits as described in [implimits], accept and correctly execute[cpp23 1] that program.
Otherwise, if a program contains a violation of any diagnosable rule or an occurrence of a construct described in this document as “conditionally-supported” when the implementation does not support that construct, a conforming implementation shall issue at least one diagnostic message.
NoteDuring template argument deduction and substitution, certain constructs that in other contexts require a diagnostic are treated differently; see [temp.deduct]. Furthermore, a conforming implementation
shall not accept a preprocessing translation unit containing a #error preprocessing directive ([cpp.error]),
#error
shall issue at least one diagnostic message for each #warning or #error preprocessing directive not following a #error preprocessing directive in a preprocessing translation unit, and
#warning
shall not accept a translation unit with a static_assert-declaration that fails ([dcl.pre]).