6 Basics [basic]

6.1 Preamble [basic.pre]

1
#
[Note 1:
This Clause presents the basic concepts of the C++ language.
It explains the difference between an object and a name and how they relate to the value categories for expressions.
It introduces the concepts of a declaration and a definition and presents C++'s notion of type, scope, linkage, and storage duration.
The mechanisms for starting and terminating a program are discussed.
Finally, this Clause presents the fundamental types of the language and lists the ways of constructing compound types from these.
— end note]
2
#
[Note 2:
This Clause does not cover concepts that affect only a single part of the language.
Such concepts are discussed in the relevant Clauses.
— end note]
3
#
An entity is a value, object, reference, structured binding, function, enumerator, type, class member, bit-field, template, template specialization, namespace, or pack.
5
#
Every name that denotes an entity is introduced by a declaration.
Every name that denotes a label is introduced either by a goto statement or a labeled-statement ([stmt.label]).
6
#
A variable is introduced by the declaration of a reference other than a non-static data member or of an object.
The variable's name, if any, denotes the reference or object.
7
#
A local entity is a variable with automatic storage duration, a structured binding whose corresponding variable is such an entity, or the *this object.
8
#
Some names denote types or templates.
In general, whenever a name is encountered it is necessary to determine whether that name denotes one of these entities before continuing to parse the program that contains it.
The process that determines this is called name lookup ([basic.lookup]).
9
#
Two names are the same if
10
#
A name used in more than one translation unit can potentially refer to the same entity in these translation units depending on the linkage of the name specified in each translation unit.

6.2 Declarations and definitions [basic.def]

1
#
A declaration may introduce one or more names into a translation unit or redeclare names introduced by previous declarations.
If so, the declaration specifies the interpretation and semantic properties of these names.
A declaration may also have effects including:
2
#
Each entity declared by a declaration is also defined by that declaration unless:
A declaration is said to be a definition of each entity that it defines.
[Example 1:
All but one of the following are definitions: int a; // defines a extern const int c = 1; // defines c int f(int x) { return x+a; } // defines f and defines x struct S { int a; int b; }; // defines S, S​::​a, and S​::​b struct X { // defines X int x; // defines non-static data member x static int y; // declares static data member y X(): x(0) { } // defines a constructor of X }; int X::y = 1; // defines X​::​y enum { up, down }; // defines up and down namespace N { int d; } // defines N and N​::​d namespace N1 = N; // defines N1 X anX; // defines anX whereas these are just declarations: extern int a; // declares a extern const int c; // declares c int f(int); // declares f struct S; // declares S typedef int Int; // declares Int extern X anotherX; // declares anotherX using N::d; // declares d
— end example]
3
#
[Note 1:
In some circumstances, C++ implementations implicitly define the default constructor ([class.default.ctor]), copy constructor, move constructor ([class.copy.ctor]), copy assignment operator, move assignment operator ([class.copy.assign]), or destructor member functions.
— end note]
[Example 2:
Given #include <string> struct C { std::string s; // std​::​string is the standard library class ([string.classes]) }; int main() { C a; C b = a; b = a; } the implementation will implicitly define functions to make the definition of C equivalent to struct C { std::string s; C() : s() { } C(const C& x): s(x.s) { } C(C&& x): s(static_cast<std::string&&>(x.s)) { } // : s(std​::​move(x.s)) { } C& operator=(const C& x) { s = x.s; return *this; } C& operator=(C&& x) { s = static_cast<std::string&&>(x.s); return *this; } // { s = std​::​move(x.s); return *this; } ~C() { } };
— end example]
4
#
[Note 2:
A class name can also be implicitly declared by an elaborated-type-specifier ([dcl.type.elab]).
— end note]
5
#
In the definition of an object, the type of that object shall not be an incomplete type ([basic.types]), an abstract class type, or a (possibly multi-dimensional) array thereof.
22)
Appearing inside the brace-enclosed declaration-seq in a linkage-specification does not affect whether a declaration is a definition.
 ⮥

6.3 One-definition rule [basic.def.odr]

1
#
No translation unit shall contain more than one definition of any variable, function, class type, enumeration type, template, default argument for a parameter (for a function in a given scope), or default template argument.
2
#
An expression or conversion is potentially evaluated unless it is an unevaluated operand ([expr.prop]), a subexpression thereof, or a conversion in an initialization or conversion sequence in such a context.
The set of potential results of an expression E is defined as follows:
  • (2.1)
    If E is an id-expression ([expr.prim.id]), the set contains only E.
  • (2.2)
    If E is a subscripting operation with an array operand, the set contains the potential results of that operand.
  • (2.3)
    If E is a class member access expression ([expr.ref]) of the form . template naming a non-static data member, the set contains the potential results of .
  • (2.4)
    If E is a class member access expression naming a static data member, the set contains the id-expression designating the data member.
  • (2.5)
    If E is a pointer-to-member expression of the form .* , the set contains the potential results of .
  • (2.6)
    If E has the form (), the set contains the potential results of .
  • (2.7)
    If E is a glvalue conditional expression, the set is the union of the sets of potential results of the second and third operands.
  • (2.8)
    If E is a comma expression, the set contains the potential results of the right operand.
  • (2.9)
    Otherwise, the set is empty.
[Note 1:
This set is a (possibly-empty) set of id-expressions, each of which is either E or a subexpression of E.
[Example 1:
In the following example, the set of potential results of the initializer of n contains the first S​::​x subexpression, but not the second S​::​x subexpression.
struct S { static const int x = 0; }; const int &f(const int &r); int n = b ? (1, S::x) // S​::​x is not odr-used here : f(S::x); // S​::​x is odr-used here, so a definition is required — end example]
— end note]
3
#
A function is named by an expression or conversion as follows:
  • (3.1)
    A function is named by an expression or conversion if it is the selected member of an overload set ([basic.lookup], [over.match], [over.over]) in an overload resolution performed as part of forming that expression or conversion, unless it is a pure virtual function and either the expression is not an id-expression naming the function with an explicitly qualified name or the expression forms a pointer to member ([expr.unary.op]).
    [Note 2:
    This covers taking the address of functions ([conv.func], [expr.unary.op]), calls to named functions ([expr.call]), operator overloading ([over]), user-defined conversions ([class.conv.fct]), allocation functions for new-expressions ([expr.new]), as well as non-default initialization ([dcl.init]).
    A constructor selected to copy or move an object of class type is considered to be named by an expression or conversion even if the call is actually elided by the implementation ([class.copy.elision]).
    — end note]
  • (3.2)
    A deallocation function for a class is named by a new-expression if it is the single matching deallocation function for the allocation function selected by overload resolution, as specified in [expr.new].
  • (3.3)
    A deallocation function for a class is named by a delete-expression if it is the selected usual deallocation function as specified in [expr.delete] and [class.free].
4
#
A variable x whose name appears as a potentially-evaluated expression E is odr-used by E unless
  • (4.1)
    x is a reference that is usable in constant expressions ([expr.const]), or
  • (4.2)
    x is a variable of non-reference type that is usable in constant expressions and has no mutable subobjects, and E is an element of the set of potential results of an expression of non-volatile-qualified non-class type to which the lvalue-to-rvalue conversion ([conv.lval]) is applied, or
  • (4.3)
    x is a variable of non-reference type, and E is an element of the set of potential results of a discarded-value expression ([expr.prop]) to which the lvalue-to-rvalue conversion is not applied.
5
#
A structured binding is odr-used if it appears as a potentially-evaluated expression.
6
#
*this is odr-used if this appears as a potentially-evaluated expression (including as the result of the implicit transformation in the body of a non-static member function ([class.mfct.non-static])).
7
#
A virtual member function is odr-used if it is not pure.
A function is odr-used if it is named by a potentially-evaluated expression or conversion.
A non-placement allocation or deallocation function for a class is odr-used by the definition of a constructor of that class.
A non-placement deallocation function for a class is odr-used by the definition of the destructor of that class, or by being selected by the lookup at the point of definition of a virtual destructor ([class.dtor]).23
8
#
An assignment operator function in a class is odr-used by an implicitly-defined copy-assignment or move-assignment function for another class as specified in [class.copy.assign].
A constructor for a class is odr-used as specified in [dcl.init].
A destructor for a class is odr-used if it is potentially invoked.
9
#
A local entity is odr-usable in a declarative region if:
  • (9.1)
    either the local entity is not *this, or an enclosing class or non-lambda function parameter scope exists and, if the innermost such scope is a function parameter scope, it corresponds to a non-static member function, and
  • (9.2)
    for each intervening declarative region ([basic.scope.declarative]) between the point at which the entity is introduced and the region (where *this is considered to be introduced within the innermost enclosing class or non-lambda function definition scope), either:
If a local entity is odr-used in a declarative region in which it is not odr-usable, the program is ill-formed.
[Example 2: void f(int n) { [] { n = 1; }; // error: n is not odr-usable due to intervening lambda-expression struct A { void f() { n = 2; } // error: n is not odr-usable due to intervening function definition scope }; void g(int = n); // error: n is not odr-usable due to intervening function parameter scope [=](int k = n) {}; // error: n is not odr-usable due to being // outside the block scope of the lambda-expression [&] { [n]{ return n; }; }; // OK } — end example]
10
#
Every program shall contain exactly one definition of every non-inline function or variable that is odr-used in that program outside of a discarded statement; no diagnostic required.
The definition can appear explicitly in the program, it can be found in the standard or a user-defined library, or (when appropriate) it is implicitly defined (see [class.default.ctor], [class.copy.ctor], [class.dtor], and [class.copy.assign]).
[Example 3: auto f() { struct A {}; return A{}; } decltype(f()) g(); auto x = g();
A program containing this translation unit is ill-formed because g is odr-used but not defined, and cannot be defined in any other translation unit because the local class A cannot be named outside this translation unit.
— end example]
11
#
A definition domain is a private-module-fragment or the portion of a translation unit excluding its private-module-fragment (if any).
A definition of an inline function or variable shall be reachable from the end of every definition domain in which it is odr-used outside of a discarded statement.
12
#
A definition of a class shall be reachable in every context in which the class is used in a way that requires the class type to be complete.
[Example 4:
The following complete translation unit is well-formed, even though it never defines X: struct X; // declare X as a struct type struct X* x1; // use X in pointer formation X* x2; // use X in pointer formation
— end example]
[Note 3:
The rules for declarations and expressions describe in which contexts complete class types are required.
A class type T must be complete if:
— end note]
13
#
There can be more than one definition of a in a program provided that each definition appears in a different translation unit and the definitions satisfy the following requirements.
Given such an entity D defined in more than one translation unit, for all definitions of D, or, if D is an unnamed enumeration, for all definitions of D that are reachable at any given program point, the following requirements shall be satisfied.
  • (13.7)
    Each such definition shall not be attached to a named module ([module.unit]).
  • (13.8)
    Each such definition shall consist of the same sequence of tokens, where the definition of a closure type is considered to consist of the sequence of tokens of the corresponding lambda-expression.
  • (13.9)
    In each such definition, corresponding names, looked up according to [basic.lookup], shall refer to the same entity, after overload resolution ([over.match]) and after matching of partial template specialization ([temp.over]), except that a name can refer to
    • (13.9.1)
      a non-volatile const object with internal or no linkage if the object or
    • (13.9.2)
      a reference with internal or no linkage initialized with a constant expression such that the reference refers to the same entity in all definitions of D.
  • (13.10)
    In each such definition, except within the default arguments and default template arguments of D, corresponding lambda-expressions shall have the same closure type (see below).
  • (13.11)
    In each such definition, corresponding entities shall have the same language linkage.
  • (13.12)
    In each such definition, the overloaded operators referred to, the implicit calls to conversion functions, constructors, operator new functions and operator delete functions, shall refer to the same function.
  • (13.13)
    In each such definition, a default argument used by an (implicit or explicit) function call or a default template argument used by an (implicit or explicit) template-id or simple-template-id is treated as if its token sequence were present in the definition of D; that is, the default argument or default template argument is subject to the requirements described in this paragraph (recursively).
  • (13.14)
    If D is a class with an implicitly-declared constructor ([class.default.ctor], [class.copy.ctor]), it is as if the constructor was implicitly defined in every translation unit where it is odr-used, and the implicit definition in every translation unit shall call the same constructor for a subobject of D.
    [Example 5: // translation unit 1: struct X { X(int, int); X(int, int, int); }; X::X(int, int = 0) { } class D { X x = 0; }; D d1; // X(int, int) called by D() // translation unit 2: struct X { X(int, int); X(int, int, int); }; X::X(int, int = 0, int = 0) { } class D { X x = 0; }; D d2; // X(int, int, int) called by D(); // D()'s implicit definition violates the ODR — end example]
  • (13.15)
    If D is a class with a defaulted three-way comparison operator function ([class.spaceship]), it is as if the operator was implicitly defined in every translation unit where it is odr-used, and the implicit definition in every translation unit shall call the same comparison operators for each subobject of D.
14
#
If D is a template and is defined in more than one translation unit, then the preceding requirements shall apply both to names from the template's enclosing scope used in the template definition ([temp.nondep]), and also to dependent names at the point of instantiation ([temp.dep]).
These requirements also apply to corresponding entities defined within each definition of D (including the closure types of lambda-expressions, but excluding entities defined within default arguments or default template arguments of either D or an entity not defined within D).
For each such entity and for D itself, the behavior is as if there is a single entity with a single definition, including in the application of these requirements to other entities.
[Note 4:
The entity is still declared in multiple translation units, and [basic.link] still applies to these declarations.
In particular, lambda-expressions ([expr.prim.lambda]) appearing in the type of D might result in the different declarations having distinct types, and lambda-expressions appearing in a default argument of D might still denote different types in different translation units.
— end note]
15
#
If these definitions do not satisfy these requirements, then the program is ill-formed; a diagnostic is required only if the entity is attached to a named module and a prior definition is reachable at the point where a later definition occurs.
16
#
[Example 6: inline void f(bool cond, void (*p)()) { if (cond) f(false, []{}); } inline void g(bool cond, void (*p)() = []{}) { if (cond) g(false); } struct X { void h(bool cond, void (*p)() = []{}) { if (cond) h(false); } };
If the definition of f appears in multiple translation units, the behavior of the program is as if there is only one definition of f.
If the definition of g appears in multiple translation units, the program is ill-formed (no diagnostic required) because each such definition uses a default argument that refers to a distinct lambda-expression closure type.
The definition of X can appear in multiple translation units of a valid program; the lambda-expressions defined within the default argument of X​::​h within the definition of X denote the same closure type in each translation unit.
— end example]
17
#
If, at any point in the program, there is more than one reachable unnamed enumeration definition in the same scope that have the same first enumerator name and do not have typedef names for linkage purposes ([dcl.enum]), those unnamed enumeration types shall be the same; no diagnostic required.
23)
An implementation is not required to call allocation and deallocation functions from constructors or destructors; however, this is a permissible implementation technique.
 ⮥

6.4 Scope [basic.scope]

6.4.1 Declarative regions and scopes [basic.scope.declarative]

1
#
Every name is introduced in some portion of program text called a declarative region, which is the largest part of the program in which that name is valid, that is, in which that name may be used as an unqualified name to refer to the same entity.
In general, each particular name is valid only within some possibly discontiguous portion of program text called its scope.
To determine the scope of a declaration, it is sometimes convenient to refer to the potential scope of a declaration.
The scope of a declaration is the same as its potential scope unless the potential scope contains another declaration of the same name.
In that case, the potential scope of the declaration in the inner (contained) declarative region is excluded from the scope of the declaration in the outer (containing) declarative region.
2
#
[Example 1:
In int j = 24; int main() { int i = j, j; j = 42; } the identifier j is declared twice as a name (and used twice).
The declarative region of the first j includes the entire example.
The potential scope of the first j begins immediately after that j and extends to the end of the program, but its (actual) scope excludes the text between the , and the }.
The declarative region of the second declaration of j (the j immediately before the semicolon) includes all the text between { and }, but its potential scope excludes the declaration of i.
The scope of the second declaration of j is the same as its potential scope.
— end example]
3
#
The names declared by a declaration are introduced into the scope in which the declaration occurs, except that the presence of a friend specifier, certain uses of the elaborated-type-specifier ([dcl.type.elab]), and using-directives ([namespace.udir]) alter this general behavior.
4
#
Given a set of declarations in a single declarative region, each of which specifies the same unqualified name,
  • (4.1)
    they shall all refer to the same entity, or all refer to functions and function templates; or
  • (4.2)
    exactly one declaration shall declare a class name or enumeration name that is not a typedef name and the other declarations shall all refer to the same variable, non-static data member, or enumerator, or all refer to functions and function templates; in this case the class name or enumeration name is hidden ([basic.scope.hiding]).
    [Note 1:
    A structured binding ([dcl.struct.bind]), namespace name ([basic.namespace]), or class template name ([temp.pre]) must be unique in its declarative region.
    — end note]
[Note 2:
These restrictions apply to the declarative region into which a name is introduced, which is not necessarily the same as the region in which the declaration occurs.
In particular, elaborated-type-specifiers ([dcl.type.elab]) and friend declarations ([class.friend]) can introduce a (possibly not visible) name into an enclosing namespace; these restrictions apply to that region.
Local extern declarations ([basic.link]) can introduce a name into the declarative region where the declaration appears and also introduce a (possibly not visible) name into an enclosing namespace; these restrictions apply to both regions.
— end note]
5
#
For a given declarative region R and a point P outside R, the set of intervening declarative regions between P and R comprises all declarative regions that are or enclose R and do not enclose P.
6
#
[Note 3:
The name lookup rules are summarized in [basic.lookup].
— end note]

6.4.2 Point of declaration [basic.scope.pdecl]

1
#
The point of declaration for a name is immediately after its complete declarator ([dcl.decl]) and before its initializer (if any), except as noted below.
[Example 1: unsigned char x = 12; { unsigned char x = x; }
Here, the initialization of the second x has undefined behavior, because the initializer accesses the second x outside its lifetime ([basic.life]).
— end example]
2
#
[Note 1:
A name from an outer scope remains visible up to the point of declaration of the name that hides it.
[Example 2:
const int i = 2; { int i[i]; } declares a block-scope array of two integers.
— end example]
— end note]
3
#
The point of declaration for a class or class template first declared by a class-specifier is immediately after the identifier or simple-template-id (if any) in its class-head ([class.pre]).
The point of declaration for an enumeration is immediately after the identifier (if any) in either its enum-specifier ([dcl.enum]) or its first opaque-enum-declaration ([dcl.enum]), whichever comes first.
The point of declaration of an alias or alias template immediately follows the defining-type-id to which the alias refers.
4
#
The point of declaration of a using-declarator that does not name a constructor is immediately after the using-declarator ([namespace.udecl]).
5
#
The point of declaration for an enumerator is immediately after its enumerator-definition.
[Example 3: const int x = 12; { enum { x = x }; }
Here, the enumerator x is initialized with the value of the constant x, namely 12.
— end example]
6
#
After the point of declaration of a class member, the member name can be looked up in the scope of its class.
[Note 2:
This is true even if the class is an incomplete class.
For example, struct X { enum E { z = 16 }; int b[X::z]; // OK };
— end note]
7
#
The point of declaration of a class first declared in an elaborated-type-specifier is as follows:
8
#
The point of declaration for an injected-class-name ([class.pre]) is immediately following the opening brace of the class definition.
9
#
The point of declaration for a function-local predefined variable ([dcl.fct.def.general]) is immediately before the function-body of a function definition.
10
#
The point of declaration of a structured binding ([dcl.struct.bind]) is immediately after the identifier-list of the structured binding declaration.
11
#
The point of declaration for the variable or the structured bindings declared in the for-range-declaration of a range-based for statement ([stmt.ranged]) is immediately after the for-range-initializer.
12
#
The point of declaration for a template parameter is immediately after its complete template-parameter.
[Example 4: typedef unsigned char T; template<class T = T // lookup finds the typedef name of unsigned char , T // lookup finds the template parameter N = 0> struct A { }; — end example]
13
#
[Note 5:
Friend declarations refer to functions or classes that are members of the nearest enclosing namespace, but they do not introduce new names into that namespace ([namespace.memdef]).
Function declarations at block scope and variable declarations with the extern specifier at block scope refer to declarations that are members of an enclosing namespace, but they do not introduce new names into that scope.
— end note]
14
#
[Note 6:
For point of instantiation of a template, see [temp.point].
— end note]

6.4.3 Block scope [basic.scope.block]

1
#
A name declared in a block ([stmt.block]) is local to that block; it has block scope.
Its potential scope begins at its point of declaration ([basic.scope.pdecl]) and ends at the end of its block.
A variable declared at block scope is a local variable.
2
#
The name declared in an exception-declaration is local to the handler and shall not be redeclared in the outermost block of the handler.
3
#
Names declared in the init-statement, the for-range-declaration, and in the condition of if, while, for, and switch statements are local to the if, while, for, or switch statement (including the controlled statement), and shall not be redeclared in a subsequent condition of that statement nor in the outermost block (or, for the if statement, any of the outermost blocks) of the controlled statement.
[Example 1: if (int x = f()) { int x; // error: redeclaration of x } else { int x; // error: redeclaration of x } — end example]

6.4.4 Function parameter scope [basic.scope.param]

1
#
A function parameter (including one appearing in a lambda-declarator) or function-local predefined variable ([dcl.fct.def]) has function parameter scope.
The potential scope of a parameter or function-local predefined variable begins at its point of declaration.
If the nearest enclosing function declarator is not the declarator of a function definition, the potential scope ends at the end of that function declarator.
Otherwise, if the function has a function-try-block the potential scope ends at the end of the last associated handler.
Otherwise the potential scope ends at the end of the outermost block of the function definition.
A parameter name shall not be redeclared in the outermost block of the function definition nor in the outermost block of any handler associated with a function-try-block.

6.4.5 Function scope [basic.funscope]

1
#
Labels have function scope and may be used anywhere in the function in which they are declared.
Only labels have function scope.

6.4.6 Namespace scope [basic.scope.namespace]

1
#
The declarative region of a namespace-definition is its namespace-body.
Entities declared in a namespace-body are said to be members of the namespace, and names introduced by these declarations into the declarative region of the namespace are said to be member names of the namespace.
A namespace member name has namespace scope.
Its potential scope includes its namespace from the name's point of declaration onwards; and for each using-directive ([namespace.udir]) that nominates the member's namespace, the member's potential scope includes that portion of the potential scope of the using-directive that follows the member's point of declaration.
[Example 1: namespace N { int i; int g(int a) { return a; } int j(); void q(); } namespace { int l=1; } // the potential scope of l is from its point of declaration to the end of the translation unit namespace N { int g(char a) { // overloads N​::​g(int) return l+a; // l is from unnamed namespace } int i; // error: duplicate definition int j(); // OK: duplicate function declaration int j() { // OK: definition of N​::​j() return g(i); // calls N​::​g(int) } int q(); // error: different return type } — end example]
2
#
If a translation unit Q is imported into a translation unit R, the potential scope of a name X declared with namespace scope in Q is extended to include the portion of the corresponding namespace scope in R following the first module-import-declaration or module-declaration in R that imports Q (directly or indirectly) if
  • (2.1)
    X does not have internal linkage, and
  • (2.2)
    X is declared after the module-declaration in Q (if any), and
  • (2.3)
    either X is exported or Q and R are part of the same module.
[Note 1:
A module-import-declaration imports both the named translation unit(s) and any modules named by exported module-import-declarations within them, recursively.
[Example 2:

Translation unit #1:export module Q; export int sq(int i) { return i*i; }

Translation unit #2:export module R; export import Q;

Translation unit #3:import R; int main() { return sq(9); } // OK: sq from module Q — end example]

— end note]
3
#
A namespace member can also be referred to after the ​::​ scope resolution operator ([expr.prim.id.qual]) applied to the name of its namespace or the name of a namespace which nominates the member's namespace in a using-directive; see [namespace.qual].
4
#
The outermost declarative region of a translation unit is also a namespace, called the global namespace.
A name declared in the global namespace has global namespace scope (also called global scope).
The potential scope of such a name begins at its point of declaration ([basic.scope.pdecl]) and ends at the end of the translation unit that is its declarative region.
A name with global namespace scope is said to be a global name.

6.4.7 Class scope [basic.scope.class]

1
#
The potential scope of a name declared in a class consists not only of the declarative region following the name's point of declaration, but also of all complete-class contexts ([class.mem]) of that class.
2
#
A name N used in a class S shall refer to the same declaration in its context and when re-evaluated in the completed scope of S.
No diagnostic is required for a violation of this rule.
3
#
A name declared within a member function hides a declaration of the same name whose scope extends to or past the end of the member function's class.
4
#
The potential scope of a declaration in a class that extends to or past the end of a class definition also extends to the regions defined by its member definitions, even if the members are defined lexically outside the class (this includes static data member definitions, nested class definitions, and member function definitions, including the member function body and any portion of the declarator part of such definitions which follows the declarator-id, including a parameter-declaration-clause and any default arguments).
5
#
[Example 1: typedef int c; enum { i = 1 }; class X { char v[i]; // error: i refers to ​::​i but when reevaluated is X​::​i int f() { return sizeof(c); } // OK: X​::​c char c; enum { i = 2 }; }; typedef char* T; struct Y { T a; // error: T refers to ​::​T but when reevaluated is Y​::​T typedef long T; T b; }; typedef int I; class D { typedef I I; // error, even though no reordering involved }; — end example]
6
#
The name of a class member shall only be used as follows:
  • (6.1)
    in the scope of its class (as described above) or a class derived from its class,
  • (6.2)
    after the . operator applied to an expression of the type of its class ([expr.ref]) or a class derived from its class,
  • (6.3)
    after the -> operator applied to a pointer to an object of its class ([expr.ref]) or a class derived from its class,
  • (6.4)
    after the ​::​ scope resolution operator ([expr.prim.id.qual]) applied to the name of its class or a class derived from its class.

6.4.8 Enumeration scope [basic.scope.enum]

1
#
Its potential scope begins at its point of declaration and terminates at the end of the enum-specifier.

6.4.9 Template parameter scope [basic.scope.temp]

1
#
The declarative region of the name of a template parameter of a template template-parameter is the smallest template-parameter-list in which the name was introduced.
2
#
The declarative region of the name of a template parameter of a template is the smallest template-declaration in which the name was introduced.
Only template parameter names belong to this declarative region; any other kind of name introduced by the declaration of a template-declaration is instead introduced into the same declarative region where it would be introduced as a result of a non-template declaration of the same name.
[Example 1: namespace N { template<class T> struct A { }; // #1 template<class U> void f(U) { } // #2 struct B { template<class V> friend int g(struct C*); // #3 }; }
The declarative regions of T, U and V are the template-declarations on lines #1, #2, and #3, respectively.
But the names A, f, g and C all belong to the same declarative region — namely, the namespace-body of N.
(g is still considered to belong to this declarative region in spite of its being hidden during qualified and unqualified name lookup.)
— end example]
3
#
The potential scope of a template parameter name begins at its point of declaration and ends at the end of its declarative region.
[Note 1:
This implies that a template-parameter can be used in the declaration of subsequent template-parameters and their default arguments but cannot be used in preceding template-parameters or their default arguments.
For example, template<class T, T* p, class U = T> class X { /* ... */ }; template<class T> void f(T* p = new T);
This also implies that a template-parameter can be used in the specification of base classes.
For example, template<class T> class X : public Array<T> { /* ... */ }; template<class T> class Y : public T { /* ... */ };
The use of a template parameter as a base class implies that a class used as a template argument must be defined and not just declared when the class template is instantiated.
— end note]
4
#
The declarative region of the name of a template parameter is nested within the immediately-enclosing declarative region.
[Note 2:
As a result, a template-parameter hides any entity with the same name in an enclosing scope ([basic.scope.hiding]).
[Example 2: typedef int N; template<N X, typename N, template<N Y> class T> struct A;
Here, X is a non-type template parameter of type int and Y is a non-type template parameter of the same type as the second template parameter of A.
— end example]
— end note]
5
#
[Note 3:
Because the name of a template parameter cannot be redeclared within its potential scope ([temp.local]), a template parameter's scope is often its potential scope.
However, it is still possible for a template parameter name to be hidden; see [temp.local].
— end note]

6.4.10 Name hiding [basic.scope.hiding]

1
#
A declaration of a name in a nested declarative region hides a declaration of the same name in an enclosing declarative region; see [basic.scope.declarative] and [basic.lookup.unqual].
2
#
If a class name ([class.name]) or enumeration name ([dcl.enum]) and a variable, data member, function, or enumerator are declared in the same declarative region (in any order) with the same name (excluding declarations made visible via using-directives ([basic.lookup.unqual])), the class or enumeration name is hidden wherever the variable, data member, function, or enumerator name is visible.
3
#
In a member function definition, the declaration of a name at block scope hides the declaration of a member of the class with the same name; see [basic.scope.class].
The declaration of a member in a derived class hides the declaration of a member of a base class of the same name; see [class.member.lookup].
4
#
During the lookup of a name qualified by a namespace name, declarations that would otherwise be made visible by a using-directive can be hidden by declarations with the same name in the namespace containing the using-directive; see [namespace.qual].
5
#
If a name is in scope and is not hidden it is said to be visible.

6.5 Name lookup [basic.lookup]

6.5.1 General [basic.lookup.general]

1
#
The name lookup rules apply uniformly to all names (including typedef-names ([dcl.typedef]), namespace-names ([basic.namespace]), and class-names ([class.name])) wherever the grammar allows such names in the context discussed by a particular rule.
Name lookup associates the use of a name with a set of declarations ([basic.def]) of that name.
If the declarations found by name lookup all denote functions or function templates, the declarations are said to form an overload set.
The declarations found by name lookup shall either all denote the same entity or form an overload set.
Overload resolution ([over.match], [over.over]) takes place after name lookup has succeeded.
The access rules ([class.access]) are considered only once name lookup and function overload resolution (if applicable) have succeeded.
Only after name lookup, function overload resolution (if applicable) and access checking have succeeded are the semantic properties introduced by the name's declaration and its reachable ([module.reach]) redeclarations used further in expression processing ([expr]).
2
#
A name “looked up in the context of an expression” is looked up in the scope where the expression is found.
3
#
The injected-class-name of a class ([class.pre]) is also considered to be a member of that class for the purposes of name hiding and lookup.
4
#
[Note 1:
[basic.link] discusses linkage issues.
The notions of scope, point of declaration and name hiding are discussed in [basic.scope].
— end note]

6.5.2 Unqualified name lookup [basic.lookup.unqual]

1
#
In all the cases listed in [basic.lookup.unqual], the scopes are searched for a declaration in the order listed in each of the respective categories; name lookup ends as soon as a declaration is found for the name.
If no declaration is found, the program is ill-formed.
2
#
The declarations from the namespace nominated by a using-directive become visible in a namespace enclosing the using-directive; see [namespace.udir].
For the purpose of the unqualified name lookup rules described in [basic.lookup.unqual], the declarations from the namespace nominated by the using-directive are considered members of that enclosing namespace.
3
#
The lookup for an unqualified name used as the postfix-expression of a function call is described in [basic.lookup.argdep].
[Note 1:
For purposes of determining (during parsing) whether an expression is a postfix-expression for a function call, the usual name lookup rules apply.
In some cases a name followed by < is treated as a template-name even though name lookup did not find a template-name (see [temp.names]).
For example, int h; void g(); namespace N { struct A {}; template <class T> int f(T); template <class T> int g(T); template <class T> int h(T); } int x = f<N::A>(N::A()); // OK: lookup of f finds nothing, f treated as template name int y = g<N::A>(N::A()); // OK: lookup of g finds a function, g treated as template name int z = h<N::A>(N::A()); // error: h< does not begin a template-id
The rules in [basic.lookup.argdep] have no effect on the syntactic interpretation of an expression.
For example, typedef int f; namespace N { struct A { friend void f(A &); operator int(); void g(A a) { int i = f(a); // f is the typedef, not the friend function: equivalent to int(a) } }; }
Because the expression is not a function call, the argument-dependent name lookup ([basic.lookup.argdep]) does not apply and the friend function f is not found.
— end note]
4
#
A name used in global scope, outside of any function, class or user-declared namespace, shall be declared before its use in global scope.
5
#
A name used in a user-declared namespace outside of the definition of any function or class shall be declared before its use in that namespace or before its use in a namespace enclosing its namespace.
6
#
In the definition of a function that is a member of namespace N, a name used after the function's declarator-id24 shall be declared before its use in the block in which it is used or in one of its enclosing blocks ([stmt.block]) or shall be declared before its use in namespace N or, if N is a nested namespace, shall be declared before its use in one of N's enclosing namespaces.
[Example 1: namespace A { namespace N { void f(); } } void A::N::f() { i = 5; // The following scopes are searched for a declaration of i: // 1) outermost block scope of A​::​N​::​f, before the use of i // 2) scope of namespace N // 3) scope of namespace A // 4) global scope, before the definition of A​::​N​::​f } — end example]
7
#
A name used in the definition of a class X25 outside of a complete-class context ([class.mem]) of X shall be declared in one of the following ways:
  • (7.1)
    before its use in class X or be a member of a base class of X ([class.member.lookup]), or
  • (7.2)
    if X is a nested class of class Y, before the definition of X in Y, or shall be a member of a base class of Y (this lookup applies in turn to Y's enclosing classes, starting with the innermost enclosing class),26 or
  • (7.3)
    if X is a local class or is a nested class of a local class, before the definition of class X in a block enclosing the definition of class X, or
  • (7.4)
    if X is a member of namespace N, or is a nested class of a class that is a member of N, or is a local class or a nested class within a local class of a function that is a member of N, before the definition of class X in namespace N or in one of N's enclosing namespaces.
[Example 2: namespace M { class B { }; } namespace N { class Y : public M::B { class X { int a[i]; }; }; } // The following scopes are searched for a declaration of i: // 1) scope of class N​::​Y​::​X, before the use of i // 2) scope of class N​::​Y, before the definition of N​::​Y​::​X // 3) scope of N​::​Y's base class M​::​B // 4) scope of namespace N, before the definition of N​::​Y // 5) global scope, before the definition of N — end example]
[Note 2:
When looking for a prior declaration of a class or function introduced by a friend declaration, scopes outside of the innermost enclosing namespace scope are not considered; see [namespace.memdef].
— end note]
[Note 3:
[basic.scope.class] further describes the restrictions on the use of names in a class definition.
[class.nest] further describes the restrictions on the use of names in nested class definitions.
[class.local] further describes the restrictions on the use of names in local class definitions.
— end note]
8
#
For the members of a class X, a name used in a complete-class context ([class.mem]) of X or in the definition of a class member outside of the definition of X, following the member's declarator-id27, shall be declared in one of the following ways:
  • (8.1)
    before its use in the block in which it is used or in an enclosing block ([stmt.block]), or
  • (8.2)
    shall be a member of class X or be a member of a base class of X ([class.member.lookup]), or
  • (8.3)
    if X is a nested class of class Y, shall be a member of Y, or shall be a member of a base class of Y (this lookup applies in turn to Y's enclosing classes, starting with the innermost enclosing class),28 or
  • (8.4)
    if X is a local class or is a nested class of a local class, before the definition of class X in a block enclosing the definition of class X, or
  • (8.5)
    if X is a member of namespace N, or is a nested class of a class that is a member of N, or is a local class or a nested class within a local class of a function that is a member of N, before the use of the name, in namespace N or in one of N's enclosing namespaces.
[Example 3: class B { }; namespace M { namespace N { class X : public B { void f(); }; } } void M::N::X::f() { i = 16; } // The following scopes are searched for a declaration of i: // 1) outermost block scope of M​::​N​::​X​::​f, before the use of i // 2) scope of class M​::​N​::​X // 3) scope of M​::​N​::​X's base class B // 4) scope of namespace M​::​N // 5) scope of namespace M // 6) global scope, before the definition of M​::​N​::​X​::​f — end example]
[Note 4:
[class.mfct] and [class.static] further describe the restrictions on the use of names in member function definitions.
[class.nest] further describes the restrictions on the use of names in the scope of nested classes.
[class.local] further describes the restrictions on the use of names in local class definitions.
— end note]
9
#
Name lookup for a name used in the definition of a friend function defined inline in the class granting friendship shall proceed as described for lookup in member function definitions.
If the friend function is not defined in the class granting friendship, name lookup in the friend function definition shall proceed as described for lookup in namespace member function definitions.
10
#
In a friend declaration naming a member function, a name used in the function declarator and not part of a template-argument in the declarator-id is first looked up in the scope of the member function's class ([class.member.lookup]).
If it is not found, or if the name is part of a template-argument in the declarator-id, the look up is as described for unqualified names in the definition of the class granting friendship.
[Example 4: struct A { typedef int AT; void f1(AT); void f2(float); template <class T> void f3(); }; struct B { typedef char AT; typedef float BT; friend void A::f1(AT); // parameter type is A​::​AT friend void A::f2(BT); // parameter type is B​::​BT friend void A::f3<AT>(); // template argument is B​::​AT }; — end example]
11
#
During the lookup for a name used as a default argument in a function parameter-declaration-clause or used in the expression of a mem-initializer for a constructor ([class.base.init]), the function parameter names are visible and hide the names of entities declared in the block, class or namespace scopes containing the function declaration.
[Note 5:
[dcl.fct.default] further describes the restrictions on the use of names in default arguments.
[class.base.init] further describes the restrictions on the use of names in a ctor-initializer.
— end note]
12
#
During the lookup of a name used in the constant-expression of an enumerator-definition, previously declared enumerators of the enumeration are visible and hide the names of entities declared in the block, class, or namespace scopes containing the enum-specifier.
13
#
A name used in the definition of a static data member of class X (after the qualified-id of the static member) is looked up as if the name was used in a member function of X.
[Note 6:
[class.static.data] further describes the restrictions on the use of names in the definition of a static data member.
— end note]
14
#
If a variable member of a namespace is defined outside of the scope of its namespace then any name that appears in the definition of the member (after the declarator-id) is looked up as if the definition of the member occurred in its namespace.
[Example 5: namespace N { int i = 4; extern int j; } int i = 2; int N::j = i; // N​::​j == 4 — end example]
15
#
A name used in the handler for a function-try-block ([except.pre]) is looked up as if the name was used in the outermost block of the function definition.
In particular, the function parameter names shall not be redeclared in the exception-declaration nor in the outermost block of a handler for the function-try-block.
Names declared in the outermost block of the function definition are not found when looked up in the scope of a handler for the function-try-block.
[Note 7:
But function parameter names are found.
— end note]
16
#
[Note 8:
The rules for name lookup in template definitions are described in [temp.res].
— end note]
24)
This refers to unqualified names that occur, for instance, in a type or default argument in the parameter-declaration-clause or used in the function body.
 ⮥
25)
This refers to unqualified names following the class name; such a name might be used in a base-specifier or in the member-specification of the class definition.
 ⮥
26)
This lookup applies whether the definition of X is nested within Y's definition or whether X's definition appears in a namespace scope enclosing Y's definition ([class.nest]).
 ⮥
27)
That is, an unqualified name that occurs, for instance, in a type in the parameter-declaration-clause or in the noexcept-specifier.
 ⮥
28)
This lookup applies whether the member function is defined within the definition of class X or whether the member function is defined in a namespace scope enclosing X's definition.
 ⮥

6.5.3 Argument-dependent name lookup [basic.lookup.argdep]

1
#
When the postfix-expression in a function call is an unqualified-id, other namespaces not considered during the usual unqualified lookup may be searched, and in those namespaces, namespace-scope friend function or function template declarations ([class.friend]) not otherwise visible may be found.
These modifications to the search depend on the types of the arguments (and for template template arguments, the namespace of the template argument).
[Example 1: namespace N { struct S { }; void f(S); } void g() { N::S s; f(s); // OK: calls N​::​f (f)(s); // error: N​::​f not considered; parentheses prevent argument-dependent lookup } — end example]
2
#
For each argument type T in the function call, there is a set of zero or more associated namespaces and a set of zero or more associated entities (other than namespaces) to be considered.
The sets of namespaces and entities are determined entirely by the types of the function arguments (and the namespace of any template template argument).
Typedef names and using-declarations used to specify the types do not contribute to this set.
The sets of namespaces and entities are determined in the following way:
  • (2.1)
    If T is a fundamental type, its associated sets of namespaces and entities are both empty.
  • (2.2)
    If T is a class type (including unions), its associated entities are: the class itself; the class of which it is a member, if any; and its direct and indirect base classes.
    Its associated namespaces are the innermost enclosing namespaces of its associated entities.
    Furthermore, if T is a class template specialization, its associated namespaces and entities also include: the namespaces and entities associated with the types of the template arguments provided for template type parameters (excluding template template parameters); the templates used as template template arguments; the namespaces of which any template template arguments are members; and the classes of which any member templates used as template template arguments are members.
    [Note 1:
    Non-type template arguments do not contribute to the set of associated namespaces.
    — end note]
  • (2.3)
    If T is an enumeration type, its associated namespace is the innermost enclosing namespace of its declaration, and its associated entities are T and, if it is a class member, the member's class.
  • (2.4)
    If T is a pointer to U or an array of U, its associated namespaces and entities are those associated with U.
  • (2.5)
    If T is a function type, its associated namespaces and entities are those associated with the function parameter types and those associated with the return type.
  • (2.6)
    If T is a pointer to a member function of a class X, its associated namespaces and entities are those associated with the function parameter types and return type, together with those associated with X.
  • (2.7)
    If T is a pointer to a data member of class X, its associated namespaces and entities are those associated with the member type together with those associated with X.
If an associated namespace is an inline namespace, its enclosing namespace is also included in the set.
If an associated namespace directly contains inline namespaces, those inline namespaces are also included in the set.
In addition, if the argument is the name or address of an overload set, its associated entities and namespaces are the union of those associated with each of the members of the set, i.e., the entities and namespaces associated with its parameter types and return type.
Additionally, if the aforementioned overload set is named with a template-id, its associated entities and namespaces also include those of its type template-arguments and its template template-arguments.
3
#
Let X be the lookup set produced by unqualified lookup and let Y be the lookup set produced by argument dependent lookup (defined as follows).
If X contains
  • (3.1)
    a declaration of a class member, or
  • (3.2)
    a block-scope function declaration that is not a using-declaration, or
  • (3.3)
    a declaration that is neither a function nor a function template
then Y is empty.
Otherwise Y is the set of declarations found in the namespaces associated with the argument types as described below.
The set of declarations found by the lookup of the name is the union of X and Y.
[Note 2:
The namespaces and entities associated with the argument types can include namespaces and entities already considered by the ordinary unqualified lookup.
— end note]
[Example 2: namespace NS { class T { }; void f(T); void g(T, int); } NS::T parm; void g(NS::T, float); int main() { f(parm); // OK: calls NS​::​f extern void g(NS::T, float); g(parm, 1); // OK: calls g(NS​::​T, float) } — end example]
4
#
When considering an associated namespace N, the lookup is the same as the lookup performed when N is used as a qualifier ([namespace.qual]) except that:
  • (4.1)
    Any using-directives in N are ignored.
  • (4.2)
    All names except those of (possibly overloaded) functions and function templates are ignored.
  • (4.3)
    Any namespace-scope friend functions or friend function templates ([class.friend]) declared in classes with reachable definitions in the set of associated entities are visible within their respective namespaces even if they are not visible during an ordinary lookup ([namespace.memdef]).
  • (4.4)
    Any exported declaration D in N declared within the purview of a named module M ([module.interface]) is visible if there is an associated entity attached to M with the same innermost enclosing non-inline namespace as D.
  • (4.5)
    If the lookup is for a dependent name ([temp.dep], [temp.dep.candidate]), any declaration D in N is visible if D would be visible to qualified name lookup ([namespace.qual]) at any point in the instantiation context ([module.context]) of the lookup, unless D is declared in another translation unit, attached to the global module, and is either discarded ([module.global.frag]) or has internal linkage.
5
#
[Example 3:

Translation unit #1:export module M; namespace R { export struct X {}; export void f(X); } namespace S { export void f(R::X, R::X); }

Translation unit #2:export module N; import M; export R::X make(); namespace R { static int g(X); } export template<typename T, typename U> void apply(T t, U u) { f(t, u); g(t); }

Translation unit #3:module Q; import N; namespace S { struct Z { template<typename T> operator T(); }; } void test() { auto x = make(); // OK, decltype(x) is R​::​X in module M R::f(x); // error: R and R​::​f are not visible here f(x); // OK, calls R​::​f from interface of M f(x, S::Z()); // error: S​::​f in module M not considered // even though S is an associated namespace apply(x, S::Z()); // error: S​::​f is visible in instantiation context, but // R​::​g has internal linkage and cannot be used outside TU #2 } — end example]

6.5.4 Qualified name lookup [basic.lookup.qual]

6.5.4.1 General [basic.lookup.qual.general]

1
#
The name of a class or namespace member or enumerator can be referred to after the ​::​ scope resolution operator ([expr.prim.id.qual]) applied to a nested-name-specifier that denotes its class, namespace, or enumeration.
If a ​::​ scope resolution operator in a nested-name-specifier is not preceded by a decltype-specifier, lookup of the name preceding that ​::​ considers only namespaces, types, and templates whose specializations are types.
If the name found does not designate a namespace or a class, enumeration, or dependent type, the program is ill-formed.
[Example 1: class A { public: static int n; }; int main() { int A; A::n = 42; // OK A b; // error: A does not name a type } — end example]
2
#
[Note 1:
Multiply qualified names, such as N1​::​N2​::​N3​::​n, can be used to refer to members of nested classes ([class.nest]) or members of nested namespaces.
— end note]
3
#
In a declaration in which the declarator-id is a qualified-id, names used before the qualified-id being declared are looked up in the defining namespace scope; names following the qualified-id are looked up in the scope of the member's class or namespace.
[Example 2: class X { }; class C { class X { }; static const int number = 50; static X arr[number]; }; X C::arr[number]; // error: // equivalent to ​::​X C​::​arr[C​::​number]; // and not to C​::​X C​::​arr[C​::​number]; — end example]
4
#
A name prefixed by the unary scope operator ​::​ ([expr.prim.id.qual]) is looked up in global scope, in the translation unit where it is used.
The name shall be declared in global namespace scope or shall be a name whose declaration is visible in global scope because of a using-directive ([namespace.qual]).
The use of ​::​ allows a global name to be referred to even if its identifier has been hidden.
5
#
A name prefixed by a nested-name-specifier that nominates an enumeration type shall represent an enumerator of that enumeration.
6
#
In a qualified-id of the form:
nested-name-specifier type-name :: ~ type-name
the second type-name is looked up in the same scope as the first.
[Example 3: struct C { typedef int I; }; typedef int I1, I2; extern int* p; extern int* q; p->C::I::~I(); // I is looked up in the scope of C q->I1::~I2(); // I2 is looked up in the scope of the postfix-expression struct A { ~A(); }; typedef A AB; int main() { AB* p; p->AB::~AB(); // explicitly calls the destructor for A } — end example]
[Note 2:
[basic.lookup.classref] describes how name lookup proceeds after the . and -> operators.
— end note]

6.5.4.2 Class members [class.qual]

1
#
If the nested-name-specifier of a qualified-id nominates a class, the name specified after the nested-name-specifier is looked up in the scope of the class ([class.member.lookup]), except for the cases listed below.
The name shall represent one or more members of that class or of one of its base classes ([class.derived]).
[Note 1:
A class member can be referred to using a qualified-id at any point in its potential scope ([basic.scope.class]).
— end note]
The exceptions to the name lookup rule above are the following:
2
#
In a lookup in which function names are not ignored29 and the nested-name-specifier nominates a class C: the name is instead considered to name the constructor of class C.
[Note 2:
For example, the constructor is not an acceptable lookup result in an elaborated-type-specifier so the constructor would not be used in place of the injected-class-name.
— end note]
Such a constructor name shall be used only in the declarator-id of a declaration that names a constructor or in a using-declaration.
[Example 1: struct A { A(); }; struct B: public A { B(); }; A::A() { } B::B() { } B::A ba; // object of type A A::A a; // error: A​::​A is not a type name struct A::A a2; // object of type A — end example]
3
#
A class member name hidden by a name in a nested declarative region or by the name of a derived class member can still be found if qualified by the name of its class followed by the ​::​ operator.
29)
Lookups in which function names are ignored include names appearing in a nested-name-specifier, an elaborated-type-specifier, or a base-specifier.
 ⮥

6.5.4.3 Namespace members [namespace.qual]

1
#
If the nested-name-specifier of a qualified-id nominates a namespace (including the case where the nested-name-specifier is ​::​, i.e., nominating the global namespace), the name specified after the nested-name-specifier is looked up in the scope of the namespace.
The names in a template-argument of a template-id are looked up in the context in which the entire postfix-expression occurs.
2
#
For a namespace X and name m, the namespace-qualified lookup set is defined as follows: Let be the set of all declarations of m in X and the inline namespace set of X ([namespace.def]) whose potential scope ([basic.scope.namespace]) would include the namespace in which m is declared at the location of the nested-name-specifier.
If is not empty, is ; otherwise, is the union of for all namespaces nominated by using-directives in X and its inline namespace set.
3
#
Given X​::​m (where X is a user-declared namespace), or given ​::​m (where X is the global namespace), if is the empty set, the program is ill-formed.
Otherwise, if has exactly one member, or if the context of the reference is a using-declaration ([namespace.udecl]), is the required set of declarations of m.
Otherwise if the use of m is not one that allows a unique declaration to be chosen from , the program is ill-formed.
[Example 1: int x; namespace Y { void f(float); void h(int); } namespace Z { void h(double); } namespace A { using namespace Y; void f(int); void g(int); int i; } namespace B { using namespace Z; void f(char); int i; } namespace AB { using namespace A; using namespace B; void g(); } void h() { AB::g(); // g is declared directly in AB, therefore S is { AB​::​g() } and AB​::​g() is chosen AB::f(1); // f is not declared directly in AB so the rules are applied recursively to A and B; // namespace Y is not searched and Y​::​f(float) is not considered; // S is and overload resolution chooses A​::​f(int) AB::f('c'); // as above but resolution chooses B​::​f(char) AB::x++; // x is not declared directly in AB, and is not declared in A or B, so the rules // are applied recursively to Y and Z, S is { } so the program is ill-formed AB::i++; // i is not declared directly in AB so the rules are applied recursively to A and B, // S is so the use is ambiguous and the program is ill-formed AB::h(16.8); // h is not declared directly in AB and not declared directly in A or B so the rules // are applied recursively to Y and Z, S is and // overload resolution chooses Z​::​h(double) } — end example]
4
#
[Note 1:
The same declaration found more than once is not an ambiguity (because it is still a unique declaration).
[Example 2: namespace A { int a; } namespace B { using namespace A; } namespace C { using namespace A; } namespace BC { using namespace B; using namespace C; } void f() { BC::a++; // OK: S is } namespace D { using A::a; } namespace BD { using namespace B; using namespace D; } void g() { BD::a++; // OK: S is } — end example]
— end note]
5
#
[Example 3:
Because each referenced namespace is searched at most once, the following is well-defined: namespace B { int b; } namespace A { using namespace B; int a; } namespace B { using namespace A; } void f() { A::a++; // OK: a declared directly in A, S is { A​::​a } B::a++; // OK: both A and B searched (once), S is { A​::​a } A::b++; // OK: both A and B searched (once), S is { B​::​b } B::b++; // OK: b declared directly in B, S is { B​::​b } }
— end example]
6
#
During the lookup of a qualified namespace member name, if the lookup finds more than one declaration of the member, and if one declaration introduces a class name or enumeration name and the other declarations introduce either the same variable, the same enumerator, or a set of functions, the non-type name hides the class or enumeration name if and only if the declarations are from the same namespace; otherwise (the declarations are from different namespaces), the program is ill-formed.
[Example 4: namespace A { struct x { }; int x; int y; } namespace B { struct y { }; } namespace C { using namespace A; using namespace B; int i = C::x; // OK, A​::​x (of type int) int j = C::y; // ambiguous, A​::​y or B​::​y } — end example]
7
#
In a declaration for a namespace member in which the declarator-id is a qualified-id, given that the qualified-id for the namespace member has the form
nested-name-specifier unqualified-id
the unqualified-id shall name a member of the namespace designated by the nested-name-specifier or of an element of the inline namespace set of that namespace.
[Example 5: namespace A { namespace B { void f1(int); } using namespace B; } void A::f1(int){ } // error: f1 is not a member of A — end example]
However, in such namespace member declarations, the nested-name-specifier may rely on using-directives to implicitly provide the initial part of the nested-name-specifier.
[Example 6: namespace A { namespace B { void f1(int); } } namespace C { namespace D { void f1(int); } } using namespace A; using namespace C::D; void B::f1(int){ } // OK, defines A​::​B​::​f1(int) — end example]

6.5.5 Elaborated type specifiers [basic.lookup.elab]

1
#
An elaborated-type-specifier ([dcl.type.elab]) may be used to refer to a previously declared class-name or enum-name even though the name has been hidden by a non-type declaration.
2
#
If the elaborated-type-specifier has no nested-name-specifier, and unless the elaborated-type-specifier appears in a declaration with the following form:
class-key attribute-specifier-seq identifier ;
the identifier is looked up according to [basic.lookup.unqual] but ignoring any non-type names that have been declared.
If the elaborated-type-specifier is introduced by the enum keyword and this lookup does not find a previously declared type-name, the elaborated-type-specifier is ill-formed.
If the elaborated-type-specifier is introduced by the class-key and this lookup does not find a previously declared type-name, or if the elaborated-type-specifier appears in a declaration with the form:
class-key attribute-specifier-seq identifier ;
the elaborated-type-specifier is a declaration that introduces the class-name as described in [basic.scope.pdecl].
3
#
If the elaborated-type-specifier has a nested-name-specifier, qualified name lookup is performed, as described in [basic.lookup.qual], but ignoring any non-type names that have been declared.
If the name lookup does not find a previously declared type-name, the elaborated-type-specifier is ill-formed.
4
#
[Example 1: struct Node { struct Node* Next; // OK: Refers to injected-class-name Node struct Data* Data; // OK: Declares type Data at global scope and member Data }; struct Data { struct Node* Node; // OK: Refers to Node at global scope friend struct ::Glob; // error: Glob is not declared, cannot introduce a qualified type ([dcl.type.elab]) friend struct Glob; // OK: Refers to (as yet) undeclared Glob at global scope. /* ... */ }; struct Base { struct Data; // OK: Declares nested Data struct ::Data* thatData; // OK: Refers to ​::​Data struct Base::Data* thisData; // OK: Refers to nested Data friend class ::Data; // OK: global Data is a friend friend class Data; // OK: nested Data is a friend struct Data { /* ... */ }; // Defines nested Data }; struct Data; // OK: Redeclares Data at global scope struct ::Data; // error: cannot introduce a qualified type ([dcl.type.elab]) struct Base::Data; // error: cannot introduce a qualified type ([dcl.type.elab]) struct Base::Datum; // error: Datum undefined struct Base::Data* pBase; // OK: refers to nested Data — end example]

6.5.6 Class member access [basic.lookup.classref]

1
#
In a class member access expression, if the . or -> token is immediately followed by an identifier followed by a <, the identifier is looked up to determine whether the < is the beginning of a template argument list ([temp.names]) or a less-than operator.
The identifier is first looked up in the class of the object expression ([class.member.lookup]).
If the identifier is not found, it is then looked up in the context of the entire postfix-expression and shall name a template whose specializations are types.
2
#
If the id-expression in a class member access is an unqualified-id, and the type of the object expression is of a class type C, the unqualified-id is looked up in the scope of class C ([class.member.lookup]).
3
#
If the unqualified-id is ~type-name, the type-name is looked up in the context of the entire postfix-expression.
If the type T of the object expression is of a class type C, the type-name is also looked up in the scope of class C.
At least one of the lookups shall find a name that refers to cv T.
[Example 1: struct A { }; struct B { struct A { }; void f(::A* a); }; void B::f(::A* a) { a->~A(); // OK: lookup in *a finds the injected-class-name } — end example]
4
#
If the id-expression in a class member access is a qualified-id of the form class-name-or-namespace-name::... the class-name-or-namespace-name following the . or -> operator is first looked up in the class of the object expression ([class.member.lookup]) and the name, if found, is used.
Otherwise it is looked up in the context of the entire postfix-expression.
[Note 1:
See [basic.lookup.qual], which describes the lookup of a name before ​::​, which will only find a type or namespace name.
— end note]
5
#
If the qualified-id has the form ::class-name-or-namespace-name::... the class-name-or-namespace-name is looked up in global scope as a class-name or namespace-name.
6
#
If the nested-name-specifier contains a simple-template-id ([temp.names]), the names in its template-arguments are looked up in the context in which the entire postfix-expression occurs.
7
#
If the id-expression is a conversion-function-id, its conversion-type-id is first looked up in the class of the object expression ([class.member.lookup]) and the name, if found, is used.
Otherwise it is looked up in the context of the entire postfix-expression.
In each of these lookups, only names that denote types or templates whose specializations are types are considered.
[Example 2: struct A { }; namespace N { struct A { void g() { } template <class T> operator T(); }; } int main() { N::A a; a.operator A(); // calls N​::​A​::​operator N​::​A } — end example]

6.5.7 Using-directives and namespace aliases [basic.lookup.udir]

1
#
In a using-directive or namespace-alias-definition, during the lookup for a namespace-name or for a name in a nested-name-specifier only namespace names are considered.

6.7 Memory and objects [basic.memobj]

6.7.1 Memory model [intro.memory]

1
#
The fundamental storage unit in the C++ memory model is the byte.
A byte is at least large enough to contain any member of the execution character set ([lex.charset]) and the eight-bit code units of the Unicode30 UTF-8 encoding form and is composed of a contiguous sequence of bits,31 the number of which is implementation-defined.
The least significant bit is called the low-order bit; the most significant bit is called the high-order bit.
The memory available to a C++ program consists of one or more sequences of contiguous bytes.
Every byte has a unique address.
2
#
[Note 1:
The representation of types is described in [basic.types].
— end note]
3
#
A memory location is either an object of scalar type that is not a bit-field or a maximal sequence of adjacent bit-fields all having nonzero width.
[Note 2:
Various features of the language, such as references and virtual functions, might involve additional memory locations that are not accessible to programs but are managed by the implementation.
— end note]
Two or more threads of execution can access separate memory locations without interfering with each other.
4
#
[Note 3:
Thus a bit-field and an adjacent non-bit-field are in separate memory locations, and therefore can be concurrently updated by two threads of execution without interference.
The same applies to two bit-fields, if one is declared inside a nested struct declaration and the other is not, or if the two are separated by a zero-length bit-field declaration, or if they are separated by a non-bit-field declaration.
It is not safe to concurrently update two bit-fields in the same struct if all fields between them are also bit-fields of nonzero width.
— end note]
5
#
[Example 1:
A class declared as struct { char a; int b:5, c:11, :0, d:8; struct {int ee:8;} e; } contains four separate memory locations: The member a and bit-fields d and e.ee are each separate memory locations, and can be modified concurrently without interfering with each other.
The bit-fields b and c together constitute the fourth memory location.
The bit-fields b and c cannot be concurrently modified, but b and a, for example, can be.
— end example]
30)
Unicode® is a registered trademark of Unicode, Inc.
This information is given for the convenience of users of this document and does not constitute an endorsement by ISO or IEC of this product.
 ⮥
31)
The number of bits in a byte is reported by the macro CHAR_­BIT in the header <climits>.
 ⮥

6.7.2 Object model [intro.object]

1
#
The constructs in a C++ program create, destroy, refer to, access, and manipulate objects.
An object is created by a definition, by a new-expression ([expr.new]), by an operation that implicitly creates objects (see below), when implicitly changing the active member of a union, or when a temporary object is created ([conv.rval], [class.temporary]).
An object occupies a region of storage in its period of construction ([class.cdtor]), throughout its lifetime, and in its period of destruction ([class.cdtor]).
[Note 1:
A function is not an object, regardless of whether or not it occupies storage in the way that objects do.
— end note]
The properties of an object are determined when the object is created.
An object can have a name ([basic.pre]).
An object has a storage duration ([basic.stc]) which influences its lifetime ([basic.life]).
An object has a type ([basic.types]).
Some objects are polymorphic ([class.virtual]); the implementation generates information associated with each such object that makes it possible to determine that object's type during program execution.
For other objects, the interpretation of the values found therein is determined by the type of the expressions ([expr.compound]) used to access them.
2
#
Objects can contain other objects, called subobjects.
A subobject can be a member subobject ([class.mem]), a base class subobject ([class.derived]), or an array element.
An object that is not a subobject of any other object is called a complete object.
If an object is created in storage associated with a member subobject or array element e (which may or may not be within its lifetime), the created object is a subobject of e's containing object if:
  • (2.1)
    the lifetime of e's containing object has begun and not ended, and
  • (2.2)
    the storage for the new object exactly overlays the storage location associated with e, and
  • (2.3)
    the new object is of the same type as e (ignoring cv-qualification).
3
#
If a complete object is created ([expr.new]) in storage associated with another object e of type “array of N unsigned char” or of type “array of N std​::​byte” ([cstddef.syn]), that array provides storage for the created object if:
  • (3.1)
    the lifetime of e has begun and not ended, and
  • (3.2)
    the storage for the new object fits entirely within e, and
  • (3.3)
    there is no smaller array object that satisfies these constraints.
[Note 2:
If that portion of the array previously provided storage for another object, the lifetime of that object ends because its storage was reused ([basic.life]).
— end note]
[Example 1: 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) — end example]
4
#
An object a is nested within another object b if:
  • (4.1)
    a is a subobject of b, or
  • (4.2)
    b provides storage for a, or
  • (4.3)
    there exists an object c where a is nested within c, and c is nested within b.
5
#
For every object x, there is some object called the complete object of x, determined as follows:
  • (5.1)
    If x is a complete object, then the complete object of x is itself.
  • (5.2)
    Otherwise, the complete object of x is the complete object of the (unique) object that contains x.
6
#
If a complete object, a member subobject, or an array element is of class type, its type is considered the most derived class, to distinguish it from the class type of any base class subobject; an object of a most derived class type or of a non-class type is called a most derived object.
7
#
A potentially-overlapping subobject is either:
8
#
An object has nonzero size if it
  • (8.1)
    is not a potentially-overlapping subobject, or
  • (8.2)
    is not of class type, or
  • (8.3)
    is of a class type with virtual member functions or virtual base classes, or
  • (8.4)
    has subobjects of nonzero size or unnamed bit-fields of nonzero length.
Otherwise, if the object is a base class subobject of a standard-layout class type with no non-static data members, it has zero size.
Otherwise, the circumstances under which the object has zero size are implementation-defined.
Unless it is a bit-field, an object with nonzero size shall occupy one or more bytes of storage, including every byte that is occupied in full or in part by any of its subobjects.
An object of trivially copyable or standard-layout type ([basic.types]) shall occupy contiguous bytes of storage.
9
#
Unless an object is a bit-field or a subobject of zero size, the address of that object is the address of the first byte it occupies.
Two objects with overlapping lifetimes that are not bit-fields may have the same address if one is nested within the other, or if at least one is a subobject of zero size and they are of different types; otherwise, they have distinct addresses and occupy disjoint bytes of storage.32
[Example 2: static const char test1 = 'x'; static const char test2 = 'x'; const bool b = &test1 != &test2; // always true — end example]
The address of a non-bit-field subobject of zero size is the address of an unspecified byte of storage occupied by the complete object of that subobject.
10
#
Some operations are described as implicitly creating objects within a specified region of storage.
For each operation that is specified as implicitly creating objects, that operation implicitly creates and starts the lifetime of zero or more objects of implicit-lifetime types ([basic.types]) in its specified region of storage if doing so would result in the program having defined behavior.
If no such set of objects would give the program defined behavior, the behavior of the program is undefined.
If multiple such sets of objects would give the program defined behavior, it is unspecified which such set of objects is created.
[Note 3:
Such operations do not start the lifetimes of subobjects of such objects that are not themselves of implicit-lifetime types.
— end note]
11
#
Further, after implicitly creating objects within a specified region of storage, some operations are described as producing a pointer to a suitable created object.
These operations select one of the implicitly-created objects whose address is the address of the start of the region of storage, and produce a pointer value that points to that object, if that value would result in the program having defined behavior.
If no such pointer value would give the program defined behavior, the behavior of the program is undefined.
If multiple such pointer values would give the program defined behavior, it is unspecified which such pointer value is produced.
12
#
[Example 3: #include <cstdlib> struct X { int a, b; }; X *make_x() { // The call to std​::​malloc implicitly creates an object of type X // and its subobjects a and b, and returns a pointer to that X object // (or an object that is pointer-interconvertible ([basic.compound]) with it), // in order to give the subsequent class member access operations // defined behavior. X *p = (X*)std::malloc(sizeof(struct X)); p->a = 1; p->b = 2; return p; } — end example]
13
#
An operation that begins the lifetime of an array of char, unsigned char, or std​::​byte implicitly creates objects within the region of storage occupied by the array.
[Note 4:
The array object provides storage for these objects.
— end note]
Any implicit or explicit invocation of a function named operator new or operator new[] implicitly creates objects in the returned region of storage and returns a pointer to a suitable created object.
[Note 5:
Some functions in the C++ standard library implicitly create objects ([allocator.traits.members], [c.malloc], [cstring.syn], [bit.cast]).
— end note]
32)
Under the “as-if” rule an implementation is allowed to store two objects at the same machine address or not store an object at all if the program cannot observe the difference ([intro.execution]).
 ⮥

6.7.3 Lifetime [basic.life]

1
#
The lifetime of an object or reference is a runtime property of the object or reference.
A variable is said to have vacuous initialization if it is default-initialized and, if it is of class type or a (possibly multi-dimensional) array thereof, that class type has a trivial default constructor.
The lifetime of an object of type T begins when:
  • (1.1)
    storage with the proper alignment and size for type T is obtained, and
  • (1.2)
    its initialization (if any) is complete (including vacuous initialization) ([dcl.init]),
except that if the object is a union member or subobject thereof, its lifetime only begins if that union member is the initialized member in the union ([dcl.init.aggr], [class.base.init]), or as described in [class.union] and [class.copy.ctor], and except as described in [allocator.members].
The lifetime of an object o of type T ends when:
  • (1.3)
    if T is a non-class type, the object is destroyed, or
  • (1.4)
    if T is a class type, the destructor call starts, or
  • (1.5)
    the storage which the object occupies is released, or is reused by an object that is not nested within o ([intro.object]).
2
#
The lifetime of a reference begins when its initialization is complete.
The lifetime of a reference ends as if it were a scalar object requiring storage.
3
#
[Note 1:
[class.base.init] describes the lifetime of base and member subobjects.
— end note]
4
#
The properties ascribed to objects and references throughout this document apply for a given object or reference only during its lifetime.
[Note 2:
In particular, before the lifetime of an object starts and after its lifetime ends there are significant restrictions on the use of the object, as described below, in [class.base.init] and in [class.cdtor].
Also, the behavior of an object under construction and destruction might not be the same as the behavior of an object whose lifetime has started and not ended.
[class.base.init] and [class.cdtor] describe the behavior of an object during its periods of construction and destruction.
— end note]
5
#
A program may end the lifetime of any object by reusing the storage which the object occupies or by explicitly calling a destructor or pseudo-destructor ([expr.prim.id.dtor]) for the object.
For an object of a class type, the program is not required to call the destructor explicitly before the storage which the object occupies is reused or released; however, if there is no explicit call to the destructor or if a delete-expression ([expr.delete]) is not used to release the storage, the destructor is not implicitly called and any program that depends on the side effects produced by the destructor has undefined behavior.
6
#
Before the lifetime of an object has started but after the storage which the object will occupy has been allocated33 or, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, any pointer that represents the address of the storage location where the object will be or was located may be used but only in limited ways.
For an object under construction or destruction, see [class.cdtor].
Otherwise, such a pointer refers to allocated storage ([basic.stc.dynamic.allocation]), and using the pointer as if the pointer were of type void* is well-defined.
Indirection through such a pointer is permitted but the resulting lvalue may only be used in limited ways, as described below.
The program has undefined behavior if:
  • (6.1)
    the object will be or was of a class type with a non-trivial destructor and the pointer is used as the operand of a delete-expression,
  • (6.2)
    the pointer is used to access a non-static data member or call a non-static member function of the object, or
  • (6.3)
    the pointer is implicitly converted ([conv.ptr]) to a pointer to a virtual base class, or
  • (6.4)
    the pointer is used as the operand of a static_­cast ([expr.static.cast]), except when the conversion is to pointer to cv void, or to pointer to cv void and subsequently to pointer to cv char, cv unsigned char, or cv std​::​byte ([cstddef.syn]), or
  • (6.5)
    the pointer is used as the operand of a dynamic_­cast ([expr.dynamic.cast]).
[Example 1: #include <cstdlib> struct B { virtual void f(); void mutate(); virtual ~B(); }; struct D1 : B { void f(); }; struct D2 : B { void f(); }; void B::mutate() { new (this) D2; // reuses storage --- ends the lifetime of *this f(); // undefined behavior ... = this; // OK, this points to valid memory } void g() { void* p = std::malloc(sizeof(D1) + sizeof(D2)); B* pb = new (p) D1; pb->mutate(); *pb; // OK: pb points to valid memory void* q = pb; // OK: pb points to valid memory pb->f(); // undefined behavior: lifetime of *pb has ended } — end example]
7
#
Similarly, before the lifetime of an object has started but after the storage which the object will occupy has been allocated or, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, any glvalue that refers to the original object may be used but only in limited ways.
For an object under construction or destruction, see [class.cdtor].
Otherwise, such a glvalue refers to allocated storage ([basic.stc.dynamic.allocation]), and using the properties of the glvalue that do not depend on its value is well-defined.
The program has undefined behavior if:
  • (7.1)
    the glvalue is used to access the object, or
  • (7.2)
    the glvalue is used to call a non-static member function of the object, or
  • (7.3)
    the glvalue is bound to a reference to a virtual base class ([dcl.init.ref]), or
  • (7.4)
    the glvalue is used as the operand of a dynamic_­cast ([expr.dynamic.cast]) or as the operand of typeid.
8
#
If, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, a new object is created at the storage location which the original object occupied, a pointer that pointed to the original object, a reference that referred to the original object, or the name of the original object will automatically refer to the new object and, once the lifetime of the new object has started, can be used to manipulate the new object, if the original object is transparently replaceable (see below) by the new object.
An object is transparently replaceable by an object if:
  • (8.1)
    the storage that occupies exactly overlays the storage that occupied, and
  • (8.2)
    and are of the same type (ignoring the top-level cv-qualifiers), and
  • (8.3)
    is not a complete const object, and
  • (8.4)
    neither nor is a potentially-overlapping subobject ([intro.object]), and
  • (8.5)
    either and are both complete objects, or and are direct subobjects of objects and , respectively, and is transparently replaceable by .
[Example 2: struct C { int i; void f(); const C& operator=( const C& ); }; const C& C::operator=( const C& other) { if ( this != &other ) { this->~C(); // lifetime of *this ends new (this) C(other); // new object of type C created f(); // well-defined } return *this; } C c1; C c2; c1 = c2; // well-defined c1.f(); // well-defined; c1 refers to a new object of type C — end example]
[Note 3:
If these conditions are not met, a pointer to the new object can be obtained from a pointer that represents the address of its storage by calling std​::​launder ([ptr.launder]).
— end note]
9
#
If a program ends the lifetime of an object of type T with static ([basic.stc.static]), thread ([basic.stc.thread]), or automatic ([basic.stc.auto]) storage duration and if T has a non-trivial destructor,34 and another object of the original type does not occupy that same storage location when the implicit destructor call takes place, the behavior of the program is undefined.
This is true even if the block is exited with an exception.
[Example 3: class T { }; struct B { ~B(); }; void h() { B b; new (&b) T; } // undefined behavior at block exit — end example]
10
#
Creating a new object within the storage that a const complete object with static, thread, or automatic storage duration occupies, or within the storage that such a const object used to occupy before its lifetime ended, results in undefined behavior.
[Example 4: struct B { B(); ~B(); }; const B b; void h() { b.~B(); new (const_cast<B*>(&b)) const B; // undefined behavior } — end example]
11
#
In this subclause, “before” and “after” refer to the “happens before” relation ([intro.multithread]).
[Note 4:
Therefore, undefined behavior results if an object that is being constructed in one thread is referenced from another thread without adequate synchronization.
— end note]
33)
For example, before the construction of a global object that is initialized via a user-provided constructor ([class.cdtor]).
 ⮥
34)
That is, an object for which a destructor will be called implicitly—upon exit from the block for an object with automatic storage duration, upon exit from the thread for an object with thread storage duration, or upon exit from the program for an object with static storage duration.
 ⮥

6.7.4 Indeterminate values [basic.indet]

1
#
When storage for an object with automatic or dynamic storage duration is obtained, the object has an indeterminate value, and if no initialization is performed for the object, that object retains an indeterminate value until that value is replaced ([expr.ass]).
[Note 1:
Objects with static or thread storage duration are zero-initialized, see [basic.start.static].
— end note]
2
#
If an indeterminate value is produced by an evaluation, the behavior is undefined except in the following cases:
  • (2.1)
    If an indeterminate value of unsigned ordinary character type ([basic.fundamental]) or std​::​byte type ([cstddef.syn]) is produced by the evaluation of: then the result of the operation is an indeterminate value.
  • (2.2)
    If an indeterminate value of unsigned ordinary character type or std​::​byte type is produced by the evaluation of the right operand of a simple assignment operator ([expr.ass]) whose first operand is an lvalue of unsigned ordinary character type or std​::​byte type, an indeterminate value replaces the value of the object referred to by the left operand.
  • (2.3)
    If an indeterminate value of unsigned ordinary character type is produced by the evaluation of the initialization expression when initializing an object of unsigned ordinary character type, that object is initialized to an indeterminate value.
  • (2.4)
    If an indeterminate value of unsigned ordinary character type or std​::​byte type is produced by the evaluation of the initialization expression when initializing an object of std​::​byte type, that object is initialized to an indeterminate value.
[Example 1: int f(bool b) { unsigned char c; unsigned char d = c; // OK, d has an indeterminate value int e = d; // undefined behavior return b ? d : 0; // undefined behavior if b is true } — end example]

6.7.5 Storage duration [basic.stc]

6.7.5.1 General [basic.stc.general]

1
#
The storage duration is the property of an object that defines the minimum potential lifetime of the storage containing the object.
The storage duration is determined by the construct used to create the object and is one of the following:
  • (1.1)
    static storage duration
  • (1.2)
    thread storage duration
  • (1.3)
    automatic storage duration
  • (1.4)
    dynamic storage duration
2
#
Static, thread, and automatic storage durations are associated with objects introduced by declarations ([basic.def]) and implicitly created by the implementation.
The dynamic storage duration is associated with objects created by a new-expression ([expr.new]).
3
#
The storage duration categories apply to references as well.
4
#
When the end of the duration of a region of storage is reached, the values of all pointers representing the address of any part of that region of storage become invalid pointer values.
Indirection through an invalid pointer value and passing an invalid pointer value to a deallocation function have undefined behavior.
Any other use of an invalid pointer value has implementation-defined behavior.35
35)
Some implementations might define that copying an invalid pointer value causes a system-generated runtime fault.
 ⮥

6.7.5.2 Static storage duration [basic.stc.static]

1
#
All variables which do not have dynamic storage duration, do not have thread storage duration, and are not local have static storage duration.
The storage for these entities lasts for the duration of the program ([basic.start.static], [basic.start.term]).
2
#
If a variable with static storage duration has initialization or a destructor with side effects, it shall not be eliminated even if it appears to be unused, except that a class object or its copy/move may be eliminated as specified in [class.copy.elision].
3
#
The keyword static can be used to declare a local variable with static storage duration.
[Note 1:
[stmt.dcl] describes the initialization of local static variables; [basic.start.term] describes the destruction of local static variables.
— end note]
4
#
The keyword static applied to a class data member in a class definition gives the data member static storage duration.

6.7.5.3 Thread storage duration [basic.stc.thread]

1
#
All variables declared with the thread_­local keyword have thread storage duration.
The storage for these entities lasts for the duration of the thread in which they are created.
There is a distinct object or reference per thread, and use of the declared name refers to the entity associated with the current thread.
2
#
[Note 1:
A variable with thread storage duration is initialized as specified in [basic.start.static], [basic.start.dynamic], and [stmt.dcl] and, if constructed, is destroyed on thread exit ([basic.start.term]).
— end note]

6.7.5.4 Automatic storage duration [basic.stc.auto]

1
#
Block-scope variables not explicitly declared static, thread_­local, or extern have automatic storage duration.
The storage for these entities lasts until the block in which they are created exits.
2
#
[Note 1:
These variables are initialized and destroyed as described in [stmt.dcl].
— end note]
3
#
If a variable with automatic storage duration has initialization or a destructor with side effects, an implementation shall not destroy it before the end of its block nor eliminate it as an optimization, even if it appears to be unused, except that a class object or its copy/move may be eliminated as specified in [class.copy.elision].

6.7.5.5 Dynamic storage duration [basic.stc.dynamic]

6.7.5.5.1 General [basic.stc.dynamic.general]

1
#
Objects can be created dynamically during program execution, using new-expressions ([expr.new]), and destroyed using delete-expressions ([expr.delete]).
A C++ implementation provides access to, and management of, dynamic storage via the global allocation functions operator new and operator new[] and the global deallocation functions operator delete and operator delete[].
[Note 1:
The non-allocating forms described in [new.delete.placement] do not perform allocation or deallocation.
— end note]
2
#
The library provides default definitions for the global allocation and deallocation functions.
Some global allocation and deallocation functions are replaceable ([new.delete]).
A C++ program shall provide at most one definition of a replaceable allocation or deallocation function.
Any such function definition replaces the default version provided in the library ([replacement.functions]).
The following allocation and deallocation functions ([support.dynamic]) are implicitly declared in global scope in each translation unit of a program.
[[nodiscard]] void* operator new(std::size_t); [[nodiscard]] void* operator new(std::size_t, std::align_val_t); void operator delete(void*) noexcept; void operator delete(void*, std::size_t) noexcept; void operator delete(void*, std::align_val_t) noexcept; void operator delete(void*, std::size_t, std::align_val_t) noexcept; [[nodiscard]] void* operator new[](std::size_t); [[nodiscard]] void* operator new[](std::size_t, std::align_val_t); void operator delete[](void*) noexcept; void operator delete[](void*, std::size_t) noexcept; void operator delete[](void*, std::align_val_t) noexcept; void operator delete[](void*, std::size_t, std::align_val_t) noexcept;
These implicit declarations introduce only the function names operator new, operator new[], operator delete, and operator delete[].
[Note 2:
The implicit declarations do not introduce the names std, std​::​size_­t, std​::​align_­val_­t, or any other names that the library uses to declare these names.
Thus, a new-expression, delete-expression, or function call that refers to one of these functions without importing or including the header <new> is well-formed.
However, referring to std or std​::​size_­t or std​::​align_­val_­t is ill-formed unless the name has been declared by importing or including the appropriate header.
— end note]
Allocation and/or deallocation functions may also be declared and defined for any class ([class.free]).
3
#
If the behavior of an allocation or deallocation function does not satisfy the semantic constraints specified in [basic.stc.dynamic.allocation] and [basic.stc.dynamic.deallocation], the behavior is undefined.

6.7.5.5.2 Allocation functions [basic.stc.dynamic.allocation]

1
#
An allocation function shall be a class member function or a global function; a program is ill-formed if an allocation function is declared in a namespace scope other than global scope or declared static in global scope.
The return type shall be void*.
The first parameter shall have type std​::​size_­t ([support.types]).
The first parameter shall not have an associated default argument ([dcl.fct.default]).
The value of the first parameter is interpreted as the requested size of the allocation.
An allocation function can be a function template.
Such a template shall declare its return type and first parameter as specified above (that is, template parameter types shall not be used in the return type and first parameter type).
Template allocation functions shall have two or more parameters.
2
#
An allocation function attempts to allocate the requested amount of storage.
If it is successful, it returns the address of the start of a block of storage whose length in bytes is at least as large as the requested size.
The order, contiguity, and initial value of storage allocated by successive calls to an allocation function are unspecified.
Even if the size of the space requested is zero, the request can fail.
If the request succeeds, the value returned by a replaceable allocation function is a non-null pointer value ([basic.compound]) p0 different from any previously returned value p1, unless that value p1 was subsequently passed to a replaceable deallocation function.
Furthermore, for the library allocation functions in [new.delete.single] and [new.delete.array], p0 represents the address of a block of storage disjoint from the storage for any other object accessible to the caller.
The effect of indirecting through a pointer returned from a request for zero size is undefined.36
3
#
For an allocation function other than a reserved placement allocation function ([new.delete.placement]), the pointer returned on a successful call shall represent the address of storage that is aligned as follows:
  • (3.1)
    If the allocation function takes an argument of type std​::​align_­val_­t, the storage will have the alignment specified by the value of this argument.
  • (3.2)
    Otherwise, if the allocation function is named operator new[], the storage is aligned for any object that does not have new-extended alignment ([basic.align]) and is no larger than the requested size.
  • (3.3)
    Otherwise, the storage is aligned for any object that does not have new-extended alignment and is of the requested size.
4
#
An allocation function that fails to allocate storage can invoke the currently installed new-handler function ([new.handler]), if any.
[Note 1:
A program-supplied allocation function can obtain the address of the currently installed new_­handler using the std​::​get_­new_­handler function ([get.new.handler]).
— end note]
An allocation function that has a non-throwing exception specification ([except.spec]) indicates failure by returning a null pointer value.
Any other allocation function never returns a null pointer value and indicates failure only by throwing an exception ([except.throw]) of a type that would match a handler ([except.handle]) of type std​::​bad_­alloc ([bad.alloc]).
5
#
A global allocation function is only called as the result of a new expression, or called directly using the function call syntax, or called indirectly to allocate storage for a coroutine state ([dcl.fct.def.coroutine]), or called indirectly through calls to the functions in the C++ standard library.
[Note 2:
In particular, a global allocation function is not called to allocate storage for objects with static storage duration, for objects or references with thread storage duration, for objects of type std​::​type_­info, or for an exception object.
— end note]
36)
The intent is to have operator new() implementable by calling std​::​malloc() or std​::​calloc(), so the rules are substantially the same.
C++ differs from C in requiring a zero request to return a non-null pointer.
 ⮥

6.7.5.5.3 Deallocation functions [basic.stc.dynamic.deallocation]

1
#
Deallocation functions shall be class member functions or global functions; a program is ill-formed if deallocation functions are declared in a namespace scope other than global scope or declared static in global scope.
2
#
A deallocation function is a destroying operator delete if it has at least two parameters and its second parameter is of type std​::​destroying_­delete_­t.
A destroying operator delete shall be a class member function named operator delete.
[Note 1:
Array deletion cannot use a destroying operator delete.
— end note]
3
#
Each deallocation function shall return void.
If the function is a destroying operator delete declared in class type C, the type of its first parameter shall be C*; otherwise, the type of its first parameter shall be void*.
A deallocation function may have more than one parameter.
A usual deallocation function is a deallocation function whose parameters after the first are
  • (3.1)
    optionally, a parameter of type std​::​destroying_­delete_­t, then
  • (3.2)
    optionally, a parameter of type std​::​size_­t37, then
  • (3.3)
    optionally, a parameter of type std​::​align_­val_­t.
A destroying operator delete shall be a usual deallocation function.
A deallocation function may be an instance of a function template.
Neither the first parameter nor the return type shall depend on a template parameter.
A deallocation function template shall have two or more function parameters.
A template instance is never a usual deallocation function, regardless of its signature.
4
#
If a deallocation function terminates by throwing an exception, the behavior is undefined.
The value of the first argument supplied to a deallocation function may be a null pointer value; if so, and if the deallocation function is one supplied in the standard library, the call has no effect.
5
#
If the argument given to a deallocation function in the standard library is a pointer that is not the null pointer value ([basic.compound]), the deallocation function shall deallocate the storage referenced by the pointer, ending the duration of the region of storage.
37)
The global operator delete(void*, std​::​size_­t) precludes use of an allocation function void operator new(std​::​size_­t, std​::​size_­t) as a placement allocation function ([diff.cpp11.basic]).
 ⮥

6.7.5.5.4 Safely-derived pointers [basic.stc.dynamic.safety]

1
#
A traceable pointer object is
  • (1.1)
    an object of an object pointer type, or
  • (1.2)
    an object of an integral type that is at least as large as std​::​intptr_­t, or
  • (1.3)
    a sequence of elements in an array of narrow character type, where the size and alignment of the sequence match those of some object pointer type.
2
#
A pointer value is a safely-derived pointer to an object with dynamic storage duration only if the pointer value has an object pointer type and is one of the following:
  • (2.1)
    the value returned by a call to the C++ standard library implementation of ​::​operator new(std​::​​size_­t) or ​::​operator new(std​::​size_­t, std​::​align_­val_­t);38
  • (2.2)
    the result of taking the address of an object (or one of its subobjects) designated by an lvalue resulting from indirection through a safely-derived pointer value;
  • (2.3)
    the result of well-defined pointer arithmetic ([expr.add]) using a safely-derived pointer value;
  • (2.4)
    the result of a well-defined pointer conversion ([conv.ptr], [expr.type.conv], [expr.static.cast], [expr.cast]) of a safely-derived pointer value;
  • (2.5)
    the result of a reinterpret_­cast of a safely-derived pointer value;
  • (2.6)
    the result of a reinterpret_­cast of an integer representation of a safely-derived pointer value;
  • (2.7)
    the value of an object whose value was copied from a traceable pointer object, where at the time of the copy the source object contained a copy of a safely-derived pointer value.
3
#
An integer value is an integer representation of a safely-derived pointer only if its type is at least as large as std​::​intptr_­t and it is one of the following:
  • (3.1)
    the result of a reinterpret_­cast of a safely-derived pointer value;
  • (3.2)
    the result of a valid conversion of an integer representation of a safely-derived pointer value;
  • (3.3)
    the value of an object whose value was copied from a traceable pointer object, where at the time of the copy the source object contained an integer representation of a safely-derived pointer value;
  • (3.4)
    the result of an additive or bitwise operation, one of whose operands is an integer representation of a safely-derived pointer value P, if that result converted by reinterpret_­cast<void*> would compare equal to a safely-derived pointer computable from reinterpret_­cast<void*>(P).
4
#
An implementation may have relaxed pointer safety, in which case the validity of a pointer value does not depend on whether it is a safely-derived pointer value.
Alternatively, an implementation may have strict pointer safety, in which case a pointer value referring to an object with dynamic storage duration that is not a safely-derived pointer value is an invalid pointer value unless the referenced complete object has previously been declared reachable ([util.dynamic.safety]).
[Note 1:
The effect of using an invalid pointer value (including passing it to a deallocation function) is undefined, see [basic.stc].
This is true even if the unsafely-derived pointer value might compare equal to some safely-derived pointer value.
— end note]
It is implementation-defined whether an implementation has relaxed or strict pointer safety.
38)
This subclause does not impose restrictions on indirection through pointers to memory not allocated by ​::​operator new.
This maintains the ability of many C++ implementations to use binary libraries and components written in other languages.
In particular, this applies to C binaries, because indirection through pointers to memory allocated by std​::​malloc is not restricted.
 ⮥

6.7.5.6 Duration of subobjects [basic.stc.inherit]

1
#
The storage duration of subobjects and reference members is that of their complete object ([intro.object]).

6.7.6 Alignment [basic.align]

1
#
Object types have alignment requirements ([basic.fundamental], [basic.compound]) which place restrictions on the addresses at which an object of that type may be allocated.
An alignment is an implementation-defined integer value representing the number of bytes between successive addresses at which a given object can be allocated.
An object type imposes an alignment requirement on every object of that type; stricter alignment can be requested using the alignment specifier.
2
#
A fundamental alignment is represented by an alignment less than or equal to the greatest alignment supported by the implementation in all contexts, which is equal to alignof(std​::​max_­align_­t) ([support.types]).
The alignment required for a type may be different when it is used as the type of a complete object and when it is used as the type of a subobject.
[Example 1: struct B { long double d; }; struct D : virtual B { char c; };
When D is the type of a complete object, it will have a subobject of type B, so it must be aligned appropriately for a long double.
If D appears as a subobject of another object that also has B as a virtual base class, the B subobject might be part of a different subobject, reducing the alignment requirements on the D subobject.
— end example]
The result of the alignof operator reflects the alignment requirement of the type in the complete-object case.
3
#
An extended alignment is represented by an alignment greater than alignof(std​::​max_­align_­t).
It is implementation-defined whether any extended alignments are supported and the contexts in which they are supported ([dcl.align]).
A type having an extended alignment requirement is an over-aligned type.
[Note 1:
Every over-aligned type is or contains a class type to which extended alignment applies (possibly through a non-static data member).
— end note]
A new-extended alignment is represented by an alignment greater than __STDCPP_­DEFAULT_­NEW_­ALIGNMENT__ ([cpp.predefined]).
4
#
Alignments are represented as values of the type std​::​size_­t.
Valid alignments include only those values returned by an alignof expression for the fundamental types plus an additional implementation-defined set of values, which may be empty.
Every alignment value shall be a non-negative integral power of two.
5
#
Alignments have an order from weaker to stronger or stricter alignments.
Stricter alignments have larger alignment values.
An address that satisfies an alignment requirement also satisfies any weaker valid alignment requirement.
6
#
The alignment requirement of a complete type can be queried using an alignof expression.
Furthermore, the narrow character types shall have the weakest alignment requirement.
[Note 2:
This enables the ordinary character types to be used as the underlying type for an aligned memory area ([dcl.align]).
— end note]
7
#
Comparing alignments is meaningful and provides the obvious results:
  • (7.1)
    Two alignments are equal when their numeric values are equal.
  • (7.2)
    Two alignments are different when their numeric values are not equal.
  • (7.3)
    When an alignment is larger than another it represents a stricter alignment.
8
#
[Note 3:
The runtime pointer alignment function ([ptr.align]) can be used to obtain an aligned pointer within a buffer; the aligned-storage templates in the library ([meta.trans.other]) can be used to obtain aligned storage.
— end note]
9
#
If a request for a specific extended alignment in a specific context is not supported by an implementation, the program is ill-formed.

6.7.7 Temporary objects [class.temporary]

1
#
Temporary objects are created
  • (1.1)
    when a prvalue is converted to an xvalue ([conv.rval]),
  • (1.2)
    when needed by the implementation to pass or return an object of trivially copyable type (see below), and
  • (1.3)
    when throwing an exception ([except.throw]).
    [Note 1:
    The lifetime of exception objects is described in [except.throw].
    — end note]
Even when the creation of the temporary object is unevaluated ([expr.prop]), all the semantic restrictions shall be respected as if the temporary object had been created and later destroyed.
[Note 2:
This includes accessibility ([class.access]) and whether it is deleted, for the constructor selected and for the destructor.
However, in the special case of the operand of a decltype-specifier ([dcl.type.decltype]), no temporary is introduced, so the foregoing does not apply to such a prvalue.
— end note]
2
#
The materialization of a temporary object is generally delayed as long as possible in order to avoid creating unnecessary temporary objects.
[Note 3:
Temporary objects are materialized:
— end note]
[Example 1:
Consider the following code: class X { public: X(int); X(const X&); X& operator=(const X&); ~X(); }; class Y { public: Y(int); Y(Y&&); ~Y(); }; X f(X); Y g(Y); void h() { X a(1); X b = f(X(2)); Y c = g(Y(3)); a = f(a); }
X(2) is constructed in the space used to hold f()'s argument and Y(3) is constructed in the space used to hold g()'s argument.
Likewise, f()'s result is constructed directly in b and g()'s result is constructed directly in c.
On the other hand, the expression a = f(a) requires a temporary for the result of f(a), which is materialized so that the reference parameter of X​::​operator=(const X&) can bind to it.
— end example]
3
#
When an object of class type X is passed to or returned from a function, if X has at least one eligible copy or move constructor ([special]), each such constructor is trivial, and the destructor of X is either trivial or deleted, implementations are permitted to create a temporary object to hold the function parameter or result object.
The temporary object is constructed from the function argument or return value, respectively, and the function's parameter or return object is initialized as if by using the eligible trivial constructor to copy the temporary (even if that constructor is inaccessible or would not be selected by overload resolution to perform a copy or move of the object).
[Note 4:
This latitude is granted to allow objects of class type to be passed to or returned from functions in registers.
— end note]
4
#
When an implementation introduces a temporary object of a class that has a non-trivial constructor ([class.default.ctor], [class.copy.ctor]), it shall ensure that a constructor is called for the temporary object.
Similarly, the destructor shall be called for a temporary with a non-trivial destructor ([class.dtor]).
Temporary objects are destroyed as the last step in evaluating the full-expression ([intro.execution]) that (lexically) contains the point where they were created.
This is true even if that evaluation ends in throwing an exception.
The value computations and side effects of destroying a temporary object are associated only with the full-expression, not with any specific subexpression.
5
#
There are three contexts in which temporaries are destroyed at a different point than the end of the full-expression.
The first context is when a default constructor is called to initialize an element of an array with no corresponding initializer ([dcl.init]).
The second context is when a copy constructor is called to copy an element of an array while the entire array is copied ([expr.prim.lambda.capture], [class.copy.ctor]).
In either case, if the constructor has one or more default arguments, the destruction of every temporary created in a default argument is sequenced before the construction of the next array element, if any.
6
#
The third context is when a reference is bound to a temporary object.39
The temporary object to which the reference is bound or the temporary object that is the complete object of a subobject to which the reference is bound persists for the lifetime of the reference if the glvalue to which the reference is bound was obtained through one of the following:
  • (6.1)
    a temporary materialization conversion ([conv.rval]),
  • (6.2)
    ( expression ), where expression is one of these expressions,
  • (6.3)
    subscripting ([expr.sub]) of an array operand, where that operand is one of these expressions,
  • (6.4)
    a class member access ([expr.ref]) using the . operator where the left operand is one of these expressions and the right operand designates a non-static data member of non-reference type,
  • (6.5)
    a pointer-to-member operation ([expr.mptr.oper]) using the .* operator where the left operand is one of these expressions and the right operand is a pointer to data member of non-reference type,
  • (6.6)
    a converting, without a user-defined conversion, a glvalue operand that is one of these expressions to a glvalue that refers to the object designated by the operand, or to its complete object or a subobject thereof,
  • (6.7)
    a conditional expression ([expr.cond]) that is a glvalue where the second or third operand is one of these expressions, or
  • (6.8)
    a comma expression ([expr.comma]) that is a glvalue where the right operand is one of these expressions.
[Example 2: template<typename T> using id = T; int i = 1; int&& a = id<int[3]>{1, 2, 3}[i]; // temporary array has same lifetime as a const int& b = static_cast<const int&>(0); // temporary int has same lifetime as b int&& c = cond ? id<int[3]>{1, 2, 3}[i] : static_cast<int&&>(0); // exactly one of the two temporaries is lifetime-extended — end example]
[Note 5:
An explicit type conversion ([expr.type.conv], [expr.cast]) is interpreted as a sequence of elementary casts, covered above.
[Example 3: const int& x = (const int&)1; // temporary for value 1 has same lifetime as x — end example]
— end note]
[Note 6:
If a temporary object has a reference member initialized by another temporary object, lifetime extension applies recursively to such a member's initializer.
[Example 4: struct S { const int& m; }; const S& s = S{1}; // both S and int temporaries have lifetime of s — end example]
— end note]
The exceptions to this lifetime rule are:
  • (6.9)
    A temporary object bound to a reference parameter in a function call ([expr.call]) persists until the completion of the full-expression containing the call.
  • (6.10)
    A temporary object bound to a reference element of an aggregate of class type initialized from a parenthesized expression-list ([dcl.init]) persists until the completion of the full-expression containing the expression-list.
  • (6.11)
    The lifetime of a temporary bound to the returned value in a function return statement ([stmt.return]) is not extended; the temporary is destroyed at the end of the full-expression in the return statement.
  • (6.12)
    A temporary bound to a reference in a new-initializer ([expr.new]) persists until the completion of the full-expression containing the new-initializer.
    [Note 7:
    This might introduce a dangling reference.
    — end note]
    [Example 5: struct S { int mi; const std::pair<int,int>& mp; }; S a { 1, {2,3} }; S* p = new S{ 1, {2,3} }; // creates dangling reference — end example]
7
#
The destruction of a temporary whose lifetime is not extended by being bound to a reference is sequenced before the destruction of every temporary which is constructed earlier in the same full-expression.
If the lifetime of two or more temporaries to which references are bound ends at the same point, these temporaries are destroyed at that point in the reverse order of the completion of their construction.
In addition, the destruction of temporaries bound to references shall take into account the ordering of destruction of objects with static, thread, or automatic storage duration ([basic.stc.static], [basic.stc.thread], [basic.stc.auto]); that is, if obj1 is an object with the same storage duration as the temporary and created before the temporary is created the temporary shall be destroyed before obj1 is destroyed; if obj2 is an object with the same storage duration as the temporary and created after the temporary is created the temporary shall be destroyed after obj2 is destroyed.
8
#
[Example 6: struct S { S(); S(int); friend S operator+(const S&, const S&); ~S(); }; S obj1; const S& cr = S(16)+S(23); S obj2;
The expression S(16) + S(23) creates three temporaries: a first temporary T1 to hold the result of the expression S(16), a second temporary T2 to hold the result of the expression S(23), and a third temporary T3 to hold the result of the addition of these two expressions.
The temporary T3 is then bound to the reference cr.
It is unspecified whether T1 or T2 is created first.
On an implementation where T1 is created before T2, T2 shall be destroyed before T1.
The temporaries T1 and T2 are bound to the reference parameters of operator+; these temporaries are destroyed at the end of the full-expression containing the call to operator+.
The temporary T3 bound to the reference cr is destroyed at the end of cr's lifetime, that is, at the end of the program.
In addition, the order in which T3 is destroyed takes into account the destruction order of other objects with static storage duration.
That is, because obj1 is constructed before T3, and T3 is constructed before obj2, obj2 shall be destroyed before T3, and T3 shall be destroyed before obj1.
— end example]
39)
The same rules apply to initialization of an initializer_­list object ([dcl.init.list]) with its underlying temporary array.
 ⮥

6.8 Types [basic.types]

6.8.1 General [basic.types.general]

1
#
[Note 1:
[basic.types] and the subclauses thereof impose requirements on implementations regarding the representation of types.
There are two kinds of types: fundamental types and compound types.
Types describe objects, references, or functions.
— end note]
2
#
For any object (other than a potentially-overlapping subobject) of trivially copyable type T, whether or not the object holds a valid value of type T, the underlying bytes ([intro.memory]) making up the object can be copied into an array of char, unsigned char, or std​::​byte ([cstddef.syn]).40
If the content of that array is copied back into the object, the object shall subsequently hold its original value.
[Example 1: constexpr std::size_t N = sizeof(T); char buf[N]; T obj; // obj initialized to its original value std::memcpy(buf, &obj, N); // between these two calls to std​::​memcpy, obj might be modified std::memcpy(&obj, buf, N); // at this point, each subobject of obj of scalar type holds its original value — end example]
3
#
For any trivially copyable type T, if two pointers to T point to distinct T objects obj1 and obj2, where neither obj1 nor obj2 is a potentially-overlapping subobject, if the underlying bytes ([intro.memory]) making up obj1 are copied into obj2,41 obj2 shall subsequently hold the same value as obj1.
[Example 2: T* t1p; T* t2p; // provided that t2p points to an initialized object ... std::memcpy(t1p, t2p, sizeof(T)); // at this point, every subobject of trivially copyable type in *t1p contains // the same value as the corresponding subobject in *t2p — end example]
4
#
The object representation of an object of type T is the sequence of N unsigned char objects taken up by the object of type T, where N equals sizeof(T).
The value representation of an object of type T is the set of bits that participate in representing a value of type T.
Bits in the object representation that are not part of the value representation are padding bits.
For trivially copyable types, the value representation is a set of bits in the object representation that determines a value, which is one discrete element of an implementation-defined set of values.42
5
#
A class that has been declared but not defined, an enumeration type in certain contexts ([dcl.enum]), or an array of unknown bound or of incomplete element type, is an incompletely-defined object type.43
Incompletely-defined object types and cv void are incomplete types ([basic.fundamental]).
[Note 2:
Objects cannot be defined to have an incomplete type ([basic.def]).
— end note]
6
#
A class type (such as “class X”) can be incomplete at one point in a translation unit and complete later on; the type “class X” is the same type at both points.
The declared type of an array object can be an array of incomplete class type and therefore incomplete; if the class type is completed later on in the translation unit, the array type becomes complete; the array type at those two points is the same type.
The declared type of an array object can be an array of unknown bound and therefore be incomplete at one point in a translation unit and complete later on; the array types at those two points (“array of unknown bound of T” and “array of N T”) are different types.
The type of a pointer to array of unknown bound, or of a type defined by a typedef declaration to be an array of unknown bound, cannot be completed.
[Example 3: class X; // X is an incomplete type extern X* xp; // xp is a pointer to an incomplete type extern int arr[]; // the type of arr is incomplete typedef int UNKA[]; // UNKA is an incomplete type UNKA* arrp; // arrp is a pointer to an incomplete type UNKA** arrpp; void foo() { xp++; // error: X is incomplete arrp++; // error: incomplete type arrpp++; // OK: sizeof UNKA* is known } struct X { int i; }; // now X is a complete type int arr[10]; // now the type of arr is complete X x; void bar() { xp = &x; // OK; type is “pointer to X” arrp = &arr; // error: different types xp++; // OK: X is complete arrp++; // error: UNKA can't be completed } — end example]
7
#
[Note 3:
The rules for declarations and expressions describe in which contexts incomplete types are prohibited.
— end note]
8
#
An object type is a (possibly cv-qualified) type that is not a function type, not a reference type, and not cv void.
9
#
Arithmetic types ([basic.fundamental]), enumeration types, pointer types, pointer-to-member types ([basic.compound]), std​::​nullptr_­t, and cv-qualified versions of these types are collectively called scalar types.
Scalar types, trivially copyable class types ([class.prop]), arrays of such types, and cv-qualified versions of these types are collectively called trivially copyable types.
Scalar types, trivial class types ([class.prop]), arrays of such types and cv-qualified versions of these types are collectively called trivial types.
Scalar types, standard-layout class types ([class.prop]), arrays of such types and cv-qualified versions of these types are collectively called standard-layout types.
Scalar types, implicit-lifetime class types ([class.prop]), array types, and cv-qualified versions of these types are collectively called implicit-lifetime types.
10
#
A type is a literal type if it is:
  • (10.1)
    cv void; or
  • (10.2)
    a scalar type; or
  • (10.3)
    a reference type; or
  • (10.4)
    an array of literal type; or
  • (10.5)
    a possibly cv-qualified class type that has all of the following properties:
    • (10.5.1)
      it has a constexpr destructor ([dcl.constexpr]),
    • (10.5.2)
      it is either a closure type ([expr.prim.lambda.closure]), an aggregate type ([dcl.init.aggr]), or has at least one constexpr constructor or constructor template (possibly inherited from a base class) that is not a copy or move constructor,
    • (10.5.3)
      if it is a union, at least one of its non-static data members is of non-volatile literal type, and
    • (10.5.4)
      if it is not a union, all of its non-static data members and base classes are of non-volatile literal types.
[Note 4:
A literal type is one for which it might be possible to create an object within a constant expression.
It is not a guarantee that it is possible to create such an object, nor is it a guarantee that any object of that type will be usable in a constant expression.
— end note]
11
#
Two types cv1 T1 and cv2 T2 are layout-compatible types if T1 and T2 are the same type, layout-compatible enumerations, or layout-compatible standard-layout class types.
40)
By using, for example, the library functions ([headers]) std​::​memcpy or std​::​memmove.
 ⮥
41)
By using, for example, the library functions ([headers]) std​::​memcpy or std​::​memmove.
 ⮥
42)
The intent is that the memory model of C++ is compatible with that of ISO/IEC 9899 Programming Language C.
 ⮥
43)
The size and layout of an instance of an incompletely-defined object type is unknown.
 ⮥

6.8.2 Fundamental types [basic.fundamental]

1
#
There are five standard signed integer types: “signed char”, “short int”, “int”, “long int”, and “long long int”.
In this list, each type provides at least as much storage as those preceding it in the list.
There may also be implementation-defined extended signed integer types.
The standard and extended signed integer types are collectively called signed integer types.
The range of representable values for a signed integer type is to (inclusive), where N is called the width of the type.
[Note 1:
Plain ints are intended to have the natural width suggested by the architecture of the execution environment; the other signed integer types are provided to meet special needs.
— end note]
2
#
For each of the standard signed integer types, there exists a corresponding (but different) standard unsigned integer type: “unsigned char”, “unsigned short int”, “unsigned int”, “unsigned long int”, and “unsigned long long int”.
Likewise, for each of the extended signed integer types, there exists a corresponding extended unsigned integer type.
The standard and extended unsigned integer types are collectively called unsigned integer types.
An unsigned integer type has the same width N as the corresponding signed integer type.
The range of representable values for the unsigned type is 0 to (inclusive); arithmetic for the unsigned type is performed modulo .
[Note 2:
Unsigned arithmetic does not overflow.
Overflow for signed arithmetic yields undefined behavior ([expr.pre]).
— end note]
3
#
An unsigned integer type has the same object representation, value representation, and alignment requirements ([basic.align]) as the corresponding signed integer type.
For each value x of a signed integer type, the value of the corresponding unsigned integer type congruent to x modulo has the same value of corresponding bits in its value representation.44
[Example 1:
The value of a signed integer type has the same representation as the largest value of the corresponding unsigned type.
— end example]
Table 12: Minimum width [tab:basic.fundamental.width]
Type
Minimum width N
signed char
8
short int
16
int
16
long int
32
long long int
64
4
#
The width of each signed integer type shall not be less than the values specified in Table 12.
The value representation of a signed or unsigned integer type comprises N bits, where N is the respective width.
Each set of values for any padding bits ([basic.types]) in the object representation are alternative representations of the value specified by the value representation.
[Note 3:
Padding bits have unspecified value, but cannot cause traps.
In contrast, see ISO C 6.2.6.2.
— end note]
[Note 4:
The signed and unsigned integer types satisfy the constraints given in ISO C 5.2.4.2.1.
— end note]
Except as specified above, the width of a signed or unsigned integer type is implementation-defined.
5
#
Each value x of an unsigned integer type with width N has a unique representation , where each coefficient is either 0 or 1; this is called the base-2 representation of x.
The base-2 representation of a value of signed integer type is the base-2 representation of the congruent value of the corresponding unsigned integer type.
The standard signed integer types and standard unsigned integer types are collectively called the standard integer types, and the extended signed integer types and extended unsigned integer types are collectively called the extended integer types.
6
#
A fundamental type specified to have a signed or unsigned integer type as its underlying type has the same object representation, value representation, alignment requirements ([basic.align]), and range of representable values as the underlying type.
Further, each value has the same representation in both types.
7
#
Type char is a distinct type that has an implementation-defined choice of “signed char” or “unsigned char” as its underlying type.
The values of type char can represent distinct codes for all members of the implementation's basic character set.
The three types char, signed char, and unsigned char are collectively called ordinary character types.
The ordinary character types and char8_­t are collectively called narrow character types.
For narrow character types, each possible bit pattern of the object representation represents a distinct value.
[Note 5:
This requirement does not hold for other types.
— end note]
[Note 6:
A bit-field of narrow character type whose width is larger than the width of that type has padding bits; see [basic.types].
— end note]
8
#
Type wchar_­t is a distinct type that has an implementation-defined signed or unsigned integer type as its underlying type.
The values of type wchar_­t can represent distinct codes for all members of the largest extended character set specified among the supported locales ([locale]).
9
#
Type char8_­t denotes a distinct type whose underlying type is unsigned char.
Types char16_­t and char32_­t denote distinct types whose underlying types are uint_­least16_­t and uint_­least32_­t, respectively, in <cstdint>.
10
#
Type bool is a distinct type that has the same object representation, value representation, and alignment requirements as an implementation-defined unsigned integer type.
The values of type bool are true and false.
[Note 7:
There are no signed, unsigned, short, or long bool types or values.
— end note]
11
#
Types bool, char, wchar_­t, char8_­t, char16_­t, char32_­t, and the signed and unsigned integer types are collectively called integral types.
A synonym for integral type is integer type.
[Note 8:
Enumerations ([dcl.enum]) are not integral; however, unscoped enumerations can be promoted to integral types as specified in [conv.prom].
— end note]
12
#
There are three floating-point types: float, double, and long double.
The type double provides at least as much precision as float, and the type long double provides at least as much precision as double.
The set of values of the type float is a subset of the set of values of the type double; the set of values of the type double is a subset of the set of values of the type long double.
The value representation of floating-point types is implementation-defined.
[Note 9:
This document imposes no requirements on the accuracy of floating-point operations; see also [support.limits].
— end note]
Integral and floating-point types are collectively called arithmetic types.
Specializations of the standard library template std​::​numeric_­limits shall specify the maximum and minimum values of each arithmetic type for an implementation.
13
#
A type cv void is an incomplete type that cannot be completed; such a type has an empty set of values.
It is used as the return type for functions that do not return a value.
Any expression can be explicitly converted to type cv void ([expr.type.conv], [expr.static.cast], [expr.cast]).
An expression of type cv void shall be used only as an expression statement, as an operand of a comma expression, as a second or third operand of ?: ([expr.cond]), as the operand of typeid, noexcept, or decltype, as the expression in a return statement for a function with the return type cv void, or as the operand of an explicit conversion to type cv void.
14
#
A value of type std​::​nullptr_­t is a null pointer constant.
Such values participate in the pointer and the pointer-to-member conversions ([conv.ptr], [conv.mem]).
sizeof(std​::​nullptr_­t) shall be equal to sizeof(void*).
15
#
The types described in this subclause are called fundamental types.
[Note 10:
Even if the implementation defines two or more fundamental types to have the same value representation, they are nevertheless different types.
— end note]
44)
This is also known as two's complement representation.
 ⮥

6.8.3 Compound types [basic.compound]

1
#
Compound types can be constructed in the following ways:
2
#
These methods of constructing types can be applied recursively; restrictions are mentioned in [dcl.meaning].
Constructing a type such that the number of bytes in its object representation exceeds the maximum value representable in the type std​::​size_­t ([support.types]) is ill-formed.
3
#
The type of a pointer to cv void or a pointer to an object type is called an object pointer type.
[Note 1:
A pointer to void does not have a pointer-to-object type, however, because void is not an object type.
— end note]
The type of a pointer that can designate a function is called a function pointer type.
A pointer to an object of type T is referred to as a “pointer to T”.
[Example 1:
A pointer to an object of type int is referred to as “pointer to int” and a pointer to an object of class X is called a “pointer to X”.
— end example]
Except for pointers to static members, text referring to “pointers” does not apply to pointers to members.
Pointers to incomplete types are allowed although there are restrictions on what can be done with them ([basic.align]).
Every value of pointer type is one of the following:
A value of a pointer type that is a pointer to or past the end of an object represents the address of the first byte in memory ([intro.memory]) occupied by the object46 or the first byte in memory after the end of the storage occupied by the object, respectively.
[Note 2:
A pointer past the end of an object ([expr.add]) is not considered to point to an unrelated object of the object's type that might be located at that address.
A pointer value becomes invalid when the storage it denotes reaches the end of its storage duration; see [basic.stc].
— end note]
For purposes of pointer arithmetic ([expr.add]) and comparison ([expr.rel], [expr.eq]), a pointer past the end of the last element of an array x of n elements is considered to be equivalent to a pointer to a hypothetical array element n of x and an object of type T that is not an array element is considered to belong to an array with one element of type T.
The value representation of pointer types is implementation-defined.
Pointers to layout-compatible types shall have the same value representation and alignment requirements ([basic.align]).
[Note 3:
Pointers to over-aligned types have no special representation, but their range of valid values is restricted by the extended alignment requirement.
— end note]
4
#
Two objects a and b are pointer-interconvertible if:
  • (4.1)
    they are the same object, or
  • (4.2)
    one is a union object and the other is a non-static data member of that object ([class.union]), or
  • (4.3)
    one is a standard-layout class object and the other is the first non-static data member of that object, or, if the object has no non-static data members, any base class subobject of that object ([class.mem]), or
  • (4.4)
    there exists an object c such that a and c are pointer-interconvertible, and c and b are pointer-interconvertible.
If two objects are pointer-interconvertible, then they have the same address, and it is possible to obtain a pointer to one from a pointer to the other via a reinterpret_­cast.
[Note 4:
An array object and its first element are not pointer-interconvertible, even though they have the same address.
— end note]
5
#
A pointer to cv void can be used to point to objects of unknown type.
Such a pointer shall be able to hold any object pointer.
An object of type cv void* shall have the same representation and alignment requirements as cv char*.
45)
Static class members are objects or functions, and pointers to them are ordinary pointers to objects or functions.
 ⮥
46)
For an object that is not within its lifetime, this is the first byte in memory that it will occupy or used to occupy.
 ⮥

6.8.4 CV-qualifiers [basic.type.qualifier]

1
#
Each type which is a cv-unqualified object type or is void ([basic.types]) has three corresponding cv-qualified versions of its type: a const-qualified version, a volatile-qualified version, and a const-volatile-qualified version.
The type of an object ([intro.object]) includes the cv-qualifiers specified in the decl-specifier-seq ([dcl.spec]), declarator ([dcl.decl]), type-id ([dcl.name]), or new-type-id ([expr.new]) when the object is created.
  • (1.1)
    A const object is an object of type const T or a non-mutable subobject of a const object.
  • (1.2)
    A volatile object is an object of type volatile T or a subobject of a volatile object.
  • (1.3)
    A const volatile object is an object of type const volatile T, a non-mutable subobject of a const volatile object, a const subobject of a volatile object, or a non-mutable volatile subobject of a const object.
The cv-qualified or cv-unqualified versions of a type are distinct types; however, they shall have the same representation and alignment requirements ([basic.align]).47
2
#
Except for array types, a compound type ([basic.compound]) is not cv-qualified by the cv-qualifiers (if any) of the types from which it is compounded.
3
#
An array type whose elements are cv-qualified is also considered to have the same cv-qualifications as its elements.
[Note 1:
Cv-qualifiers applied to an array type attach to the underlying element type, so the notation “cv T”, where T is an array type, refers to an array whose elements are so-qualified ([dcl.array]).
— end note]
[Example 1: typedef char CA[5]; typedef const char CC; CC arr1[5] = { 0 }; const CA arr2 = { 0 };
The type of both arr1 and arr2 is “array of 5 const char”, and the array type is considered to be const-qualified.
— end example]
4
#
[Note 2:
See [dcl.fct] and [class.this] regarding function types that have cv-qualifiers.
— end note]
5
#
There is a partial ordering on cv-qualifiers, so that a type can be said to be more cv-qualified than another.
Table 13 shows the relations that constitute this ordering.
Table 13: Relations on const and volatile [tab:basic.type.qualifier.rel]
no cv-qualifier
<
const
no cv-qualifier
<
volatile
no cv-qualifier
<
const volatile
const
<
const volatile
volatile
<
const volatile
6
#
In this document, the notation cv (or cv1, cv2, etc.)
, used in the description of types, represents an arbitrary set of cv-qualifiers, i.e., one of {const}, {volatile}, {const, volatile}, or the empty set.
For a type cv T, the top-level cv-qualifiers of that type are those denoted by cv.
[Example 2:
The type corresponding to the type-id const int& has no top-level cv-qualifiers.
The type corresponding to the type-id volatile int * const has the top-level cv-qualifier const.
For a class type C, the type corresponding to the type-id void (C​::​* volatile)(int) const has the top-level cv-qualifier volatile.
— end example]
47)
The same representation and alignment requirements are meant to imply interchangeability as arguments to functions, return values from functions, and non-static data members of unions.
 ⮥

6.8.5 Integer conversion rank [conv.rank]

1
#
Every integer type has an integer conversion rank defined as follows:
  • (1.1)
    No two signed integer types other than char and signed char (if char is signed) shall have the same rank, even if they have the same representation.
  • (1.2)
    The rank of a signed integer type shall be greater than the rank of any signed integer type with a smaller width.
  • (1.3)
    The rank of long long int shall be greater than the rank of long int, which shall be greater than the rank of int, which shall be greater than the rank of short int, which shall be greater than the rank of signed char.
  • (1.4)
    The rank of any unsigned integer type shall equal the rank of the corresponding signed integer type.
  • (1.5)
    The rank of any standard integer type shall be greater than the rank of any extended integer type with the same width.
  • (1.6)
    The rank of char shall equal the rank of signed char and unsigned char.
  • (1.7)
    The rank of bool shall be less than the rank of all other standard integer types.
  • (1.8)
    The ranks of char8_­t, char16_­t, char32_­t, and wchar_­t shall equal the ranks of their underlying types ([basic.fundamental]).
  • (1.9)
    The rank of any extended signed integer type relative to another extended signed integer type with the same width is implementation-defined, but still subject to the other rules for determining the integer conversion rank.
  • (1.10)
    For all integer types T1, T2, and T3, if T1 has greater rank than T2 and T2 has greater rank than T3, then T1 shall have greater rank than T3.
[Note 1:
The integer conversion rank is used in the definition of the integral promotions ([conv.prom]) and the usual arithmetic conversions ([expr.arith.conv]).
— end note]

6.9 Program execution [basic.exec]

6.9.1 Sequential execution [intro.execution]

1
#
An instance of each object with automatic storage duration 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).
2
#
A constituent expression is defined as follows:
[Example 1: 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]
3
#
The immediate subexpressions of an expression E are
4
#
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]
5
#
A full-expression is
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: 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 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)); }; B b[2] = { B(), B() }; // full-expression is the entire initialization // including the destruction of temporaries — end example]
6
#
[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]
7
#
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.
8
#
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.
9
#
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.48
10
#
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: 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]
11
#
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.49
[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, regardless of the syntax of the expression that calls the function.
12
#
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]
48)
As specified in [class.temporary], after a full-expression is evaluated, a sequence of zero or more invocations of destructor functions for temporary objects takes place, usually in reverse order of the construction of each temporary object.
 ⮥
49)
In other words, function executions do not interleave with each other.
 ⮥

6.9.2 Multi-threaded executions and data races [intro.multithread]

6.9.2.1 General [intro.multithread.general]

1
#
A thread of execution (also known as a thread) is a single flow of control within a program, including the initial invocation of a specific top-level function, and recursively including every function invocation subsequently executed by the thread.
[Note 1:
When one thread creates another, the initial call to the top-level function of the new thread is executed by the new thread, not by the creating thread.
— end note]
Every thread in a program can potentially access every object and function in a program.50
Under a hosted implementation, a C++ program can have more than one thread running concurrently.
The execution of each thread proceeds as defined by the remainder of this document.
The execution of the entire program consists of an execution of all of its threads.
[Note 2:
Usually the 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.
— end note]
Under a freestanding implementation, it is implementation-defined whether a program can have more than one thread of execution.
2
#
For a signal handler that is not executed as a result of a call to the std​::​raise function, it is unspecified which thread of execution contains the signal handler invocation.
50)
An object with automatic or thread storage duration ([basic.stc]) is associated with one specific thread, and can be accessed by a different thread only indirectly through a pointer or reference ([basic.compound]).
 ⮥

6.9.2.2 Data races [intro.races]

1
#
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.
[Note 1:
In some cases, there might instead be undefined behavior.
Much of this subclause is motivated by the desire to support atomic operations with explicit and detailed visibility constraints.
However, it also implicitly supports a simpler view for more restricted programs.
— end note]
2
#
Two expression evaluations conflict if one of them modifies a memory location ([intro.memory]) and the other one reads or modifies the same memory location.
3
#
The library defines a number of atomic operations ([atomics]) and operations on mutexes ([thread]) that are specially identified as synchronization operations.
These operations play a special role in making assignments in one thread visible to another.
A synchronization operation on one or more memory locations is either a consume operation, an acquire operation, a release operation, or both an acquire and release operation.
A synchronization operation without an associated memory location is a fence and can be either an acquire fence, a release fence, or both an acquire and release fence.
In addition, there are relaxed atomic operations, which are not synchronization operations, and atomic read-modify-write operations, which have special characteristics.
[Note 2:
For example, a call that acquires a mutex will perform an acquire operation on the locations comprising the mutex.
Correspondingly, a call that releases the same mutex will perform a release operation on those same locations.
Informally, performing a release operation on A forces prior side effects on other memory locations to become visible to other threads that later perform a consume or an acquire operation on A.
“Relaxed” atomic operations are not synchronization operations even though, like synchronization operations, they cannot contribute to data races.
— end note]
4
#
All modifications to a particular atomic object M occur in some particular total order, called the modification order of M.
[Note 3:
There is a separate order for each atomic object.
There is no requirement that these can be combined into a single total order for all objects.
In general this will be impossible since different threads might observe modifications to different objects in inconsistent orders.
— end note]
5
#
A release sequence headed by a release operation A on an atomic object M is a maximal contiguous sub-sequence of side effects in the modification order of M, where the first operation is A, and every subsequent operation is an atomic read-modify-write operation.
6
#
Certain library calls synchronize with other library calls performed by another thread.
For example, an atomic store-release synchronizes with a load-acquire that takes its value from the store ([atomics.order]).
[Note 4:
Except in the specified cases, reading a later value does not necessarily ensure visibility as described below.
Such a requirement would sometimes interfere with efficient implementation.
— end note]
[Note 5:
The specifications of the synchronization operations define when one reads the value written by another.
For atomic objects, the definition is clear.
All operations on a given mutex occur in a single total order.
Each mutex acquisition “reads the value written” by the last mutex release.
— end note]
7
#
An evaluation A carries a dependency to an evaluation B if
  • (7.1)
    the value of A is used as an operand of B, unless: or
  • (7.2)
    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
  • (7.3)
    for some evaluation X, A carries a dependency to X, and X carries a dependency to B.
[Note 6:
“Carries a dependency to” is a subset of “is sequenced before”, and is similarly strictly intra-thread.
— end note]
8
#
An evaluation A is dependency-ordered before an evaluation B if
  • (8.1)
    A performs a release operation on an atomic object M, and, in another thread, B performs a consume operation on M and reads the value written by A, or
  • (8.2)
    for some evaluation X, A is dependency-ordered before X and X carries a dependency to B.
[Note 7:
The relation “is dependency-ordered before” is analogous to “synchronizes with”, but uses release/consume in place of release/acquire.
— end note]
9
#
An evaluation A inter-thread happens before an evaluation B if
  • (9.1)
    A synchronizes with B, or
  • (9.2)
    A is dependency-ordered before B, or
  • (9.3)
    for some evaluation X
    • (9.3.1)
      A synchronizes with X and X is sequenced before B, or
    • (9.3.2)
      A is sequenced before X and X inter-thread happens before B, or
    • (9.3.3)
      A inter-thread happens before X and X inter-thread happens before B.
[Note 8:
The “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”.
— end note]
10
#
An evaluation A happens before an evaluation B (or, equivalently, B happens after A) if:
  • (10.1)
    A is sequenced before B, or
  • (10.2)
    A inter-thread happens before B.
The implementation shall ensure that no program execution demonstrates a cycle in the “happens before” relation.
[Note 9:
This cycle would otherwise be possible only through the use of consume operations.
— end note]
11
#
An evaluation A simply happens before an evaluation B if either
  • (11.1)
    A is sequenced before B, or
  • (11.2)
    A synchronizes with B, or
  • (11.3)
    A simply happens before X and X simply happens before B.
[Note 10:
In the absence of consume operations, the happens before and simply happens before relations are identical.
— end note]
12
#
An evaluation A strongly happens before an evaluation D if, either
  • (12.1)
    A is sequenced before D, or
  • (12.2)
    A synchronizes with D, and both A and D are sequentially consistent atomic operations ([atomics.order]), or
  • (12.3)
    there are evaluations B and C such that A is sequenced before B, B simply happens before C, and C is sequenced before D, or
  • (12.4)
    there is an evaluation B such that A strongly happens before B, and B strongly happens before D.
[Note 11:
Informally, if A strongly happens before B, then A appears to be evaluated before B in all contexts.
Strongly happens before excludes consume operations.
— end note]
13
#
A visible side effect A on a scalar object or bit-field M with respect to a value computation B of M satisfies the conditions:
  • (13.1)
    A happens before B and
  • (13.2)
    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.
[Note 12:
If 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.
— end note]
[Note 13:
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.
— end note]
14
#
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.
[Note 14:
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.
— end note]
15
#
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.
[Note 15:
This requirement is known as write-write coherence.
— end note]
16
#
If a value computation A of an atomic object M happens before a value computation B of M, and A takes its value from a side effect X on M, then the value computed by B shall either be the value stored by X or the value stored by a side effect Y on M, where Y follows X in the modification order of M.
[Note 16:
This requirement is known as read-read coherence.
— end note]
17
#
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.
[Note 17:
This requirement is known as read-write coherence.
— end note]
18
#
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.
[Note 18:
This requirement is known as write-read coherence.
— end note]
19
#
[Note 19:
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.
— end note]
20
#
[Note 20:
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.
— end note]
21
#
Two actions are potentially concurrent if
  • (21.1)
    they are performed by different threads, or
  • (21.2)
    they are unsequenced, at least one is performed by a signal handler, and they are not both performed by the same signal handler invocation.
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.
[Note 21:
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 “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 has undefined behavior.
— end note]
22
#
Two accesses to the same object of type volatile std​::​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 std​::​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.
23
#
[Note 22:
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 document, 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 might alias is also generally precluded, since this could violate the coherence rules.
— end note]
24
#
[Note 23:
Transformations that introduce a speculative read of a potentially shared memory location might not preserve the semantics of the C++ program as defined in this document, since they potentially introduce a data race.
However, they are typically valid in the context of an optimizing compiler that targets a specific machine with well-defined semantics for data races.
They would be invalid for a hypothetical machine that is not tolerant of races or provides hardware race detection.
— end note]

6.9.2.3 Forward progress [intro.progress]

1
#
The implementation may assume that any thread will eventually do one of the following:
  • (1.1)
    terminate,
  • (1.2)
    make a call to a library I/O function,
  • (1.3)
    perform an access through a volatile glvalue, or
  • (1.4)
    perform a synchronization operation or an atomic operation.
[Note 1:
This is intended to allow compiler transformations such as removal of empty loops, even when termination cannot be proven.
— end note]
2
#
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.
  • (2.1)
    If there is only one thread that is not blocked ([defns.block]) in a standard library function, a lock-free execution in that thread shall complete.
    [Note 2:
    Concurrently executing threads might 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.
    — end note]
  • (2.2)
    When one or more lock-free executions run concurrently, at least one should complete.
    [Note 3:
    It is difficult for some implementations to provide absolute guarantees to this effect, since repeated and particularly inopportune interference from other threads could prevent forward progress, e.g., by repeatedly stealing a cache line for unrelated purposes between load-locked and store-conditional instructions.
    For implementations that follow this recommendation and ensure that such effects cannot indefinitely delay progress under expected operating conditions, such anomalies can therefore safely be ignored by programmers.
    Outside this document, this property is sometimes termed lock-free.
    — end note]
3
#
During the execution of a thread of execution, each of the following is termed an execution step:
  • (3.1)
    termination of the thread of execution,
  • (3.2)
    performing an access through a volatile glvalue, or
  • (3.3)
    completion of a call to a library I/O function, a synchronization operation, or an atomic operation.
4
#
An invocation of a standard library function that blocks ([defns.block]) is considered to continuously execute execution steps while waiting for the condition that it blocks on to be satisfied.
[Example 1:
A library I/O function that blocks until the I/O operation is complete can be considered to continuously check whether the operation is complete.
Each such check might consist of one or more execution steps, for example using observable behavior of the abstract machine.
— end example]
5
#
[Note 4:
Because of this and the preceding requirement regarding what threads of execution have to perform eventually, it follows that no thread of execution can execute forever without an execution step occurring.
— end note]
6
#
A thread of execution makes progress when an execution step occurs or a lock-free execution does not complete because there are other concurrent threads that are not blocked in a standard library function (see above).
7
#
For a thread of execution providing concurrent forward progress guarantees, the implementation ensures that the thread will eventually make progress for as long as it has not terminated.
[Note 5:
This is required regardless of whether or not other threads of executions (if any) have been or are making progress.
To eventually fulfill this requirement means that this will happen in an unspecified but finite amount of time.
— end note]
8
#
It is implementation-defined whether the implementation-created thread of execution that executes main ([basic.start.main]) and the threads of execution created by std​::​thread ([thread.thread.class]) or std​::​jthread ([thread.jthread.class]) provide concurrent forward progress guarantees.
General-purpose implementations should provide these guarantees.
9
#
For a thread of execution providing parallel forward progress guarantees, the implementation is not required to ensure that the thread will eventually make progress if it has not yet executed any execution step; once this thread has executed a step, it provides concurrent forward progress guarantees.
10
#
[Note 6:
This does not specify a requirement for when to start this thread of execution, which will typically be specified by the entity that creates this thread of execution.
For example, a thread of execution that provides concurrent forward progress guarantees and executes tasks from a set of tasks in an arbitrary order, one after the other, satisfies the requirements of parallel forward progress for these tasks.
— end note]
11
#
For a thread of execution providing weakly parallel forward progress guarantees, the implementation does not ensure that the thread will eventually make progress.
12
#
[Note 7:
Threads of execution providing weakly parallel forward progress guarantees cannot be expected to make progress regardless of whether other threads make progress or not; however, blocking with forward progress guarantee delegation, as defined below, can be used to ensure that such threads of execution make progress eventually.
— end note]
13
#
Concurrent forward progress guarantees are stronger than parallel forward progress guarantees, which in turn are stronger than weakly parallel forward progress guarantees.
[Note 8:
For example, some kinds of synchronization between threads of execution might only make progress if the respective threads of execution provide parallel forward progress guarantees, but will fail to make progress under weakly parallel guarantees.
— end note]
14
#
When a thread of execution P is specified to block with forward progress guarantee delegation on the completion of a set S of threads of execution, then throughout the whole time of P being blocked on S, the implementation shall ensure that the forward progress guarantees provided by at least one thread of execution in S is at least as strong as P's forward progress guarantees.
[Note 9:
It is unspecified which thread or threads of execution in S are chosen and for which number of execution steps.
The strengthening is not permanent and not necessarily in place for the rest of the lifetime of the affected thread of execution.
As long as P is blocked, the implementation has to eventually select and potentially strengthen a thread of execution in S.
— end note]
Once a thread of execution in S terminates, it is removed from S.
Once S is empty, P is unblocked.
15
#
[Note 10:
A thread of execution B thus can temporarily provide an effectively stronger forward progress guarantee for a certain amount of time, due to a second thread of execution A being blocked on it with forward progress guarantee delegation.
In turn, if B then blocks with forward progress guarantee delegation on C, this could also temporarily provide a stronger forward progress guarantee to C.
— end note]
16
#
[Note 11:
If all threads of execution in S finish executing (e.g., they terminate and do not use blocking synchronization incorrectly), then P's execution of the operation that blocks with forward progress guarantee delegation will not result in P's progress guarantee being effectively weakened.
— end note]
17
#
[Note 12:
This does not remove any constraints regarding blocking synchronization for threads of execution providing parallel or weakly parallel forward progress guarantees because the implementation is not required to strengthen a particular thread of execution whose too-weak progress guarantee is preventing overall progress.
— end note]
18
#
An implementation should ensure that the last value (in modification order) assigned by an atomic or synchronization operation will become visible to all other threads in a finite period of time.

6.9.3 Start and termination [basic.start]

6.9.3.1 main function [basic.start.main]

1
#
A program shall contain a global function called main attached to the global module.
Executing a program starts a main thread of execution ([intro.multithread], [thread.threads]) in which the main function is invoked.
It is implementation-defined whether a program in a freestanding environment is required to define a main function.
[Note 1:
In a freestanding environment, startup and termination is implementation-defined; startup contains the execution of constructors for objects of namespace scope with static storage duration; termination contains the execution of destructors for objects with static storage duration.
— end note]
2
#
An implementation shall not predefine the main function.
This function shall not be overloaded.
Its type shall have C++ language linkage and it shall have a declared return type of type int, but otherwise its type is implementation-defined.
An implementation shall allow both
  • (2.1)
    a function of () returning int and
  • (2.2)
    a function of (int, pointer to pointer to char) returning int
as the type of main ([dcl.fct]).
In the latter form, for purposes of exposition, the first function parameter is called argc and the second function parameter is called argv, where argc shall be the number of arguments passed to the program from the environment in which the program is run.
If argc is nonzero these arguments shall be supplied in argv[0] through argv[argc-1] as pointers to the initial characters of null-terminated multibyte strings (ntmbss) ([multibyte.strings]) and argv[0] shall be the pointer to the initial character of a ntmbs that represents the name used to invoke the program or "".
The value of argc shall be non-negative.
The value of argv[argc] shall be 0.
[Note 2:
It is recommended that any further (optional) parameters be added after argv.
— end note]
3
#
The function main shall not be used within a program.
The linkage ([basic.link]) of main is implementation-defined.
A program that defines main as deleted or that declares main to be inline, static, or constexpr is ill-formed.
The function main shall not be a coroutine ([dcl.fct.def.coroutine]).
The main function shall not be declared with a linkage-specification ([dcl.link]).
A program that declares a variable main at global scope, or that declares a function main at global scope attached to a named module, or that declares the name main with C language linkage (in any namespace) is ill-formed.
The name main is not otherwise reserved.
[Example 1:
Member functions, classes, and enumerations can be called main, as can entities in other namespaces.
— end example]
4
#
Terminating the program without leaving the current block (e.g., by calling the function std​::​exit(int) ([support.start.term])) does not destroy any objects with automatic storage duration ([class.dtor]).
If std​::​exit is called to end a program during the destruction of an object with static or thread storage duration, the program has undefined behavior.
5
#
A return statement ([stmt.return]) in main has the effect of leaving the main function (destroying any objects with automatic storage duration) and calling std​::​exit with the return value as the argument.
If control flows off the end of the compound-statement of main, the effect is equivalent to a return with operand 0 (see also [except.handle]).

6.9.3.2 Static initialization [basic.start.static]

1
#
Variables with static storage duration are initialized as a consequence of program initiation.
Variables with thread storage duration are initialized as a consequence of thread execution.
Within each of these phases of initiation, initialization occurs as follows.
2
#
Constant initialization is performed if a variable or temporary object with static or thread storage duration is constant-initialized ([expr.const]).
If constant initialization is not performed, a variable with static storage duration ([basic.stc.static]) or thread storage duration ([basic.stc.thread]) is zero-initialized ([dcl.init]).
Together, zero-initialization and constant initialization are called static initialization; all other initialization is dynamic initialization.
All static initialization strongly happens before ([intro.races]) any dynamic initialization.
[Note 1:
The dynamic initialization of non-local variables is described in [basic.start.dynamic]; that of local static variables is described in [stmt.dcl].
— end note]
3
#
An implementation is permitted to perform the initialization of a variable with static or thread storage duration as a static initialization even if such initialization is not required to be done statically, provided that
  • (3.1)
    the dynamic version of the initialization does not change the value of any other object of static or thread storage duration prior to its initialization, and
  • (3.2)
    the static version of the initialization produces the same value in the initialized variable as would be produced by the dynamic initialization if all variables not required to be initialized statically were initialized dynamically.
[Note 2:
As a consequence, if the initialization of an object obj1 refers to an object obj2 of namespace scope potentially requiring dynamic initialization and defined later in the same translation unit, it is unspecified whether the value of obj2 used will be the value of the fully initialized obj2 (because obj2 was statically initialized) or will be the value of obj2 merely zero-initialized.
For example, inline double fd() { return 1.0; } extern double d1; double d2 = d1; // unspecified: // either statically initialized to 0.0 or // dynamically initialized to 0.0 if d1 is // dynamically initialized, or 1.0 otherwise double d1 = fd(); // either initialized statically or dynamically to 1.0
— end note]

6.9.3.3 Dynamic initialization of non-local variables [basic.start.dynamic]

1
#
Dynamic initialization of a non-local variable with static storage duration is unordered if the variable is an implicitly or explicitly instantiated specialization, is partially-ordered if the variable is an inline variable that is not an implicitly or explicitly instantiated specialization, and otherwise is ordered.
[Note 1:
An explicitly specialized non-inline static data member or variable template specialization has ordered initialization.
— end note]
2
#
A declaration D is appearance-ordered before a declaration E if
  • (2.1)
    D appears in the same translation unit as E, or
  • (2.2)
    the translation unit containing E has an interface dependency on the translation unit containing D,
in either case prior to E.
3
#
Dynamic initialization of non-local variables V and W with static storage duration are ordered as follows:
  • (3.1)
    If V and W have ordered initialization and the definition of V is appearance-ordered before the definition of W, or if V has partially-ordered initialization, W does not have unordered initialization, and for every definition E of W there exists a definition D of V such that D is appearance-ordered before E, then
    • (3.1.1)
      if the program does not start a thread ([intro.multithread]) other than the main thread ([basic.start.main]) or V and W have ordered initialization and they are defined in the same translation unit, the initialization of V is sequenced before the initialization of W;
    • (3.1.2)
      otherwise, the initialization of V strongly happens before the initialization of W.
  • (3.2)
    Otherwise, if the program starts a thread other than the main thread before either V or W is initialized, it is unspecified in which threads the initializations of V and W occur; the initializations are unsequenced if they occur in the same thread.
  • (3.3)
    Otherwise, the initializations of V and W are indeterminately sequenced.
[Note 2:
This definition permits initialization of a sequence of ordered variables concurrently with another sequence.
— end note]
4
#
A non-initialization odr-use is an odr-use ([basic.def.odr]) not caused directly or indirectly by the initialization of a non-local static or thread storage duration variable.
5
#
It is implementation-defined whether the dynamic initialization of a non-local non-inline variable with static storage duration is sequenced before the first statement of main or is deferred.
If it is deferred, it strongly happens before any non-initialization odr-use of any non-inline function or non-inline variable defined in the same translation unit as the variable to be initialized.51
It is implementation-defined in which threads and at which points in the program such deferred dynamic initialization occurs.
Recommended practice: An implementation should choose such points in a way that allows the programmer to avoid deadlocks.
[Example 1: // - File 1 - #include "a.h" #include "b.h" B b; A::A(){ b.Use(); } // - File 2 - #include "a.h" A a; // - File 3 - #include "a.h" #include "b.h" extern A a; extern B b; int main() { a.Use(); b.Use(); }
It is implementation-defined whether either a or b is initialized before main is entered or whether the initializations are delayed until a is first odr-used in main.
In particular, if a is initialized before main is entered, it is not guaranteed that b will be initialized before it is odr-used by the initialization of a, that is, before A​::​A is called.
If, however, a is initialized at some point after the first statement of main, b will be initialized prior to its use in A​::​A.
— end example]
6
#
It is implementation-defined whether the dynamic initialization of a non-local inline variable with static storage duration is sequenced before the first statement of main or is deferred.
If it is deferred, it strongly happens before any non-initialization odr-use of that variable.
It is implementation-defined in which threads and at which points in the program such deferred dynamic initialization occurs.
7
#
It is implementation-defined whether the dynamic initialization of a non-local non-inline variable with thread storage duration is sequenced before the first statement of the initial function of a thread or is deferred.
If it is deferred, the initialization associated with the entity for thread t is sequenced before the first non-initialization odr-use by t of any non-inline variable with thread storage duration defined in the same translation unit as the variable to be initialized.
It is implementation-defined in which threads and at which points in the program such deferred dynamic initialization occurs.
8
#
If the initialization of a non-local variable with static or thread storage duration exits via an exception, the function std​::​terminate is called ([except.terminate]).
51)
A non-local variable with static storage duration having initialization with side effects is initialized in this case, even if it is not itself odr-used ([basic.def.odr], [basic.stc.static]).
 ⮥

6.9.3.4 Termination [basic.start.term]

1
#
Constructed objects ([dcl.init]) with static storage duration are destroyed and functions registered with std​::​atexit are called as part of a call to std​::​exit ([support.start.term]).
The call to std​::​exit is sequenced before the destructions and the registered functions.
[Note 1:
Returning from main invokes std​::​exit ([basic.start.main]).
— end note]
2
#
Constructed objects with thread storage duration within a given thread are destroyed as a result of returning from the initial function of that thread and as a result of that thread calling std​::​exit.
The destruction of all constructed objects with thread storage duration within that thread strongly happens before destroying any object with static storage duration.
3
#
If the completion of the constructor or dynamic initialization of an object with static storage duration strongly happens before that of another, the completion of the destructor of the second is sequenced before the initiation of the destructor of the first.
If the completion of the constructor or dynamic initialization of an object with thread storage duration is sequenced before that of another, the completion of the destructor of the second is sequenced before the initiation of the destructor of the first.
If an object is initialized statically, the object is destroyed in the same order as if the object was dynamically initialized.
For an object of array or class type, all subobjects of that object are destroyed before any block-scope object with static storage duration initialized during the construction of the subobjects is destroyed.
If the destruction of an object with static or thread storage duration exits via an exception, the function std​::​terminate is called ([except.terminate]).
4
#
If a function contains a block-scope object of static or thread storage duration that has been destroyed and the function is called during the destruction of an object with static or thread storage duration, the program has undefined behavior if the flow of control passes through the definition of the previously destroyed block-scope object.
Likewise, the behavior is undefined if the block-scope object is used indirectly (i.e., through a pointer) after its destruction.
5
#
If the completion of the initialization of an object with static storage duration strongly happens before a call to std​::​atexit (see <cstdlib>, [support.start.term]), the call to the function passed to std​::​atexit is sequenced before the call to the destructor for the object.
If a call to std​::​atexit strongly happens before the completion of the initialization of an object with static storage duration, the call to the destructor for the object is sequenced before the call to the function passed to std​::​atexit.
If a call to std​::​atexit strongly happens before another call to std​::​atexit, the call to the function passed to the second std​::​atexit call is sequenced before the call to the function passed to the first std​::​atexit call.
6
#
If there is a use of a standard library object or function not permitted within signal handlers ([support.runtime]) that does not happen before ([intro.multithread]) completion of destruction of objects with static storage duration and execution of std​::​atexit registered functions ([support.start.term]), the program has undefined behavior.
[Note 2:
If there is a use of an object with static storage duration that does not happen before the object's destruction, the program has undefined behavior.
Terminating every thread before a call to std​::​exit or the exit from main is sufficient, but not necessary, to satisfy these requirements.
These requirements permit thread managers as static-storage-duration objects.
— end note]
7
#
Calling the function std​::​abort() declared in <cstdlib> terminates the program without executing any destructors and without calling the functions passed to std​::​atexit() or std​::​at_­quick_­exit().