basic.tex

%!TEX root = std.tex
\rSec0[basic]{Basics}

\gramSec[gram.basic]{Basics}

\rSec1[basic.pre]{Preamble}

\pnum
\begin{note}
This Clause presents the basic concepts of the \Cpp{} 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 \Cpp{}'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}

\pnum
\begin{note}
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}

\pnum
\indextext{type}%
\indextext{object}%
\indextext{storage class}%
\indextext{scope}%
\indextext{linkage}%
\indextext{region!declarative}%
An \defn{entity} is a value, object, reference,
structured binding,
function, enumerator, type,
class member, bit-field, template, template specialization, namespace, or
pack.

\pnum
A \defn{name} is a use of an \grammarterm{identifier}\iref{lex.name},
\grammarterm{operator-function-id}\iref{over.oper},
\grammarterm{literal-operator-id}\iref{over.literal},
\grammarterm{conversion-function-id}\iref{class.conv.fct}, or
\grammarterm{template-id}\iref{temp.names} that denotes an entity or
label~(\ref{stmt.goto}, \ref{stmt.label}).

\pnum
Every name that denotes an entity is introduced by a
\defn{declaration}. Every name that denotes a label is introduced
either by a \tcode{goto} statement\iref{stmt.goto} or a
\grammarterm{labeled-statement}\iref{stmt.label}.

\pnum
A \defn{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.

\pnum
A \defnadj{local}{entity} is a variable with
automatic storage duration\iref{basic.stc.auto},
a structured binding\iref{dcl.struct.bind}
whose corresponding variable is such an entity,
or the \tcode{*this} object\iref{expr.prim.this}.

\pnum
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
\defnx{name lookup}{lookup!name}\iref{basic.lookup}.

\pnum
Two names are \defnx{the same}{name!same} if
\begin{itemize}
\item they are \grammarterm{identifier}{s} composed of the same character sequence, or
\item they are \grammarterm{operator-function-id}{s} formed with
the same operator, or
\item they are \grammarterm{conversion-function-id}{s} formed
with the same type, or
\item they are \grammarterm{template-id}{s} that refer to the same class,
function, or variable\iref{temp.type}, or
\item they are the names of literal operators\iref{over.literal} formed with
the same literal suffix identifier.
\end{itemize}

\pnum
\indextext{translation unit!name and}%
\indextext{linkage}%
A name used in more than one translation unit can potentially
refer to the same entity in these translation units depending on the
linkage\iref{basic.link} of the name specified in each
translation unit.

\rSec1[basic.def]{Declarations and definitions}

\pnum
\indextext{declaration!definition versus}%
\indextext{declaration}%
\indextext{declaration!name}%
A declaration\iref{dcl.dcl} 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:
\begin{itemize}
\item a static assertion\iref{dcl.pre},
\item controlling template instantiation\iref{temp.explicit},
\item guiding template argument deduction for constructors\iref{temp.deduct.guide},
\item use of attributes\iref{dcl.attr}, and
\item nothing (in the case of an \grammarterm{empty-declaration}).
\end{itemize}

\pnum
\indextext{declaration!function}%
\indextext{definition}%
Each entity declared by a \grammarterm{declaration} is
also \defnx{defined}{define} by that declaration unless:
\begin{itemize}
\item
it declares a function
without specifying the function's body\iref{dcl.fct.def},
\item
it contains
the
\indextext{declaration!\idxcode{extern}}%
\tcode{extern} specifier\iref{dcl.stc} or a
\grammarterm{linkage-specification}\footnote{Appearing inside the brace-enclosed
\grammarterm{declaration-seq} in a \grammarterm{linkage-specification} does
not affect whether a declaration is a definition.}\iref{dcl.link}
and neither an \grammarterm{initializer} nor a
\grammarterm{function-body},
\item
\indextext{declaration!static member@\tcode{static} member}%
it declares a non-inline static data member in a class
definition~(\ref{class.mem}, \ref{class.static}),
\item
it declares a static data member outside a class definition
and the variable was defined within the class with the \tcode{constexpr}
specifier (this usage is deprecated; see \ref{depr.static.constexpr}),
\item
\indextext{declaration!class name}%
it is introduced by an \grammarterm{elaborated-type-specifier}\iref{class.name},
\item
it is an
\indextext{declaration!opaque enum}%
\grammarterm{opaque-enum-declaration}\iref{dcl.enum},
\item
it is a
\indextext{parameter!template}\indextext{template parameter}%
\grammarterm{template-parameter}\iref{temp.param},
\item
it is a
\indextext{declaration!parameter}\indextext{parameter declaration}%
\grammarterm{parameter-declaration}\iref{dcl.fct} in a function
\indextext{declarator}%
declarator that is not the \grammarterm{declarator} of a
\grammarterm{function-definition},
\item
it is a
\indextext{declaration!\idxcode{typedef}}%
\tcode{typedef} declaration\iref{dcl.typedef},
\item it is
an \grammarterm{alias-declaration}\iref{dcl.typedef},
\item it is
a
\grammarterm{using-declaration}\iref{namespace.udecl},
\item it is
a \grammarterm{deduction-guide}\iref{temp.deduct.guide},
\item it is
a \grammarterm{static_assert-declaration}\iref{dcl.pre},
\item
it is an
\grammarterm{attribute-declaration}\iref{dcl.pre},
\item
it is an
\grammarterm{empty-declaration}\iref{dcl.pre},
\item it is
a \grammarterm{using-directive}\iref{namespace.udir},
\item it is
a \grammarterm{using-enum-declaration}\iref{enum.udecl},
\item it is
a \grammarterm{template-declaration}\iref{temp.pre}
whose \grammarterm{template-head} is not followed by
either a \grammarterm{concept-definition} or a \grammarterm{declaration}
that defines a function, a class, a variable, or a static data member.
\item it is
an explicit instantiation declaration\iref{temp.explicit}, or
\item it is
an explicit specialization\iref{temp.expl.spec} whose
\grammarterm{declaration} is not a definition.
\end{itemize}
A declaration is said to be a \defn{definition} of each entity that it defines.
\begin{example}
All but one of the following are definitions:
\begin{codeblock}
int a;                          // defines \tcode{a}
extern const int c = 1;         // defines \tcode{c}
int f(int x) { return x+a; }    // defines \tcode{f} and defines \tcode{x}
struct S { int a; int b; };     // defines \tcode{S}, \tcode{S::a}, and \tcode{S::b}
struct X {                      // defines \tcode{X}
  int x;                        // defines non-static data member \tcode{x}
  static int y;                 // declares static data member \tcode{y}
  X(): x(0) { }                 // defines a constructor of \tcode{X}
};
int X::y = 1;                   // defines \tcode{X::y}
enum { up, down };              // defines \tcode{up} and \tcode{down}
namespace N { int d; }          // defines \tcode{N} and \tcode{N::d}
namespace N1 = N;               // defines \tcode{N1}
X anX;                          // defines \tcode{anX}

\end{codeblock}
whereas these are just declarations:
\begin{codeblock}
extern int a;                   // declares \tcode{a}
extern const int c;             // declares \tcode{c}
int f(int);                     // declares \tcode{f}
struct S;                       // declares \tcode{S}
typedef int Int;                // declares \tcode{Int}
extern X anotherX;              // declares \tcode{anotherX}
using N::d;                     // declares \tcode{d}
\end{codeblock}
\end{example}

\pnum
\begin{note}
\indextext{implementation-generated}%
In some circumstances, \Cpp{} implementations implicitly define the
default constructor\iref{class.default.ctor},
copy constructor, move constructor\iref{class.copy.ctor},
copy assignment operator, move assignment operator\iref{class.copy.assign},
or destructor\iref{class.dtor} member functions.
\end{note}
\begin{example}
Given
\begin{codeblock}
#include <string>

struct C {
  std::string s;                // \tcode{std::string} is the standard library class\iref{string.classes}
};

int main() {
  C a;
  C b = a;
  b = a;
}
\end{codeblock}
the implementation will implicitly define functions to make the
definition of \tcode{C} equivalent to
\begin{codeblock}
struct C {
  std::string s;
  C() : s() { }
  C(const C& x): s(x.s) { }
  C(C&& x): s(static_cast<std::string&&>(x.s)) { }
      @\rlap{\normalfont\itshape //}@    : 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; }
      @\rlap{\normalfont\itshape //}@                { s = std::move(x.s); return *this; }
  ~C() { }
};
\end{codeblock}
\end{example}

\pnum
\begin{note}
A class name can also be implicitly declared by an
\grammarterm{elaborated-type-specifier}\iref{dcl.type.elab}.
\end{note}

\pnum
\indextext{type!incomplete}%
In the definition of an object,
the type of that object shall not be
an incomplete type\iref{basic.types},
an abstract class type\iref{class.abstract}, or
a (possibly multi-dimensional) array thereof.

\indextext{object!definition}%
\indextext{function!definition}%
\indextext{class!definition}%
\indextext{enumerator!definition}%
\indextext{one-definition rule|(}%
\rSec1[basic.def.odr]{One-definition rule}

\pnum
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.

\pnum
\indextext{expression!potentially evaluated}%
An expression or conversion is \defn{potentially evaluated} unless it is
an unevaluated operand\iref{expr.prop},
a subexpression thereof, or
a conversion in an initialization or conversion sequence in such a context.
The set of \defn{potential results} of an expression \tcode{e} is
defined as follows:
\begin{itemize}
\item If \tcode{e} is an
\grammarterm{id-expression}\iref{expr.prim.id}, the set
contains only \tcode{e}.
\item If \tcode{e} is a subscripting operation\iref{expr.sub} with
an array operand, the set contains the potential results of that operand.
\item If \tcode{e} is a class member access
expression\iref{expr.ref} of the form
\tcode{e1 . \opt{template} e2}
naming a non-static data member,
the set contains the potential results of \tcode{e1}.
\item If \tcode{e} is a class member access expression
naming a static data member,
the set contains the \grammarterm{id-expression} designating the data member.
\item If \tcode{e} is a pointer-to-member
expression\iref{expr.mptr.oper} of the form
\tcode{e1 .* e2},
the set contains the potential results of \tcode{e1}.
\item If \tcode{e} has the form \tcode{(e1)}, the set contains the
potential results of \tcode{e1}.
\item If \tcode{e} is a glvalue conditional
expression\iref{expr.cond}, the set is the union of the sets of
potential results of the second and third operands.
\item If \tcode{e} is a comma expression\iref{expr.comma}, the set
contains the potential results of the right operand.
\item Otherwise, the set is empty.
\end{itemize}
\begin{note}
This set is a (possibly-empty) set of \grammarterm{id-expression}{s},
each of which is either \tcode{e} or a subexpression of \tcode{e}.
\begin{example}
In the following example, the set of potential results of the initializer
of \tcode{n} contains the first \tcode{S::x} subexpression, but not the second
\tcode{S::x} subexpression.
\begin{codeblock}
struct S { static const int x = 0; };
const int &f(const int &r);
int n = b ? (1, S::x)           // \tcode{S::x} is not odr-used here
          : f(S::x);            // \tcode{S::x} is odr-used here, so a definition is required
\end{codeblock}
\end{example}
\end{note}

\pnum
A function is \defnx{named by}{function!named by expression or conversion}
an expression or conversion as follows:
\begin{itemize}
\item
  A function is named by an expression or conversion
  if it is the unique result of a name lookup or the selected member
  of a set of overloaded functions~(\ref{basic.lookup}, \ref{over.match}, \ref{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 \grammarterm{id-expression} naming the function with
  an explicitly qualified name or
  the expression forms a pointer to member\iref{expr.unary.op}.
  \begin{note}
This covers
  taking the address of functions~(\ref{conv.func}, \ref{expr.unary.op}),
  calls to named functions\iref{expr.call},
  operator overloading\iref{over},
  user-defined conversions\iref{class.conv.fct},
  allocation functions for \grammarterm{new-expression}{s}\iref{expr.new}, as well as
  non-default initialization\iref{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\iref{class.copy.elision}.
\end{note}
\item
  A deallocation function for a class
  is named by a \grammarterm{new-expression}
  if it is the single matching deallocation function
  for the allocation function selected by overload resolution,
  as specified in~\ref{expr.new}.
\item
  A deallocation function for a class
  is named by a \grammarterm{delete-expression}
  if it is the selected usual deallocation function
  as specified in~\ref{expr.delete} and~\ref{class.free}.
\end{itemize}

\pnum
A variable \tcode{x} whose name appears as a
potentially-evaluated expression \tcode{e}
is \defnx{odr-used}{odr-use} by \tcode{e} unless
\begin{itemize}
\item
  \tcode{x} is a reference that is
  usable in constant expressions\iref{expr.const}, or
\item
  \tcode{x} is a variable of non-reference type that is
  usable in constant expressions and has no mutable subobjects, and
  \tcode{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\iref{conv.lval} is applied, or
\item
  \tcode{x} is a variable of non-reference type, and
  \tcode{e} is an element of the set of potential results
  of a discarded-value expression\iref{expr.prop}
  to which the lvalue-to-rvalue conversion is not applied.
\end{itemize}

\pnum
A structured binding is odr-used if it appears as a potentially-evaluated expression.

\pnum
\tcode{*this} is odr-used if \tcode{this} appears as a potentially-evaluated expression
(including as the result of the implicit transformation in the body of a non-static
member function~(\ref{class.mfct.non-static})).

\pnum
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\iref{class.dtor}.\footnote{An implementation is not required
to call allocation and
deallocation functions from constructors or destructors; however, this
is a permissible implementation technique.}

\pnum
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~\ref{class.copy.assign}.
A constructor for a class is odr-used as specified
in~\ref{dcl.init}. A destructor for a class is odr-used if it is potentially
invoked\iref{class.dtor}.

\pnum
A local entity\iref{basic.pre}
is \defn{odr-usable} in a declarative region\iref{basic.scope.declarative} if:
\begin{itemize}
\item either the local entity is not \tcode{*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
\item
for each intervening declarative region\iref{basic.scope.declarative}
between the point at which the entity is introduced and the region
(where \tcode{*this} is considered to be introduced
within the innermost enclosing class or non-lambda function definition scope),
either:
\begin{itemize}
\item the intervening declarative region is a block scope, or
\item the intervening declarative region is the function parameter scope of a \grammarterm{lambda-expression}
that has a \grammarterm{simple-capture}
naming the entity or has a \grammarterm{capture-default}, and
the block scope of the \grammarterm{lambda-expression}
is also an intervening declarative region.
\end{itemize}
\end{itemize}

If a local entity is odr-used
in a declarative region in which it is not odr-usable,
the program is ill-formed.
\begin{example}
\begin{codeblock}
void f(int n) {
  [] { n = 1; };                // error: \tcode{n} is not odr-usable due to intervening lambda-expression
  struct A {
    void f() { n = 2; }         // error: \tcode{n} is not odr-usable due to intervening function definition scope
  };
  void g(int = n);              // error: \tcode{n} is not odr-usable due to intervening function parameter scope
  [=](int k = n) {};            // error: \tcode{n} is not odr-usable due to being
                                // outside the block scope of the \grammarterm{lambda-expression}
  [&] { [n]{ return n; }; };    // OK
}
\end{codeblock}
\end{example}

\pnum
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\iref{stmt.if}; 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~\ref{class.default.ctor}, \ref{class.copy.ctor},
\ref{class.dtor}, and \ref{class.copy.assign}).
A definition of an inline function or variable shall be reachable in every
translation unit in which it is odr-used outside of a discarded statement.
\begin{example}
\begin{codeblock}
auto f() {
  struct A {};
  return A{};
}
decltype(f()) g();
auto x = g();
\end{codeblock}
A program containing this translation unit is ill-formed
because \tcode{g} is odr-used but not defined,
and cannot be defined in any other translation unit
because the local class \tcode{A} cannot be named outside this
translation unit.
\end{example}

\pnum
\indextext{type!incomplete}%
A definition of a class is required to be reachable in every context in which
the class is used in a way that requires the class type to be complete.
\begin{example}
The following complete translation unit is well-formed,
even though it never defines \tcode{X}:
\begin{codeblock}
struct X;                       // declare \tcode{X} as a struct type
struct X* x1;                   // use \tcode{X} in pointer formation
X* x2;                          // use \tcode{X} in pointer formation
\end{codeblock}
\end{example}
\begin{note}
The rules for declarations and expressions
describe in which contexts complete class types are required. A class
type \tcode{T} must be complete if:
\begin{itemize}
\item an object of type \tcode{T} is defined\iref{basic.def}, or
\item a non-static class data member of type \tcode{T} is
declared\iref{class.mem}, or
\item \tcode{T} is used as the allocated type or array element type in a
\grammarterm{new-expression}\iref{expr.new}, or
\item an lvalue-to-rvalue conversion is applied to
a glvalue referring
to an object of type \tcode{T}\iref{conv.lval}, or
\item an expression is converted (either implicitly or explicitly) to
type \tcode{T} (\ref{conv}, \ref{expr.type.conv},
\ref{expr.dynamic.cast}, \ref{expr.static.cast}, \ref{expr.cast}), or
\item an expression that is not a null pointer constant, and has type
other than \cv{}~\tcode{void*}, is converted to the type pointer to \tcode{T}
or reference to \tcode{T} using a standard conversion\iref{conv},
a \tcode{dynamic_cast}\iref{expr.dynamic.cast} or
a \tcode{static_cast}\iref{expr.static.cast}, or
\item a class member access operator is applied to an expression of type
\tcode{T}\iref{expr.ref}, or
\item the \tcode{typeid} operator\iref{expr.typeid} or the
\tcode{sizeof} operator\iref{expr.sizeof} is applied to an operand of
type \tcode{T}, or
\item a function with a return type or argument type of type \tcode{T}
is defined\iref{basic.def} or called\iref{expr.call}, or
\item a class with a base class of type \tcode{T} is
defined\iref{class.derived}, or
\item an lvalue of type \tcode{T} is assigned to\iref{expr.ass}, or
\item the type \tcode{T} is the subject of an
\tcode{alignof} expression\iref{expr.alignof}, or
\item an \grammarterm{exception-declaration} has type \tcode{T}, reference to
\tcode{T}, or pointer to \tcode{T}\iref{except.handle}.
\end{itemize}
\end{note}

\pnum
There can be more than one definition of a
\begin{itemize}
\item class type\iref{class},
\item enumeration type\iref{dcl.enum},
\item inline function or variable\iref{dcl.inline},
\item templated entity\iref{temp.pre},
\item default argument for a parameter (for a function in a given scope)%
\iref{dcl.fct.default}, or
\item default template argument\iref{temp.param}
\end{itemize}
in a program provided that
each definition appears in a different translation unit, and
provided the definitions satisfy the following requirements.
There shall not be more than one definition
of an entity
that is attached to a named module\iref{module.unit};
no diagnostic is required unless a prior definition
is reachable at a point where a later definition appears.
Given such
an entity named \tcode{D} defined in more than one translation unit,
then
\begin{itemize}
\item each definition of \tcode{D} 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 \grammarterm{lambda-expression}; and
\item in each definition of \tcode{D}, corresponding names, looked up
according to~\ref{basic.lookup}, shall refer to the same entity, after
overload resolution\iref{over.match} and after matching of partial
template specialization\iref{temp.over}, except that a name can refer to
\begin{itemize}
\item
a non-volatile const object with internal or no linkage if the object
\begin{itemize}
\item has the same literal type in all definitions of \tcode{D},
\item is initialized with a constant expression\iref{expr.const},
\item is not odr-used in any definition of \tcode{D}, and
\item has the same value in all definitions of \tcode{D},
\end{itemize}
or
\item
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 \tcode{D};
\end{itemize}
and

\item in each definition of \tcode{D}, except within
the default arguments and default template arguments of \tcode{D},
corresponding \grammarterm{lambda-expression}{s} shall have
the same closure type (see below); and

\item in each definition of \tcode{D}, corresponding entities shall have the
same language linkage; and

\item in each definition of \tcode{D}, 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; and

\item in each definition of \tcode{D},
a default argument used by an (implicit or explicit) function call or
a default template argument used by an (implicit or explicit)
\grammarterm{template-id} or \grammarterm{simple-template-id}
is treated as if its token sequence
were present in the definition of \tcode{D};
that is, the default argument or default template argument
is subject to the requirements described in this paragraph (recursively); and

\item if \tcode{D} is a class with an implicitly-declared
constructor (\ref{class.default.ctor}, \ref{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 \tcode{D}.
\begin{example}
\begin{codeblock}
// translation unit 1:
struct X {
  X(int, int);
  X(int, int, int);
};
X::X(int, int = 0) { }
class D {
  X x = 0;
};
D d1;                           // \tcode{X(int, int)} called by \tcode{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;                           // \tcode{X(int, int, int)} called by \tcode{D()};
                                // \tcode{D()}'s implicit definition violates the ODR
\end{codeblock}
\end{example}

\item if \tcode{D} is a class with
a defaulted three-way comparison operator function\iref{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 \tcode{D}.
\end{itemize}
If \tcode{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\iref{temp.nondep}, and also to dependent names at
the point of instantiation\iref{temp.dep}.
These requirements also apply to corresponding entities
defined within each definition of \tcode{D}
(including the closure types of \grammarterm{lambda-expression}{s},
but excluding entities defined within default arguments or
default template arguments of either \tcode{D} or
an entity not defined within \tcode{D}).
For each such entity and for \tcode{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.
\begin{note}
The entity is still declared in multiple translation units, and \ref{basic.link}
still applies to these declarations. In particular,
\grammarterm{lambda-expression}{s}\iref{expr.prim.lambda}
appearing in the type of \tcode{D} may result
in the different declarations having distinct types, and
\grammarterm{lambda-expression}{s} appearing in a default argument of \tcode{D}
may still denote different types in different translation units.
\end{note}
If the definitions of
\tcode{D} do not satisfy these requirements, then
the program is ill-formed, no diagnostic required.%
\indextext{one-definition rule|)}
\begin{example}
\begin{codeblock}
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);
  }
};
\end{codeblock}

If the definition of \tcode{f} appears in multiple translation units,
the behavior of the program is as if
there is only one definition of \tcode{f}.
If the definition of \tcode{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 \grammarterm{lambda-expression} closure type.
The definition of \tcode{X} can appear
in multiple translation units of a valid program;
the \grammarterm{lambda-expression}{s} defined within
the default argument of \tcode{X::h} within the definition of \tcode{X}
denote the same closure type in each translation unit.
\end{example}

\rSec1[basic.scope]{Scope}%
\indextext{scope|(}

\rSec2[basic.scope.declarative]{Declarative regions and scopes}%
\indextext{scope!declarations and|(}

\pnum
\indextext{name!scope of}%
Every name is introduced in some portion of program text called a
\indextext{region!declarative}%
\indextext{scope!potential}%
\defn{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 \defn{scope}. To determine the
scope of a declaration, it is sometimes convenient to refer to the
\defn{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.

\pnum
\begin{example}
In
\begin{codeblock}
int j = 24;
int main() {
  int i = j, j;
  j = 42;
}
\end{codeblock}
the identifier \tcode{j} is declared twice as a name (and used twice).
The declarative region of the first \tcode{j} includes the entire
example. The potential scope of the first \tcode{j} begins immediately
after that \tcode{j} and extends to the end of the program, but its
(actual) scope excludes the text between the \tcode{,} and the
\tcode{\}}. The declarative region of the second declaration of
\tcode{j} (the \tcode{j} immediately before the semicolon) includes all
the text between \tcode{\{} and \tcode{\}}, but its potential scope
excludes the declaration of \tcode{i}. The scope of the second
declaration of \tcode{j} is the same as its potential scope.
\end{example}

\pnum
The names declared by a declaration are introduced into the scope in
which the declaration occurs, except that the presence of a
\tcode{friend} specifier\iref{class.friend}, certain uses of the
\grammarterm{elaborated-type-specifier}\iref{dcl.type.elab}, and
\grammarterm{using-directive}{s}\iref{namespace.udir} alter this general
behavior.

\pnum
Given a set of declarations in a single declarative region, each of
which specifies the same unqualified name,
\begin{itemize}
\item they shall all refer to the same entity, or all refer to functions
and function templates; or
\item 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\iref{basic.scope.hiding}.
\begin{note}
A structured binding\iref{dcl.struct.bind},
namespace name\iref{basic.namespace}, or
class template name\iref{temp.pre}
must be unique in its declarative region.
\end{note}
\end{itemize}
\begin{note}
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,
\grammarterm{elaborated-type-specifier}{s}\iref{dcl.type.elab} and
friend declarations\iref{class.friend} may introduce a (possibly not
visible) name into an enclosing namespace; these restrictions apply to
that region. Local extern declarations\iref{basic.link} may 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}

\pnum
For a given declarative region \placeholder{R}
and a point \placeholder{P} outside \placeholder{R},
the set of \defnx{intervening}{region!declarative!intervening} declarative regions
between \placeholder{P} and \placeholder{R}
comprises all declarative regions
that are or enclose \placeholder{R} and do not enclose \placeholder{P}.

\pnum
\begin{note}
The name lookup rules are summarized in~\ref{basic.lookup}.
\end{note}

\rSec2[basic.scope.pdecl]{Point of declaration}

\indextext{declaration!point of|(}%

\pnum
\indextext{name!point of declaration|see{declaration, point of}}%
\indextext{point of!declaration|see{declaration, point of}}%
The \defnx{point of declaration}{declaration!point of} for a name is immediately after its
complete declarator\iref{dcl.decl} and before its
\grammarterm{initializer} (if any), except as noted below.
\begin{example}
\begin{codeblock}
unsigned char x = 12;
{ unsigned char x = x; }
\end{codeblock}
Here the second \tcode{x} is initialized with its own (indeterminate)
value.
\end{example}

\pnum
\begin{note}
\indextext{name hiding}%
A name from an outer scope remains visible up
to the point of declaration of the name that hides it.
\begin{example}
\begin{codeblock}
const int  i = 2;
{ int  i[i]; }
\end{codeblock}
declares a block-scope array of two integers.
\end{example}
\end{note}

\pnum
The point of declaration for a class or class template first declared by a
\grammarterm{class-specifier} is immediately after the \grammarterm{identifier} or
\grammarterm{simple-template-id} (if any) in its \grammarterm{class-head}\iref{class.pre}.
The point of declaration for an enumeration is
immediately after the \grammarterm{identifier} (if any) in either its
\grammarterm{enum-specifier}\iref{dcl.enum} or its first
\grammarterm{opaque-enum-declaration}\iref{dcl.enum}, whichever comes first.
The point of declaration of an alias or alias template immediately
follows the \grammarterm{defining-type-id} to which the
alias refers.

\pnum
The point of declaration of a \grammarterm{using-declarator} that does not name a
constructor is immediately after the \grammarterm{using-declarator}\iref{namespace.udecl}.

\pnum
\indextext{declaration!enumerator point of}%
The point of declaration for an enumerator is immediately after its
\grammarterm{enumerator-definition}.
\begin{example}
\begin{codeblock}
const int x = 12;
{ enum { x = x }; }
\end{codeblock}
Here, the enumerator \tcode{x} is initialized with the value of the
constant \tcode{x}, namely 12.
\end{example}

\pnum
After the point of declaration of a class member, the member name can be
looked up in the scope of its class.
\begin{note}
\indextext{type!incomplete}%
This is true even if the class is an incomplete class. For example,
\begin{codeblock}
struct X {
  enum E { z = 16 };
  int b[X::z];      // OK
};
\end{codeblock}
\end{note}

\pnum
The point of declaration of a class first declared in an
\grammarterm{elaborated-type-specifier} is as follows:
\begin{itemize}
\item for a declaration of the form
\begin{ncbnf}
class-key \opt{attribute-specifier-seq} identifier \terminal{;}
\end{ncbnf}
the \grammarterm{identifier} is declared to be a
\grammarterm{class-name} in the scope that contains the declaration,
otherwise
\item for an \grammarterm{elaborated-type-specifier} of the form
\begin{ncbnf}
class-key identifier
\end{ncbnf}
if the
\grammarterm{elaborated-type-specifier} is used in the
\grammarterm{decl-specifier-seq} or \grammarterm{parameter-declaration-clause}
of a function defined in namespace scope, the \grammarterm{identifier} is
declared as a \grammarterm{class-name} in the namespace that contains the
declaration; otherwise, except as a friend declaration, the
\grammarterm{identifier} is declared in the smallest namespace or block
scope that contains the declaration.
\begin{note}
These rules also apply within templates.
\end{note}
\begin{note}
Other
forms of \grammarterm{elaborated-type-specifier} do not declare a new name,
and therefore must refer to an existing \grammarterm{type-name}.
See~\ref{basic.lookup.elab} and~\ref{dcl.type.elab}.
\end{note}
\end{itemize}

\pnum
The point of declaration for an
injected-class-name\iref{class.pre} is immediately following
the opening brace of the class definition.

\pnum
The point of declaration for a function-local predefined
variable\iref{dcl.fct.def.general} is immediately before the
\grammarterm{function-body} of a function definition.

\pnum
The point of declaration of a structured binding\iref{dcl.struct.bind}
is immediately after
the \grammarterm{identifier-list} of the structured binding declaration.

\pnum
The point of declaration for the variable or the structured bindings
declared in the \grammarterm{for-range-declaration}
of a range-based \tcode{for} statement\iref{stmt.ranged}
is immediately after the \grammarterm{for-range-initializer}.

\pnum
The point of declaration for a template parameter is immediately after its complete
\grammarterm{template-parameter}.
\begin{example}
\begin{codeblock}
typedef unsigned char T;
template<class T
  = T               // lookup finds the typedef name of \tcode{unsigned char}
  , T               // lookup finds the template parameter
    N = 0> struct A { };
\end{codeblock}
\end{example}

\pnum
\begin{note}
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\iref{namespace.memdef}. Function
declarations at block scope and variable declarations with the
\tcode{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}

\pnum
\begin{note}
For point of instantiation of a template, see~\ref{temp.point}.
\end{note}
\indextext{scope!declarations and|)}%
\indextext{declaration!point of|)}

\rSec2[basic.scope.block]{Block scope}

\pnum
\indextext{scope!block}%
\indextext{local scope|see{block scope}}%
A name declared in a block\iref{stmt.block} is local to that block; it has
\defnx{block scope}{block (statement)!scope}.
Its potential scope begins at its point of
declaration\iref{basic.scope.pdecl} and ends at the end of its block.
A variable declared at block scope is a \defn{local variable}.

\pnum
\indextext{scope!exception declaration}%
The name declared in an \grammarterm{exception-declaration}
is local to the
\grammarterm{handler} and shall not be redeclared in the outermost block of the
\grammarterm{handler}.

\pnum
Names declared in the \grammarterm{init-statement}, the \grammarterm{for-range-declaration}, and in the
\grammarterm{condition} of \tcode{if}, \tcode{while}, \tcode{for}, and
\tcode{switch} statements are local to the \tcode{if}, \tcode{while},
\tcode{for}, or \tcode{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 \tcode{if}
statement, any of the outermost blocks) of the controlled statement.
\begin{example}
\begin{codeblock}
if (int x = f()) {
  int x;            // ill-formed, redeclaration of \tcode{x}
}
else {
  int x;            // ill-formed, redeclaration of \tcode{x}
}
\end{codeblock}
\end{example}

\rSec2[basic.scope.param]{Function parameter scope}

\pnum
\indextext{scope!function parameter}%
\indextext{scope!function prototype|see{scope, function parameter}}%
\indextext{parameter!scope of}%
A function parameter
(including one appearing in a
\grammarterm{lambda-declarator})
or function-local predefined variable\iref{dcl.fct.def}
has \defn{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 \grammarterm{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 \grammarterm{function-try-block}.

\rSec2[basic.funscope]{Function scope}

\pnum
\indextext{label!scope of}%
Labels\iref{stmt.label} have \defnx{function scope}{scope!function} and
may be used anywhere in the function in which they are declared. Only
labels have function scope.

\rSec2[basic.scope.namespace]{Namespace scope}

\pnum
\indextext{scope!namespace}%
The declarative region of a \grammarterm{namespace-definition} is its
\grammarterm{namespace-body}.  Entities declared in a
\grammarterm{namespace-body} are said to be \defn{members} of the
namespace, and names introduced by these declarations into the
declarative region of the namespace are said to be \defn{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\iref{basic.scope.pdecl} onwards; and for each
\grammarterm{using-directive}\iref{namespace.udir} that nominates the
member's namespace, the member's potential scope includes that portion
of the potential scope of the \grammarterm{using-directive} that follows
the member's point of declaration.
\begin{example}
\begin{codeblock}
namespace N {
  int i;
  int g(int a) { return a; }
  int j();
  void q();
}
namespace { int l=1; }
// the potential scope of \tcode{l} is from its point of declaration to the end of the translation unit

namespace N {
  int g(char a) {   // overloads \tcode{N::g(int)}
    return l+a;     // \tcode{l} is from unnamed namespace
  }

  int i;            // error: duplicate definition
  int j();          // OK: duplicate function declaration

  int j() {         // OK: definition of \tcode{N::j()}
    return g(i);    // calls \tcode{N::g(int)}
  }
  int q();          // error: different return type
}
\end{codeblock}
\end{example}

\pnum
If a translation unit $Q$ is imported into a translation unit $R$\iref{module.import},
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 \grammarterm{module-import-declaration}
or \grammarterm{module-declaration}
in $R$ that imports $Q$ (directly or indirectly) if
\begin{itemize}
\item $X$ does not have internal linkage, and
\item $X$ is declared after the \grammarterm{module-declaration} in $Q$ (if any), and
\item either $X$ is exported or $Q$ and $R$ are part of the same module.
\end{itemize}
\begin{note}
A \grammarterm{module-import-declaration} imports both
the named translation unit(s) and
any modules named by exported
\grammarterm{module-import-declaration}{s} within them,
recursively.
\begin{example}
\begin{codeblocktu}{Translation unit \#1}
export module Q;
export int sq(int i) { return i*i; }
\end{codeblocktu}

\begin{codeblocktu}{Translation unit \#2}
export module R;
export import Q;
\end{codeblocktu}

\begin{codeblocktu}{Translation unit \#3}
import R;
int main() { return sq(9); }   // OK: \tcode{sq} from module \tcode{Q}
\end{codeblocktu}
\end{example}
\end{note}

\pnum
A namespace member can also be referred to after the \tcode{::} scope
resolution operator\iref{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 \grammarterm{using-directive}; see~\ref{namespace.qual}.

\pnum
The outermost declarative region of a translation unit is also a
namespace, called the \defnadj{global}{namespace}. A name declared in
the global namespace has \defnadj{global}{namespace scope} (also called
\defnadj{global}{scope}). The potential scope of such a name begins at
its point of declaration\iref{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
\defnadj{global}{name}.

\rSec2[basic.scope.class]{Class scope}
\indextext{scope!class}%

\pnum
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\iref{class.mem}
of that class.

\pnum
A name \tcode{N} used in a class \tcode{S} shall refer to the same
declaration in its context and when re-evaluated in the completed scope
of \tcode{S}. No diagnostic is required for a violation of this rule.

\pnum
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.

\pnum
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 \grammarterm{declarator-id},
including a \grammarterm{parameter-declaration-clause} and any default
arguments\iref{dcl.fct.default}).

\pnum
\begin{example}
\begin{codeblock}
typedef int  c;
enum { i = 1 };

class X {
  char  v[i];                       // error: \tcode{i} refers to \tcode{::i} but when reevaluated is \tcode{X::i}
  int  f() { return sizeof(c); }    // OK: \tcode{X::c}
  char  c;
  enum { i = 2 };
};

typedef char*  T;
struct Y {
  T  a;                             // error: \tcode{T} refers to \tcode{::T} but when reevaluated is \tcode{Y::T}
  typedef long  T;
  T  b;
};

typedef int I;
class D {
  typedef I I;                      // error, even though no reordering involved
};
\end{codeblock}
\end{example}

\pnum
The name of a class member shall only be used as follows:
\begin{itemize}
\item in the scope of its class (as described above) or a class derived\iref{class.derived}
from its class,
\item after the \tcode{.} operator applied to an expression of the type
of its class\iref{expr.ref} or a class derived from its class,
\item after the \tcode{->} operator applied to a pointer to an object of
its class\iref{expr.ref} or a class derived from its class,
\item after the \tcode{::} scope resolution operator\iref{expr.prim.id.qual}
applied to the name of its class or a class derived from its class.
\end{itemize}

\rSec2[basic.scope.enum]{Enumeration scope}%
\indextext{enumeration scope}%
\indextext{scope!enumeration}

\pnum
The name of a scoped enumerator\iref{dcl.enum} has
\defn{enumeration scope}. Its potential scope begins at
its point of declaration and terminates at the end of the
\grammarterm{enum-specifier}.

\rSec2[basic.scope.temp]{Template parameter scope}%
\indextext{template parameter scope}%
\indextext{scope!template parameter}%

\pnum
The declarative region of the name of a template parameter of a template
\grammarterm{template-parameter} is the smallest \grammarterm{template-parameter-list}
in which the name was introduced.

\pnum
The declarative region of the name of a template parameter of a template is the smallest
\grammarterm{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 \grammarterm{declaration} of a \grammarterm{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.
\begin{example}
\begin{codeblock}
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
  };
}
\end{codeblock}
The declarative regions of \tcode{T}, \tcode{U} and \tcode{V} are the
\grammarterm{template-declaration}{s} on lines \#1, \#2, and \#3,
respectively. But the names \tcode{A}, \tcode{f}, \tcode{g} and \tcode{C} all belong to
the same declarative region --- namely, the \grammarterm{namespace-body} of \tcode{N}.
(\tcode{g} is still considered to belong to this declarative region in spite of its
being hidden during qualified and unqualified name lookup.)
\end{example}

\pnum
The potential scope of a template parameter name begins at its point of
declaration\iref{basic.scope.pdecl} and ends at the end of its declarative region.
\begin{note}
This implies that a \grammarterm{template-parameter} can be used in the
declaration of subsequent \grammarterm{template-parameter}{s} and their default
arguments but cannot be used in preceding \grammarterm{template-parameter}{s} or their
default arguments. For example,
\begin{codeblock}
template<class T, T* p, class U = T> class X { @\commentellip@ };
template<class T> void f(T* p = new T);
\end{codeblock}

This also implies that a \grammarterm{template-parameter} can be used in the
specification of base classes. For example,
\begin{codeblock}
template<class T> class X : public Array<T> { @\commentellip@ };
template<class T> class Y : public T { @\commentellip@ };
\end{codeblock}
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}

\pnum
The declarative region of the name of a template parameter is nested within the
immediately-enclosing declarative region.
\begin{note}
As a result, a
\grammarterm{template-parameter} hides any entity with the same name in an enclosing
scope\iref{basic.scope.hiding}.
\begin{example}
\begin{codeblock}
typedef int N;
template<N X, typename N, template<N Y> class T> struct A;
\end{codeblock}
Here, \tcode{X} is a non-type template parameter of type \tcode{int} and \tcode{Y} is a
non-type template parameter of the same type as the second template parameter of
\tcode{A}.
\end{example}
\end{note}

\pnum
\begin{note}
Because the name of a template parameter cannot be redeclared within its
potential scope\iref{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~\ref{temp.local}.
\end{note}

\rSec2[basic.scope.hiding]{Name hiding}

\pnum
\indextext{scope name hiding and}%
\indextext{name hiding}%
\indextext{hiding|see{name hiding}}%
A declaration of a name in a nested declarative region
hides a declaration of the same name in an enclosing declarative region;
see \ref{basic.scope.declarative} and \ref{basic.lookup.unqual}.

\pnum
\indextext{name hiding}%
If a class name\iref{class.name} or enumeration name\iref{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 \grammarterm{using-directive}{s}\iref{basic.lookup.unqual}),
the class or enumeration name is hidden wherever the variable, data member,
function, or enumerator name is visible.

\pnum
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~\ref{basic.scope.class}. The declaration of a member in a derived
class\iref{class.derived} hides the declaration of a member of
a base class of the same name; see~\ref{class.member.lookup}.

\pnum
During the lookup of a name qualified by a namespace name, declarations
that would otherwise be made visible by a \grammarterm{using-directive} can
be hidden by declarations with the same name in the namespace containing
the \grammarterm{using-directive}; see~\ref{namespace.qual}.

\pnum
\indextext{visibility}%
If a name is in scope and is not hidden it is said to be \defn{visible}.%
\indextext{scope|)}

\rSec1[basic.lookup]{Name lookup}%
\indextext{scope!name lookup and|(}%
\indextext{lookup!name|(}%

\pnum
The name lookup rules apply uniformly to all names (including
\grammarterm{typedef-name}{s}\iref{dcl.typedef},
\grammarterm{namespace-name}{s}\iref{basic.namespace}, and
\grammarterm{class-name}{s}\iref{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\iref{basic.def} of
that name.
The declarations found by name lookup shall either all denote the same entity or
shall all denote functions or function templates;
in the latter case,
the declarations are said to form a set of overloaded
functions\iref{over.load}. Overload resolution\iref{over.match}
takes place after name lookup has succeeded. The access rules\iref{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\iref{module.reach} redeclarations
used further in expression processing\iref{expr}.

\pnum
A name ``looked up in the context of an expression'' is looked up
in the scope where the expression is found.

\pnum
The injected-class-name of a class\iref{class.pre} is also
considered to be a member of that class for the purposes of name hiding
and lookup.

\pnum
\begin{note}
\ref{basic.link} discusses linkage issues. The notions of
scope, point of declaration and name hiding are discussed
in~\ref{basic.scope}.
\end{note}

\rSec2[basic.lookup.unqual]{Unqualified name lookup}

\pnum
\indextext{lookup!unqualified name}%
\indextext{name!unqualified}%
In all the cases listed in~\ref{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.

\pnum
The declarations from the namespace nominated by a
\grammarterm{using-directive} become visible in a namespace enclosing the
\grammarterm{using-directive}; see~\ref{namespace.udir}. For the purpose of
the unqualified name lookup rules described
in~\ref{basic.lookup.unqual}, the declarations from the namespace
nominated by the \grammarterm{using-directive} are considered members of
that enclosing namespace.

\pnum
The lookup for an unqualified name used as the
\grammarterm{postfix-expression} of a function call is described
in~\ref{basic.lookup.argdep}.
\begin{note}
For purposes of determining
(during parsing) whether an expression is a
\grammarterm{postfix-expression} for a function call, the usual name lookup
rules apply.
In some cases
a name followed by \tcode{<} is treated as a \grammarterm{template-name}
even though name lookup did not find a \grammarterm{template-name}
(see \ref{temp.names}).
For example,
\begin{codeblock}
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 \tcode{f} finds nothing, \tcode{f} treated as template name
int y = g<N::A>(N::A());        // OK: lookup of \tcode{g} finds a function, \tcode{g} treated as template name
int z = h<N::A>(N::A());        // error: \tcode{h<} does not begin a \grammarterm{template-id}
\end{codeblock}

The rules in~\ref{basic.lookup.argdep} have no effect on
the syntactic interpretation of an expression. For example,
\begin{codeblock}
typedef int f;
namespace N {
  struct A {
    friend void f(A &);
    operator int();
    void g(A a) {
      int i = f(a);             // \tcode{f} is the typedef, not the friend function: equivalent to \tcode{int(a)}
    }
  };
}
\end{codeblock}
Because the expression is not a function call, the argument-dependent
name lookup\iref{basic.lookup.argdep} does not apply and the friend
function \tcode{f} is not found.
\end{note}

\pnum
A name used in global scope, outside of any function, class or
user-declared namespace, shall be declared before its use in global
scope.

\pnum
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.

\pnum
In the definition of a function that is a member of namespace \tcode{N},
a name used after the function's
\grammarterm{declarator-id}\footnote{This refers to unqualified names
that occur, for instance, in
a type or default argument in the
\grammarterm{parameter-declaration-clause} or used in the function body.}
shall be
declared before its use in the block in which it is used or in one of
its enclosing blocks\iref{stmt.block} or shall be declared before its
use in namespace \tcode{N} or, if \tcode{N} is a nested namespace, shall
be declared before its use in one of \tcode{N}'s enclosing namespaces.
\begin{example}
\begin{codeblock}
namespace A {
  namespace N {
    void f();
  }
}
void A::N::f() {
  i = 5;
  // The following scopes are searched for a declaration of \tcode{i}:
  // 1) outermost block scope of \tcode{A::N::f}, before the use of \tcode{i}
  // 2) scope of namespace \tcode{N}
  // 3) scope of namespace \tcode{A}
  // 4) global scope, before the definition of \tcode{A::N::f}
}
\end{codeblock}
\end{example}

\pnum
A name used in the definition of a class \tcode{X}%
\footnote{This
refers to unqualified names following the class name;
such a name may be used in a \grammarterm{base-specifier} or
in the \grammarterm{member-specification} of the class definition.}
outside of a complete-class context\iref{class.mem} of \tcode{X}
shall be declared in one of the following ways:
\begin{itemize}
\item before its use in class \tcode{X} or be a member of a base class
of \tcode{X}\iref{class.member.lookup}, or
\item if \tcode{X} is a nested class of class
\tcode{Y}\iref{class.nest}, before the definition of \tcode{X} in
\tcode{Y}, or shall be a member of a base class of \tcode{Y} (this
lookup applies in turn to \tcode{Y}'s enclosing classes, starting with
the innermost enclosing class),\footnote{This lookup applies whether the
definition of \tcode{X} is
nested within \tcode{Y}'s definition or whether \tcode{X}'s definition
appears in a namespace scope enclosing \tcode{Y}'s
definition\iref{class.nest}.}
or
\item if \tcode{X} is a local class\iref{class.local} or is a nested
class of a local class, before the definition of class \tcode{X} in a
block enclosing the definition of class \tcode{X}, or
\item if \tcode{X} is a member of namespace \tcode{N}, or is a nested
class of a class that is a member of \tcode{N}, or is a local class or a
nested class within a local class of a function that is a member of
\tcode{N}, before the definition of class \tcode{X} in namespace
\tcode{N} or in one of \tcode{N}'s enclosing namespaces.
\end{itemize}
\begin{example}
\begin{codeblock}
namespace M {
  class B { };
}

\end{codeblock}
\begin{codeblock}
namespace N {
  class Y : public M::B {
    class X {
      int a[i];
    };
  };
}

// The following scopes are searched for a declaration of \tcode{i}:
// 1) scope of class \tcode{N::Y::X}, before the use of \tcode{i}
// 2) scope of class \tcode{N::Y}, before the definition of \tcode{N::Y::X}
// 3) scope of \tcode{N::Y}'s base class \tcode{M::B}
// 4) scope of namespace \tcode{N}, before the definition of \tcode{N::Y}
// 5) global scope, before the definition of \tcode{N}
\end{codeblock}
\end{example}
\begin{note}
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~\ref{namespace.memdef}.
\end{note}
\begin{note}
\ref{basic.scope.class}
further describes the restrictions on the use of names in a class
definition. \ref{class.nest} further describes the restrictions on the
use of names in nested class definitions. \ref{class.local} further
describes the restrictions on the use of names in local class
definitions.
\end{note}

\pnum
For the members of a class \tcode{X}, a name used
in a complete-class context\iref{class.mem} of \tcode{X} or
in the definition of a class member outside of the definition of \tcode{X},
following the member's
\grammarterm{declarator-id}\footnote{That is, an unqualified name that occurs,
for instance, in a
type in the
\grammarterm{parameter-declaration-clause} or in the
\grammarterm{noexcept-specifier}.}, shall be declared in one of the
following ways:
\begin{itemize}
\item before its use in the block in which it is used or in an enclosing
block\iref{stmt.block}, or

\item shall be a member of class \tcode{X} or be a member of a base
class of \tcode{X}\iref{class.member.lookup}, or

\item if \tcode{X}
is a nested class of class \tcode{Y}\iref{class.nest}, shall be a
member of \tcode{Y}, or shall be a member of a base class of \tcode{Y}
(this lookup applies in turn to \tcode{Y}'s enclosing classes, starting
with the innermost enclosing class),\footnote{This lookup applies whether
the member function is defined
within the definition of class \tcode{X} or whether the member function
is defined in a namespace scope enclosing \tcode{X}'s definition.}
or

\item if \tcode{X} is a local class\iref{class.local} or is a nested
class of a local class, before the definition of class \tcode{X} in a
block enclosing the definition of class \tcode{X}, or

\item if \tcode{X} is a member of namespace \tcode{N}, or is a nested
class of a class that is a member of \tcode{N}, or is a local class or a
nested class within a local class of a function that is a member of
\tcode{N}, before the use of the name, in namespace \tcode{N}
or in one of \tcode{N}'s enclosing namespaces.
\end{itemize}
\begin{example}
\begin{codeblock}
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 \tcode{i}:
// 1) outermost block scope of \tcode{M::N::X::f}, before the use of \tcode{i}
// 2) scope of class \tcode{M::N::X}
// 3) scope of \tcode{M::N::X}'s base class \tcode{B}
// 4) scope of namespace \tcode{M::N}
// 5) scope of namespace \tcode{M}
// 6) global scope, before the definition of \tcode{M::N::X::f}
\end{codeblock}
\end{example}
\begin{note}
\ref{class.mfct} and~\ref{class.static} further
describe the restrictions on the use of names in member function
definitions. \ref{class.nest} further describes the restrictions on the
use of names in the scope of nested classes. \ref{class.local} further
describes the restrictions on the use of names in local class
definitions.
\end{note}

\pnum
Name lookup for a name used in the definition of a friend
function\iref{class.friend} 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.

\pnum
In a friend declaration naming a member function, a name used in
the function declarator and not part of a \grammarterm{template-argument}
in the \grammarterm{declarator-id} is first looked up in the scope of the
member function's class\iref{class.member.lookup}. If it is not found,
or if the name is part of a
\grammarterm{template-argument} in
the \grammarterm{declarator-id}, the look up is
as described for unqualified names in the definition of the class
granting friendship.
\begin{example}
\begin{codeblock}
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 \tcode{A::AT}
  friend void A::f2(BT);        // parameter type is \tcode{B::BT}
  friend void A::f3<AT>();      // template argument is \tcode{B::AT}
};
\end{codeblock}
\end{example}

\pnum
During the lookup for a name used as a default
argument\iref{dcl.fct.default} in a function
\grammarterm{parameter-declaration-clause} or used in the
\grammarterm{expression} of a \grammarterm{mem-initializer} for a
constructor\iref{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.
\begin{note}
\ref{dcl.fct.default} further describes the restrictions on the use of
names in default arguments. \ref{class.base.init} further describes the
restrictions on the use of names in a \grammarterm{ctor-initializer}.
\end{note}

\pnum
During the lookup of a name used in the
\grammarterm{constant-expression} of an \grammarterm{enumerator-definition},
previously declared \grammarterm{enumerator}{s} of the enumeration are visible
and hide the names of entities declared in the block, class, or namespace
scopes containing the \grammarterm{enum-specifier}.

\pnum
A name used in the definition of a \tcode{static} data member of class
\tcode{X}\iref{class.static.data} (after the \grammarterm{qualified-id}
of the static member) is looked up as if the name was used in a member
function of \tcode{X}.
\begin{note}
\ref{class.static.data} further
describes the restrictions on the use of names in the definition of a
\tcode{static} data member.
\end{note}

\pnum
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 \grammarterm{declarator-id}) is looked up as if the
definition of the member occurred in its namespace.
\begin{example}
\begin{codeblock}
namespace N {
  int i = 4;
  extern int j;
}

int i = 2;

int N::j = i;       // \tcode{N::j == 4}
\end{codeblock}
\end{example}

\pnum
A name used in the handler for a \grammarterm{function-try-block}\iref{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
\grammarterm{exception-declaration} nor in the outermost block of a handler
for the \grammarterm{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 \grammarterm{function-try-block}.
\begin{note}
But
function parameter names are found.
\end{note}

\pnum
\begin{note}
The rules for name lookup in template definitions are
described in~\ref{temp.res}.
\end{note}

\rSec2[basic.lookup.argdep]{Argument-dependent name lookup}%
\indextext{lookup!argument-dependent}

\pnum
When the \grammarterm{postfix-expression} in
a function call\iref{expr.call} is an \grammarterm{unqualified-id}, other namespaces not considered
during the usual unqualified lookup\iref{basic.lookup.unqual} may be
searched, and in those namespaces, namespace-scope friend function or
function template declarations\iref{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).
\begin{example}
\begin{codeblock}
namespace N {
  struct S { };
  void f(S);
}

void g() {
  N::S s;
  f(s);             // OK: calls \tcode{N::f}
  (f)(s);           // error: \tcode{N::f} not considered; parentheses prevent argument-dependent lookup
}
\end{codeblock}
\end{example}

\pnum
For each argument type \tcode{T} in the function call,
there is a set of zero or more
\defnx{associated namespaces}{namespace!associated}
and a set of zero or more
\defnx{associated entities}{entity!associated}
(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 \grammarterm{using-declaration}{s}
used to specify the types
do not contribute to this set.
The sets of namespaces and entities
are determined in the following way:
\begin{itemize}
\item If \tcode{T} is a fundamental type, its associated sets of
namespaces and entities are both empty.

\item If \tcode{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 \tcode{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.
\begin{note}
Non-type template arguments do not
contribute to the set of associated namespaces.
\end{note}

\item If \tcode{T} is an enumeration type,
its associated namespace is
the innermost enclosing namespace of its declaration, and
its associated entities are \tcode{T}
and, if it is a class member, the member's class.

\item If \tcode{T} is a pointer to \tcode{U} or an array of \tcode{U},
its associated namespaces and entities are those associated with
\tcode{U}.

\item If \tcode{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.

\item If \tcode{T} is a pointer to a member function of a class
\tcode{X}, its associated namespaces and entities are those associated
with the function parameter types and return type, together with those
associated with \tcode{X}.

\item If \tcode{T} is a pointer to a data member of class \tcode{X}, its
associated namespaces and entities are those associated with the member
type together with those associated with \tcode{X}.
\end{itemize}
If an associated namespace is an inline namespace\iref{namespace.def}, 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 a set of
overloaded functions and/or function templates, 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 set of overloaded functions is named with
a \grammarterm{template-id}, its associated entities and namespaces also include
those of its type \grammarterm{template-argument}{s} and its template
\grammarterm{template-argument}{s}.

\pnum
Let \placeholder{X} be the lookup set produced by unqualified
lookup\iref{basic.lookup.unqual} and let \placeholder{Y} be the lookup set produced
by argument dependent lookup (defined as follows). If \placeholder{X} contains
\begin{itemize}
\item a declaration of a class member, or
\item a block-scope function declaration that is not a \grammarterm{using-declaration}, or
\item a declaration that is neither a function nor a function template
\end{itemize}
then \placeholder{Y} is empty. Otherwise \placeholder{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 \placeholder{X} and \placeholder{Y}.
\begin{note}
The namespaces and entities
associated with the argument types can include namespaces and entities
already considered by the ordinary unqualified lookup.
\end{note}
\begin{example}
\begin{codeblock}
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 \tcode{NS::f}
  extern void g(NS::T, float);
  g(parm, 1);                   // OK: calls \tcode{g(NS::T, float)}
}
\end{codeblock}
\end{example}

\pnum
When considering an associated namespace \tcode{N},
the lookup is the same as the
lookup performed when \tcode{N}
is used as a qualifier\iref{namespace.qual}
except that:
\begin{itemize}
\item Any \grammarterm{using-directive}{s} in \tcode{N} are ignored.

\item All names except those of (possibly overloaded) functions and
function templates are ignored.

\item Any namespace-scope friend functions or friend function templates\iref{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\iref{namespace.memdef}.

\item
Any exported declaration \tcode{D} in \tcode{N}
declared within the purview of
a named module \tcode{M}\iref{module.interface}
is visible
if there is an associated entity attached to \tcode{M}
with the same innermost enclosing non-inline namespace as \tcode{D}.

\item
If the lookup is for a dependent name (\ref{temp.dep}, \ref{temp.dep.candidate}),
any declaration \tcode{D} in \tcode{N}
is visible
if \tcode{D} would be visible to qualified name lookup\iref{namespace.qual}
at any point in the instantiation context\iref{module.context} of the lookup,
unless \tcode{D} is declared in another translation unit, attached to the global module,
and is either discarded\iref{module.global.frag} or has internal linkage.
\end{itemize}

\pnum
\begin{example}
\begin{codeblocktu}{Translation unit \#1}
export module M;
namespace R {
  export struct X {};
  export void f(X);
}
namespace S {
  export void f(R::X, R::X);
}
\end{codeblocktu}

\begin{codeblocktu}{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);
}
\end{codeblocktu}

\begin{codeblocktu}{Translation unit \#3}
module Q;
import N;
namespace S {
  struct Z { template<typename T> operator T(); };
}
void test() {
  auto x = make();              // OK, \tcode{decltype(x)} is \tcode{R::X} in module \tcode{M}
  R::f(x);                      // ill-formed: \tcode{R} and \tcode{R::f} are not visible here
  f(x);                         // OK, calls \tcode{R::f} from interface of \tcode{M}
  f(x, S::Z());                 // ill-formed: \tcode{S::f} in module \tcode{M} not considered
                                // even though \tcode{S} is an associated namespace
  apply(x, S::Z());             // OK, \tcode{S::f} is visible in instantiation context, and
                                // \tcode{R::g} is visible even though it has internal linkage
}
\end{codeblocktu}
\end{example}

\rSec2[basic.lookup.qual]{Qualified name lookup}

\pnum
\indextext{lookup!qualified name|(}%
\indextext{name!qualified}%
\indextext{qualification!explicit}%
The name of a class or namespace member
or enumerator can be referred to after the
\tcode{::} scope resolution operator\iref{expr.prim.id.qual} applied to a
\grammarterm{nested-name-specifier} that denotes its class,
namespace, or enumeration.
If a
\tcode{::} scope resolution
operator
in a \grammarterm{nested-name-specifier} is not preceded by a \grammarterm{decltype-specifier},
lookup of the name preceding that \tcode{::} 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.
\begin{example}
\begin{codeblock}
class A {
public:
  static int n;
};
int main() {
  int A;
  A::n = 42;        // OK
  A b;              // ill-formed: \tcode{A} does not name a type
}
\end{codeblock}
\end{example}

\pnum
\begin{note}
Multiply qualified names, such as \tcode{N1::N2::N3::n}, can
be used to refer to members of nested classes\iref{class.nest} or
members of nested namespaces.
\end{note}

\pnum
In a declaration in which the \grammarterm{declarator-id} is a
\grammarterm{qualified-id}, names used before the \grammarterm{qualified-id}
being declared are looked up in the defining namespace scope; names
following the \grammarterm{qualified-id} are looked up in the scope of the
member's class or namespace.
\begin{example}
\begin{codeblock}
class X { };
class C {
  class X { };
  static const int number = 50;
  static X arr[number];
};
X C::arr[number];   // ill-formed:
                    // equivalent to \tcode{::X} \tcode{C::arr[C::number];}
                    // and not to \tcode{C::X} \tcode{C::arr[C::number];}
\end{codeblock}
\end{example}

\pnum
\indextext{operator!scope resolution}%
\indextext{scope resolution operator|see{operator, scope resolution}}%
A name prefixed by the unary scope operator \tcode{::}\iref{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
\grammarterm{using-directive}\iref{namespace.qual}. The use of \tcode{::}
allows a global name to be referred to even if its identifier has been
hidden\iref{basic.scope.hiding}.

\pnum
A name prefixed by a \grammarterm{nested-name-specifier} that
nominates an enumeration type shall represent an \grammarterm{enumerator}
of that enumeration.

\pnum
In a \grammarterm{qualified-id} of the form:

\begin{ncbnf}
\opt{nested-name-specifier} type-name \terminal{::} \terminal{\~} type-name
\end{ncbnf}
the second \grammarterm{type-name} is looked up in the same scope as the first.
\begin{example}
\begin{codeblock}
struct C {
  typedef int I;
};
typedef int I1, I2;
extern int* p;
extern int* q;
p->C::I::~I();      // \tcode{I} is looked up in the scope of \tcode{C}
q->I1::~I2();       // \tcode{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 \tcode{A}
}
\end{codeblock}
\end{example}
\begin{note}
\ref{basic.lookup.classref} describes how name
lookup proceeds after the \tcode{.} and \tcode{->} operators.
\end{note}

\rSec3[class.qual]{Class members}

\pnum
\indextext{lookup!class member}%
If the \grammarterm{nested-name-specifier} of a \grammarterm{qualified-id}
nominates a class, the name specified after the
\grammarterm{nested-name-specifier} is looked up in the scope of the
class\iref{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\iref{class.derived}.
\begin{note}
A class member
can be referred to using a \grammarterm{qualified-id} at any point in its
potential scope\iref{basic.scope.class}.
\end{note}
The exceptions to
the name lookup rule above are the following:
\begin{itemize}
\item the lookup for a destructor is as specified
in~\ref{basic.lookup.qual};

\item a \grammarterm{conversion-type-id} of a
\grammarterm{conversion-function-id} is looked up
in the same manner as a \grammarterm{conversion-type-id} in a class member
access (see~\ref{basic.lookup.classref});

\item the names in a \grammarterm{template-argument} of a
\grammarterm{template-id} are looked up in the context in which the entire
\grammarterm{postfix-expression} occurs;

\item the lookup for a name specified in a
\grammarterm{using-declaration}\iref{namespace.udecl} also finds class or
enumeration names hidden within the same
scope\iref{basic.scope.hiding}.
\end{itemize}

\pnum
In a lookup in which function names are not ignored\footnote{Lookups in which
function names are ignored include names appearing in a
\grammarterm{nested-name-specifier}, an
\grammarterm{elaborated-type-specifier}, or a \grammarterm{base-specifier}.}
and the \grammarterm{nested-name-specifier} nominates a class \tcode{C}:
\begin{itemize}
\item if the name specified after the \grammarterm{nested-name-specifier},
when looked up in \tcode{C}, is the injected-class-name of \tcode{C}\iref{class.pre}, or
\item
in a \grammarterm{using-declarator} of
a \grammarterm{using-declaration}\iref{namespace.udecl} that is a \grammarterm{member-declaration},
if the name specified after the \grammarterm{nested-name-specifier} is the same as the
\grammarterm{identifier} or the \grammarterm{simple-template-id}'s
\grammarterm{template-name} in the last component of the \grammarterm{nested-name-specifier},
\end{itemize}
the name is instead considered to name the
constructor of class \tcode{C}.
\begin{note}
For example, the constructor
is not an acceptable lookup result in an
\grammarterm{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 \grammarterm{declarator-id} of a declaration
that names a constructor or in a \grammarterm{using-declaration}.
\begin{example}
\begin{codeblock}
struct A { A(); };
struct B: public A { B(); };

A::A() { }
B::B() { }

B::A ba;            // object of type \tcode{A}
A::A a;             // error, \tcode{A::A} is not a type name
struct A::A a2;     // object of type \tcode{A}
\end{codeblock}
\end{example}

\pnum
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 \tcode{::} operator.

\rSec3[namespace.qual]{Namespace members}

\pnum
\indextext{lookup!namespace member}%
If the \grammarterm{nested-name-specifier} of a \grammarterm{qualified-id}
nominates a namespace (including the case where the
\grammarterm{nested-name-specifier} is \tcode{::}, i.e., nominating
the global namespace), the name specified after the
\grammarterm{nested-name-specifier} is looked up in the scope of the
namespace.
The names in a \grammarterm{template-argument} of a
\grammarterm{template-id} are looked up in the context in which the
entire \grammarterm{postfix-expression} occurs.

\pnum
For a namespace \tcode{X} and name \tcode{m}, the namespace-qualified lookup set
$S(X, m)$ is defined as follows: Let $S'(X, m)$ be the set of all
declarations of \tcode{m} in \tcode{X} and the inline namespace set of
\tcode{X}\iref{namespace.def}
whose potential scope\iref{basic.scope.namespace}
would include the namespace in which \tcode{m} is declared
at the location of the \grammarterm{nested-name-specifier}.
If $S'(X, m)$ is not empty, $S(X, m)$
is $S'(X, m)$; otherwise, $S(X, m)$ is the union of $S(N_i, m)$ for
all namespaces $N_i$ nominated by \grammarterm{using-directive}{s} in
\tcode{X} and its inline namespace set.

\pnum
Given \tcode{X::m} (where \tcode{X} is a user-declared namespace), or
given \tcode{::m} (where X is the global namespace), if
$S(X, m)$ is the empty set, the program is ill-formed. Otherwise, if
$S(X, m)$ has exactly one member, or if the context of the reference is
a \grammarterm{using-declaration}\iref{namespace.udecl}, $S(X, m)$
is the
required set of declarations of \tcode{m}. Otherwise if the use of
\tcode{m} is not one that allows a unique declaration to be chosen from
$S(X, m)$, the program is ill-formed.
\begin{example}
\begin{codeblock}
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();          // \tcode{g} is declared directly in \tcode{AB}, therefore \tcode{S} is $\{ \tcode{AB::g()} \}$ and \tcode{AB::g()} is chosen

  AB::f(1);         // \tcode{f} is not declared directly in \tcode{AB} so the rules are applied recursively to \tcode{A} and \tcode{B};
                    // namespace \tcode{Y} is not searched and \tcode{Y::f(float)} is not considered;
                    // \tcode{S} is $\{ \tcode{A::f(int)}, \tcode{B::f(char)} \}$ and overload resolution chooses \tcode{A::f(int)}

  AB::f('c');       // as above but resolution chooses \tcode{B::f(char)}

  AB::x++;          // \tcode{x} is not declared directly in \tcode{AB}, and is not declared in \tcode{A} or \tcode{B}, so the rules
                    // are applied recursively to \tcode{Y} and \tcode{Z}, \tcode{S} is $\{ \}$ so the program is ill-formed

  AB::i++;          // \tcode{i} is not declared directly in \tcode{AB} so the rules are applied recursively to \tcode{A} and \tcode{B},
                    // \tcode{S} is $\{ \tcode{A::i}, \tcode{B::i} \}$ so the use is ambiguous and the program is ill-formed

  AB::h(16.8);      // \tcode{h} is not declared directly in \tcode{AB} and not declared directly in \tcode{A} or \tcode{B} so the rules
                    // are applied recursively to \tcode{Y} and \tcode{Z}, \tcode{S} is $\{ \tcode{Y::h(int)}, \tcode{Z::h(double)} \}$ and
                    // overload resolution chooses \tcode{Z::h(double)}
}
\end{codeblock}
\end{example}

\pnum
\begin{note}
The same declaration found more than once is not an ambiguity (because
it is still a unique declaration).
\begin{example}
\begin{codeblock}
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: \tcode{S} is $\{ \tcode{A::a}, \tcode{A::a} \}$
}

namespace D {
  using A::a;
}

namespace BD {
  using namespace B;
  using namespace D;
}

void g()
{
  BD::a++;          // OK: \tcode{S} is $\{ \tcode{A::a}, \tcode{A::a} \}$
}
\end{codeblock}
\end{example}
\end{note}

\pnum
\begin{example}
Because each referenced namespace is searched at most once, the
following is well-defined:
\begin{codeblock}
namespace B {
  int b;
}

namespace A {
  using namespace B;
  int a;
}

namespace B {
  using namespace A;
}

void f()
{
  A::a++;           // OK: \tcode{a} declared directly in \tcode{A}, \tcode{S} is $\{ \tcode{A::a} \}$
  B::a++;           // OK: both \tcode{A} and \tcode{B} searched (once), \tcode{S} is $\{ \tcode{A::a} \}$
  A::b++;           // OK: both \tcode{A} and \tcode{B} searched (once), \tcode{S} is $\{ \tcode{B::b} \}$
  B::b++;           // OK: \tcode{b} declared directly in \tcode{B}, \tcode{S} is $\{ \tcode{B::b} \}$
}
\end{codeblock}
\end{example}

\pnum
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.
\begin{example}
\begin{codeblock}
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, \tcode{A::x} (of type \tcode{int})
  int j = C::y;     // ambiguous, \tcode{A::y} or \tcode{B::y}
}
\end{codeblock}
\end{example}

\pnum
In a declaration for a namespace member in which the
\grammarterm{declarator-id} is a \grammarterm{qualified-id}, given that the
\grammarterm{qualified-id} for the namespace member has the form
\begin{ncbnf}
nested-name-specifier unqualified-id
\end{ncbnf}
the
\grammarterm{unqualified-id} shall name a member of the namespace
designated by the \grammarterm{nested-name-specifier}
or of an element of the inline namespace set\iref{namespace.def} of that namespace.
\begin{example}
\begin{codeblock}
namespace A {
  namespace B {
    void f1(int);
  }
  using namespace B;
}
void A::f1(int){ }  // ill-formed, \tcode{f1} is not a member of \tcode{A}
\end{codeblock}
\end{example}
However, in such namespace member declarations, the
\grammarterm{nested-name-specifier} may rely on \grammarterm{using-directive}{s}
to implicitly provide the initial part of the
\grammarterm{nested-name-specifier}.
\begin{example}
\begin{codeblock}
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 \tcode{A::B::f1(int)}
\end{codeblock}
\end{example}
\indextext{lookup!qualified name|)}%

\rSec2[basic.lookup.elab]{Elaborated type specifiers}%
\indextext{lookup!elaborated type specifier|(}%
\indextext{type specifier!elaborated}

\pnum
An \grammarterm{elaborated-type-specifier}\iref{dcl.type.elab} may be
used to refer to a previously declared \grammarterm{class-name} or
\grammarterm{enum-name} even though the name has been hidden by a non-type
declaration\iref{basic.scope.hiding}.

\pnum
If the \grammarterm{elaborated-type-specifier} has no
\grammarterm{nested-name-specifier}, and unless the
\grammarterm{elaborated-type-specifier} appears in a declaration with the
following form:
\begin{ncbnf}
class-key \opt{attribute-specifier-seq} identifier \terminal{;}
\end{ncbnf}
the \grammarterm{identifier} is looked up according
to~\ref{basic.lookup.unqual} but ignoring any non-type names that have
been declared. If the \grammarterm{elaborated-type-specifier} is introduced
by the \tcode{enum} keyword and this lookup does not find a previously
declared \grammarterm{type-name}, the \grammarterm{elaborated-type-specifier}
is ill-formed. If the \grammarterm{elaborated-type-specifier} is introduced
by the \grammarterm{class-key} and this lookup does not find a previously
declared \grammarterm{type-name}, or if the
\grammarterm{elaborated-type-specifier} appears in a declaration with the
form:
\begin{ncbnf}
class-key \opt{attribute-specifier-seq} identifier \terminal{;}
\end{ncbnf}
the \grammarterm{elaborated-type-specifier} is a declaration that
introduces the \grammarterm{class-name} as described
in~\ref{basic.scope.pdecl}.

\pnum
If the \grammarterm{elaborated-type-specifier} has a
\grammarterm{nested-name-specifier}, qualified name lookup is performed, as
described in~\ref{basic.lookup.qual}, but ignoring any non-type names
that have been declared. If the name lookup does not find a previously
declared \grammarterm{type-name}, the \grammarterm{elaborated-type-specifier}
is ill-formed.

\pnum
\begin{example}
\begin{codeblock}
struct Node {
  struct Node* Next;            // OK: Refers to injected-class-name \tcode{Node}
  struct Data* Data;            // OK: Declares type \tcode{Data} at global scope and member \tcode{Data}
};

struct Data {
  struct Node* Node;            // OK: Refers to \tcode{Node} at global scope
  friend struct ::Glob;         // error: \tcode{Glob} is not declared, cannot introduce a qualified type\iref{dcl.type.elab}
  friend struct Glob;           // OK: Refers to (as yet) undeclared \tcode{Glob} at global scope.
  @\commentellip@
};

struct Base {
  struct Data;                  // OK: Declares nested \tcode{Data}
  struct ::Data*     thatData;  // OK: Refers to \tcode{::Data}
  struct Base::Data* thisData;  // OK: Refers to nested \tcode{Data}
  friend class ::Data;          // OK: global \tcode{Data} is a friend
  friend class Data;            // OK: nested \tcode{Data} is a friend
  struct Data { @\commentellip@ };    // Defines nested \tcode{Data}
};

struct Data;                    // OK: Redeclares \tcode{Data} at global scope
struct ::Data;                  // error: cannot introduce a qualified type\iref{dcl.type.elab}
struct Base::Data;              // error: cannot introduce a qualified type\iref{dcl.type.elab}
struct Base::Datum;             // error: \tcode{Datum} undefined
struct Base::Data* pBase;       // OK: refers to nested \tcode{Data}
\end{codeblock}
\end{example}
\indextext{lookup!elaborated type specifier|)}%

\rSec2[basic.lookup.classref]{Class member access}

\pnum
\indextext{lookup!class member}%
In a class member access expression\iref{expr.ref}, if the \tcode{.}
or \tcode{->} token is immediately followed by an \grammarterm{identifier}
followed by a \tcode{<}, the identifier must be looked up to determine
whether the \tcode{<} is the beginning of a template argument
list\iref{temp.names} or a less-than operator. The identifier is first
looked up in the class of the object expression\iref{class.member.lookup}.
If the identifier is not found,
it is then looked up in the context of the entire
\grammarterm{postfix-expression} and shall name a template
whose specializations are types.

\pnum
If the \grammarterm{id-expression} in a class member
access\iref{expr.ref} is an \grammarterm{unqualified-id}, and the type of
the object expression is of a class type \tcode{C}, the
\grammarterm{unqualified-id} is looked up
in the scope of class \tcode{C}\iref{class.member.lookup}.

\pnum
If the \grammarterm{unqualified-id} is \tcode{\~}\grammarterm{type-name}, the
\grammarterm{type-name} is looked up in the context of the entire
\grammarterm{postfix-expression}. If the type \tcode{T} of the object
expression is of a class type \tcode{C}, the \grammarterm{type-name} is
also looked up in the scope of class \tcode{C}. At least one of the
lookups shall find a name that refers to \cv{}~\tcode{T}.
\begin{example}
\begin{codeblock}
struct A { };

struct B {
  struct A { };
  void f(::A* a);
};

void B::f(::A* a) {
  a->~A();                      // OK: lookup in \tcode{*a} finds the injected-class-name
}
\end{codeblock}
\end{example}

\pnum
If the \grammarterm{id-expression} in a class member access is a
\grammarterm{qualified-id} of the form
\begin{codeblock}
@\placeholder{class-name-or-namespace-name}@::...
\end{codeblock}
the \tcode{\placeholder{class-name-or-namespace-name}} following the \tcode{.} or
\tcode{->} operator is
first looked up in the class of the object expression\iref{class.member.lookup}
and the name, if found,
is used. Otherwise it is looked up in the context of the entire
\grammarterm{postfix-expression}.
\begin{note}
See~\ref{basic.lookup.qual}, which
describes the lookup of a name before \tcode{::}, which will only find a type
or namespace name.
\end{note}

\pnum
If the \grammarterm{qualified-id} has the form
\begin{codeblock}
::@\placeholder{class-name-or-namespace-name}@::...
\end{codeblock}
the \tcode{\placeholder{class-name-or-namespace-name}} is looked up in global scope
as a \grammarterm{class-name} or \grammarterm{namespace-name}.

\pnum
If the \grammarterm{nested-name-specifier} contains a
\grammarterm{simple-template-id}\iref{temp.names}, the names in its
\grammarterm{template-argument}{s} are looked up in the context in which the
entire \grammarterm{postfix-expression} occurs.

\pnum
If the \grammarterm{id-expression} is a \grammarterm{conversion-function-id},
its \grammarterm{conversion-type-id}
is first looked up
in the class of the object expression\iref{class.member.lookup}
and the name, if
found, is used. Otherwise it is looked up in the context
of the entire \grammarterm{postfix-expression}.
In each of these lookups, only names that denote types or templates whose
specializations are types are considered.
\begin{example}
\begin{codeblock}
struct A { };
namespace N {
  struct A {
    void g() { }
    template <class T> operator T();
  };
}

int main() {
  N::A a;
  a.operator A();               // calls \tcode{N::A::operator N::A}
}
\end{codeblock}
\end{example}

\rSec2[basic.lookup.udir]{Using-directives and namespace aliases}

\pnum
\indextext{lookup!using-directives and}%
\indextext{lookup!namespace aliases and}%
In a \grammarterm{using-directive} or \grammarterm{namespace-alias-definition},
during the lookup for a \grammarterm{namespace-name} or for a name in a
\grammarterm{nested-name-specifier}{}
only namespace names are considered.%
\indextext{lookup!name|)}%
\indextext{scope!name lookup and|)}

\rSec1[basic.link]{Program and linkage}%
\indextext{linkage|(}

\pnum
\indextext{program}%
A \defn{program} consists of one or more translation units\iref{lex.separate}
linked together. A translation unit consists
of a sequence of declarations.

\begin{bnf}
\nontermdef{translation-unit}\br
    \opt{top-level-declaration-seq}\br
    \opt{global-module-fragment} module-declaration \opt{top-level-declaration-seq} \opt{private-module-fragment}
\end{bnf}

\begin{bnf}
\nontermdef{top-level-declaration-seq}\br
    top-level-declaration\br
    top-level-declaration-seq top-level-declaration
\end{bnf}

\begin{bnf}
\nontermdef{top-level-declaration}\br
    module-import-declaration\br
    declaration
\end{bnf}

\pnum
A token sequence beginning with
\opt{\tcode{export}} \tcode{module}
and not immediately followed by \tcode{::}
is never interpreted as the \grammarterm{declaration}
of a \grammarterm{top-level-declaration}.

\pnum
\indextext{linkage}%
\indextext{translation unit}%
\indextext{linkage!internal}%
\indextext{linkage!external}%
A name is said to have \defn{linkage} when it might denote the same
object, reference, function, type, template, namespace or value as a
name introduced by a declaration in another scope:
\begin{itemize}
\item When a name has \indextext{linkage!external}\defn{external linkage},
the entity it denotes
can be referred to by names from scopes of other translation units or
from other scopes of the same translation unit.

\item When a name has \defnx{module linkage}{linkage!module},
the entity it denotes
can be referred to by names from other scopes of the same module unit\iref{module.unit} or
from scopes of other module units of that same module.

\item When a name has \indextext{linkage!internal}\defn{internal linkage},
the entity it denotes
can be referred to by names from other scopes in the same translation
unit.

\item When a name has \indextext{linkage!no}\defn{no linkage}, the entity it denotes
cannot be referred to by names from other scopes.
\end{itemize}

\pnum
\indextext{linkage!\idxcode{static} and}%
\indextext{\idxcode{static}!linkage of}%
\indextext{linkage!\idxcode{const} and}%
\indextext{\idxcode{const}!linkage of}%
\indextext{linkage!\idxcode{inline} and}%
\indextext{\idxcode{inline}!linkage of}%
A name having namespace scope\iref{basic.scope.namespace} has internal
linkage if it is the name of
\begin{itemize}
\item
  a variable, variable template, function, or function template that is
  explicitly declared \tcode{static}; or
\item
  a non-template variable of non-volatile const-qualified type, unless
  \begin{itemize}
  \item it is explicitly declared \tcode{extern}, or
  \item it is inline or exported, or
  \item it was previously declared and the prior declaration did
  not have internal linkage; or
  \end{itemize}
\item
  a data member of an anonymous union.
\end{itemize}
\begin{note}
An instantiated variable template that has const-qualified type
can have external or module linkage, even if not declared \tcode{extern}.
\end{note}

\pnum
An unnamed namespace or a namespace declared directly or indirectly within an
unnamed namespace has internal linkage. All other namespaces have external linkage.
A name having namespace scope
that has not been given internal linkage above
and that is the name of
\begin{itemize}
\item a variable; or
\item a function; or
\item \indextext{class!linkage of}%
a named class\iref{class.pre}, or an unnamed class defined in a
typedef declaration in which the class has the typedef name for linkage
purposes\iref{dcl.typedef}; or
\item \indextext{enumeration!linkage of}%
a named enumeration\iref{dcl.enum}, or an unnamed enumeration defined
in a typedef declaration in which the enumeration has the typedef name
for linkage purposes\iref{dcl.typedef}; or
\item a template
\end{itemize}
has its linkage determined as follows:
\begin{itemize}
\item
if the enclosing namespace has internal linkage,
the name has internal linkage;
\item
otherwise,
if the declaration of the name is
attached to a named module\iref{module.unit}
and is not exported\iref{module.interface},
the name has module linkage;
\item
otherwise,
the name has external linkage.
\end{itemize}

\pnum
In addition, a member function, static data member, a named class or
enumeration of class scope, or an unnamed class or enumeration defined
in a class-scope typedef declaration such that the class or enumeration
has the typedef name for linkage purposes\iref{dcl.typedef}, has
the same linkage, if any, as the name of the class of which it is a
member.

\pnum
The name of a function declared in block scope and
the name of a variable declared by a block scope \tcode{extern} declaration
have linkage.
If such a declaration is attached to a named module,
the program is ill-formed.
If there is a visible declaration
of an entity with linkage, ignoring entities declared
outside the innermost enclosing namespace scope,
such that the block scope declaration would be
a (possibly ill-formed) redeclaration
if the two declarations appeared in the same declarative region,
the block scope declaration declares
that same entity and receives the linkage of the previous declaration. If there is more
than one such matching entity, the program is ill-formed. Otherwise, if no matching
entity is found, the block scope entity receives external linkage.
If, within a translation unit, the same entity is declared with both
internal and external linkage, the program is ill-formed.
\begin{example}
\begin{codeblock}
static void f();
extern "C" void h();
static int i = 0;               // \#1
void g() {
  extern void f();              // internal linkage
  extern void h();              // C language linkage
  int i;                        // \#2: \tcode{i} has no linkage
  {
    extern void f();            // internal linkage
    extern int i;               // \#3: external linkage, ill-formed
  }
}
\end{codeblock}
Without the declaration at line \#2,
the declaration at line \#3 would link with the declaration at line \#1.
Because the declaration with internal linkage is hidden, however,
\#3 is given external linkage, making the program ill-formed.
\end{example}

\pnum
When a block scope declaration of an entity with linkage is not found to
refer to some other declaration, then that entity is a member of the
innermost enclosing namespace. However such a declaration does not
introduce the member name in its namespace scope.
\begin{example}
\begin{codeblock}
namespace X {
  void p() {
    q();                        // error: \tcode{q} not yet declared
    extern void q();            // \tcode{q} is a member of namespace \tcode{X}
  }

  void middle() {
    q();                        // error: \tcode{q} not yet declared
  }

  void q() { @\commentellip@ }        // definition of \tcode{X::q}
}

void q() { @\commentellip@ }          // some other, unrelated \tcode{q}
\end{codeblock}
\end{example}

\pnum
\indextext{linkage!no}%
Names not covered by these rules have no linkage. Moreover, except as
noted, a name declared at block scope\iref{basic.scope.block} has no
linkage.

\pnum
Two names that are the same\iref{basic.pre} and that are declared
in different scopes shall denote the same variable, function,
type, template or namespace if
\begin{itemize}
\item both names have external or module linkage
and are declared in declarations attached to the same module,
or else both names have internal linkage
and are declared in the same translation unit; and

\item both names refer to members of the same namespace or to members,
not by inheritance, of the same class; and

\item when both names denote functions or function templates,
the signatures~(\ref{defns.signature}, \ref{defns.signature.templ})
are the same.

\end{itemize}
If multiple declarations of the same name with external linkage
would declare the same entity except that
they are attached to different modules,
the program is ill-formed; no diagnostic is required.
\begin{note}
\grammarterm{using-declaration}{s},
typedef declarations,
and \grammarterm{alias-declaration}{s}
do not declare entities, but merely introduce synonyms.
Similarly,
\grammarterm{using-directive}{s}
do not declare entities.
\end{note}

\pnum
If a declaration would redeclare a reachable declaration
attached to a different module, the program is ill-formed.
\begin{example}
\begin{codeblocktu}{\tcode{"decls.h"}}
int f();            // \#1, attached to the global module
int g();            // \#2, attached to the global module
\end{codeblocktu}

\begin{codeblocktu}{Module interface of \tcode{M}}
module;
#include "decls.h"
export module M;
export using ::f;   // OK: does not declare an entity, exports \#1
int g();            // error: matches \#2, but attached to \tcode{M}
export int h();     // \#3
export int k();     // \#4
\end{codeblocktu}

\begin{codeblocktu}{Other translation unit}
import M;
static int h();     // error: matches \#3
int k();            // error: matches \#4
\end{codeblocktu}
\end{example}
As a consequence of these rules,
all declarations of an entity are attached to the same module;
the entity is said to be \defnx{attached}{attached!entity} to that module.

\pnum
\indextext{consistency!type declaration}%
\indextext{declaration!multiple}%
After all adjustments of types (during which
typedefs\iref{dcl.typedef} are replaced by their definitions), the
types specified by all declarations referring to a given variable or
function shall be identical, except that declarations for an array
object can specify array types that differ by the presence or absence of
a major array bound\iref{dcl.array}. A violation of this rule on type
identity does not require a diagnostic.

\pnum
\begin{note}
Linkage to non-\Cpp{} declarations can be achieved using a
\grammarterm{linkage-specification}\iref{dcl.link}.
\end{note}
\indextext{linkage|)}

\rSec1[basic.memobj]{Memory and objects}

\rSec2[intro.memory]{Memory model}

\pnum
\indextext{memory model|(}%
The fundamental storage unit in the \Cpp{} memory model is the
\defn{byte}.
A byte is at least large enough to contain any member of the basic
\indextext{character set!basic execution}%
execution character set\iref{lex.charset}
and the eight-bit code units of the Unicode UTF-8 encoding form
and is composed of a contiguous sequence of
bits,\footnote{The number of bits in a byte is reported by the macro
\tcode{CHAR_BIT} in the header \libheaderref{climits}.}
the number of which is \impldef{bits in a byte}. The least
significant bit is called the \defn{low-order bit}; the most
significant bit is called the \defn{high-order bit}. The memory
available to a \Cpp{} program consists of one or more sequences of
contiguous bytes. Every byte has a unique address.

\pnum
\begin{note}
The representation of types is described
in~\ref{basic.types}.
\end{note}

\pnum
A \defn{memory location} is either an object of scalar type or a maximal
sequence of adjacent bit-fields all having nonzero width.
\begin{note}
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\iref{intro.multithread} can access separate memory
locations without interfering with each other.

\pnum
\begin{note}
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}

\pnum
\begin{example}
A class declared as
\begin{codeblock}
struct {
  char a;
  int b:5,
  c:11,
  :0,
  d:8;
  struct {int ee:8;} e;
}
\end{codeblock}
contains four separate memory locations: The member \tcode{a} and bit-fields
\tcode{d} and \tcode{e.ee} are each separate memory locations, and can be
modified concurrently without interfering with each other. The bit-fields
\tcode{b} and \tcode{c} together constitute the fourth memory location. The
bit-fields \tcode{b} and \tcode{c} cannot be concurrently modified, but
\tcode{b} and \tcode{a}, for example, can be.
\end{example}
\indextext{memory model|)}

\rSec2[intro.object]{Object model}

\pnum
\indextext{object model|(}%
The constructs in a \Cpp{} program create, destroy, refer to, access, and
manipulate objects.
An \defn{object} is created
by a definition\iref{basic.def},
by a \grammarterm{new-expression}\iref{expr.new},
when implicitly changing the active member of a union\iref{class.union},
or
when a temporary object is created~(\ref{conv.rval}, \ref{class.temporary}).
An object occupies a region of storage
in its period of construction\iref{class.cdtor},
throughout its lifetime\iref{basic.life},
and
in its period of destruction\iref{class.cdtor}.
\begin{note}
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\iref{basic.pre}. An object has a storage
duration\iref{basic.stc} which influences its
lifetime\iref{basic.life}. An object has a
type\iref{basic.types}.
Some objects are
polymorphic\iref{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 \grammarterm{expression}{s}\iref{expr.compound}
used to access them.

\pnum
\indextext{subobject}%
Objects can contain other objects, called \defnx{subobjects}{subobject}.
A subobject can be
a \defn{member subobject}\iref{class.mem}, a \defn{base class subobject}\iref{class.derived},
or an array element.
\indextext{object!complete}%
An object that is not a subobject of any other object is called a \defn{complete
object}.
If an object is created
in storage associated with a member subobject or array element \placeholder{e}
(which may or may not be within its lifetime),
the created object
is a subobject of \placeholder{e}'s containing object if:
\begin{itemize}
\item
the lifetime of \placeholder{e}'s containing object has begun and not ended, and
\item
the storage for the new object exactly overlays the storage location associated with \placeholder{e}, and
\item
the new object is of the same type as \placeholder{e} (ignoring cv-qualification).
\end{itemize}

\pnum
\indextext{object!providing storage for}%
If a complete object is created\iref{expr.new}
in storage associated with another object \placeholder{e}
of type ``array of $N$ \tcode{unsigned char}'' or
of type ``array of $N$ \tcode{std::byte}''\iref{cstddef.syn},
that array \defn{provides storage}
for the created object if:
\begin{itemize}
\item
the lifetime of \placeholder{e} has begun and not ended, and
\item
the storage for the new object fits entirely within \placeholder{e}, and
\item
there is no smaller array object that satisfies these constraints.
\end{itemize}
\begin{note}
If that portion of the array
previously provided storage for another object,
the lifetime of that object ends
because its storage was reused\iref{basic.life}.
\end{note}
\begin{example}
\begin{codeblock}
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, \tcode{au.data} provides storage
  char *c = new (au.data) char();       // OK, ends lifetime of \tcode{*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;                 // \tcode{a.a} provides storage for \tcode{*b}
int *p = new (b->b + 4) int;            // \tcode{b->b} provides storage for \tcode{*p}
                                        // \tcode{a.a} does not provide storage for \tcode{*p} (directly),
                                        // but \tcode{*p} is nested within \tcode{a} (see below)
\end{codeblock}
\end{example}

\pnum
\indextext{object!nested within}%
An object \placeholder{a} is \defn{nested within} another object \placeholder{b} if:
\begin{itemize}
\item
\placeholder{a} is a subobject of \placeholder{b}, or
\item
\placeholder{b} provides storage for \placeholder{a}, or
\item
there exists an object \placeholder{c}
where \placeholder{a} is nested within \placeholder{c},
and \placeholder{c} is nested within \placeholder{b}.
\end{itemize}

\pnum
For every object \tcode{x}, there is some object called the
\defn{complete object of} \tcode{x}, determined as follows:
\begin{itemize}
\item
If \tcode{x} is a complete object, then the complete object
of \tcode{x} is itself.

\item
Otherwise, the complete object of \tcode{x} is the complete object
of the (unique) object that contains \tcode{x}.
\end{itemize}

\pnum
If a complete object, a data member\iref{class.mem}, or an array element is of
class type, its type is considered the \defn{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
\defn{most derived object}.

\pnum
A \defn{potentially-overlapping subobject} is either:
\begin{itemize}
\item a base class subobject, or
\item a non-static data member
declared with the \tcode{no_unique_address} attribute\iref{dcl.attr.nouniqueaddr}.
\end{itemize}

\pnum
\indextext{object!zero size}%
\indextext{object!nonzero size}%
An object has nonzero size if it
\begin{itemize}
\item is not a potentially-overlapping subobject, or
\item is not of class type, or
\item is of a class type with virtual member functions or virtual base classes, or
\item has subobjects of nonzero size or bit-fields of nonzero length.
\end{itemize}
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 \impldef{which non-standard-layout objects
containing no data are considered empty}.
\indextext{most derived object!bit-field}%
Unless it is a bit-field\iref{class.bit},
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\iref{basic.types} shall occupy contiguous bytes of
storage.

\pnum
\indextext{most derived object!bit-field}%
\indextext{most derived object!zero size subobject}%
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.\footnote{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\iref{intro.execution}.}
\begin{example}
\begin{codeblock}
static const char test1 = 'x';
static const char test2 = 'x';
const bool b = &test1 != &test2;        // always \tcode{true}
\end{codeblock}
\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.

\pnum
\begin{note}
\Cpp{} provides a variety of fundamental types and several ways of composing
new types from existing types\iref{basic.types}.
\end{note}
\indextext{object model|)}

\rSec2[basic.life]{Object and reference lifetime}

\pnum
\indextext{object lifetime|(}%
The \defn{lifetime} of an object or reference is a runtime property of the
object or reference.
\indextext{initialization!vacuous}%
A variable is said to have \defn{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 \tcode{T} begins when:
\begin{itemize}
\item storage with the proper alignment and size
  for type \tcode{T} is obtained, and
\item its initialization (if any) is complete
  (including vacuous initialization)\iref{dcl.init},
\end{itemize}
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~(\ref{dcl.init.aggr}, \ref{class.base.init}),
or as described in \ref{class.union}.
The lifetime of an object \placeholder{o} of type \tcode{T} ends when:
\begin{itemize}
\item if \tcode{T} is a non-class type, the object is destroyed, or
\item if \tcode{T} is a class type, the destructor call starts, or
\item the storage which the object occupies is released,
or is reused by an object that is not nested within \placeholder{o}\iref{intro.object}.
\end{itemize}

\pnum
\indextext{reference lifetime}%
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.

\pnum
\begin{note}
\ref{class.base.init}
describes the lifetime of base and member subobjects.
\end{note}

\pnum
The properties ascribed to objects and references throughout this document
apply for a given object or reference only during its lifetime.
\begin{note}
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~\ref{class.base.init} and
in~\ref{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. \ref{class.base.init}
and~\ref{class.cdtor} describe the behavior of an object during its periods
of construction and destruction.
\end{note}

\pnum
A program may end the lifetime of any object by reusing the storage
which the object occupies or by explicitly calling the destructor for an
object of a class type.
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 \grammarterm{delete-expression}\iref{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.

\pnum
Before the lifetime of an object has started but after the storage which
the object will occupy has been allocated\footnote{For example, before the
construction of a global object
that is initialized via a user-provided constructor\iref{class.cdtor}.}
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~\ref{class.cdtor}.
Otherwise, such
a pointer refers to allocated
storage\iref{basic.stc.dynamic.allocation}, and using the pointer as
if the pointer were of type \tcode{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:
\begin{itemize}
\item
  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 \grammarterm{delete-expression},
\item
  the pointer is used to access a non-static data member or call a
  non-static member function of the object, or
\item
  the pointer is implicitly converted\iref{conv.ptr} to a pointer
  to a virtual base class, or
\item
  the pointer is used as the operand of a
  \tcode{static_cast}\iref{expr.static.cast}, except when the conversion
  is to pointer to \cv{}~\tcode{void}, or to pointer to \cv{}~\tcode{void}
  and subsequently to pointer to
  \cv{}~\tcode{char},
  \cv{}~\tcode{unsigned char}, or
  \cv{}~\tcode{std::byte}\iref{cstddef.syn}, or
\item
  the pointer is used as the operand of a
  \tcode{dynamic_cast}\iref{expr.dynamic.cast}.
\end{itemize}
\begin{example}
\begin{codeblock}
#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 \tcode{*this}
  f();              // undefined behavior
  ... = this;       // OK, \tcode{this} points to valid memory
}

void g() {
  void* p = std::malloc(sizeof(D1) + sizeof(D2));
  B* pb = new (p) D1;
  pb->mutate();
  *pb;              // OK: \tcode{pb} points to valid memory
  void* q = pb;     // OK: \tcode{pb} points to valid memory
  pb->f();          // undefined behavior, lifetime of \tcode{*pb} has ended
}
\end{codeblock}
\end{example}

\pnum
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~\ref{class.cdtor}.
Otherwise, such
a glvalue refers to
allocated storage\iref{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:
\begin{itemize}
\item the glvalue is used to access the object, or
\item the glvalue is used to call a non-static member function of the object, or
\item the glvalue is bound to a reference to a virtual base class\iref{dcl.init.ref}, or
\item the glvalue is used as the operand of a
\tcode{dynamic_cast}\iref{expr.dynamic.cast} or as the operand of
\tcode{typeid}.
\end{itemize}

\pnum
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:
\begin{itemize}
\item the storage for the new object exactly overlays the storage
location which the original object occupied, and

\item the new object is of the same type as the original object
(ignoring the top-level cv-qualifiers), and

\item the original object is neither
a complete object that is const-qualified nor
a subobject of such an object, and

\item neither the original object nor the new object
is a potentially-overlapping subobject\iref{intro.object}.
\end{itemize}
\begin{example}
\begin{codeblock}
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 \tcode{*this} ends
    new (this) C(other);        // new object of type \tcode{C} created
    f();                        // well-defined
  }
  return *this;
}

C c1;
C c2;
c1 = c2;                        // well-defined
c1.f();                         // well-defined; \tcode{c1} refers to a new object of type \tcode{C}
\end{codeblock}
\end{example}
\begin{note}
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 \tcode{std::launder}\iref{support.dynamic}.
\end{note}

\pnum
If a program ends the lifetime of an object of type \tcode{T} with
static\iref{basic.stc.static}, thread\iref{basic.stc.thread},
or automatic\iref{basic.stc.auto}
storage duration and if \tcode{T} has a non-trivial destructor,\footnote{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.}
the program must ensure that an object of the original type occupies
that same storage location when the implicit destructor call takes
place; otherwise the behavior of the program is undefined. This is true
even if the block is exited with an exception.
\begin{example}
\begin{codeblock}
class T { };
struct B {
   ~B();
};

void h() {
   B b;
   new (&b) T;
}                               // undefined behavior at block exit
\end{codeblock}
\end{example}

\pnum
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.
\begin{example}
\begin{codeblock}
struct B {
  B();
  ~B();
};

const B b;

void h() {
  b.~B();
  new (const_cast<B*>(&b)) const B;     // undefined behavior
}
\end{codeblock}
\end{example}

\pnum
In this subclause, ``before'' and ``after'' refer to the ``happens before''
relation\iref{intro.multithread}.
\begin{note}
Therefore, undefined behavior results
if an object that is being constructed in one thread is referenced from another
thread without adequate synchronization.
\end{note}
\indextext{object lifetime|)}

\rSec2[basic.indet]{Indeterminate values}

\pnum
\indextext{value!indeterminate}%
\indextext{indeterminate value}%
When storage for an object with automatic or dynamic storage duration
is obtained, the object has an \defnadj{indeterminate}{value}, and if
no initialization is performed for the object, that object retains an
indeterminate value until that value is replaced\iref{expr.ass}.
\begin{note}
Objects with static or thread storage duration are zero-initialized,
see~\ref{basic.start.static}.
\end{note}

\pnum
If an indeterminate value is produced by an evaluation,
the behavior is undefined except in the following cases:
\begin{itemize}
\item
  If an indeterminate value of
  unsigned ordinary character type\iref{basic.fundamental}
  or \tcode{std::byte} type\iref{cstddef.syn}
  is produced by the evaluation of:
  \begin{itemize}
  \item
    the second or third operand of a conditional expression\iref{expr.cond},
  \item
    the right operand of a comma expression\iref{expr.comma},
  \item
    the operand of a cast or conversion~(\ref{conv.integral},
    \ref{expr.type.conv}, \ref{expr.static.cast}, \ref{expr.cast})
    to an unsigned ordinary character type
    or \tcode{std::byte} type\iref{cstddef.syn}, or
  \item
    a discarded-value expression\iref{expr.context},
  \end{itemize}
  then the result of the operation is an indeterminate value.
\item
  If an indeterminate value of
  unsigned ordinary character type or \tcode{std::byte} type
  is produced by the evaluation of
  the right operand of a simple assignment operator\iref{expr.ass}
  whose first operand is an lvalue of
  unsigned ordinary character type or \tcode{std::byte} type,
  an indeterminate value replaces
  the value of the object referred to by the left operand.
\item
  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.
\item
  If an indeterminate value of
  unsigned ordinary character type or \tcode{std::byte} type
  is produced by the evaluation of the initialization expression
  when initializing an object of \tcode{std::byte} type,
  that object is initialized to an indeterminate value.
\end{itemize}
\begin{example}
\begin{codeblock}
int f(bool b) {
  unsigned char c;
  unsigned char d = c;          // OK, \tcode{d} has an indeterminate value
  int e = d;                    // undefined behavior
  return b ? d : 0;             // undefined behavior if \tcode{b} is \tcode{true}
}
\end{codeblock}
\end{example}

\rSec2[basic.stc]{Storage duration}

\pnum
\indextext{storage duration|(}%
The \defn{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:
\begin{itemize}
\item static storage duration
\item thread storage duration
\item automatic storage duration
\item dynamic storage duration
\end{itemize}

\pnum
\indextext{storage duration!static}%
\indextext{storage duration!thread}%
\indextext{storage duration!automatic}%
\indextext{storage duration!dynamic}%
Static, thread, and automatic storage durations are associated with objects
introduced by declarations\iref{basic.def} and implicitly created by
the implementation\iref{class.temporary}. The dynamic storage duration
is associated with objects created by a
\grammarterm{new-expression}\iref{expr.new}.

\pnum
The storage duration categories apply to references as well.

\pnum
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\iref{basic.compound}.
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
\impldef{any use of an invalid pointer other than to perform indirection or deallocate}
behavior.\footnote{Some implementations might define that
copying an invalid pointer value
causes a system-generated runtime fault.}

\rSec3[basic.stc.static]{Static storage duration}

\pnum
\indextext{storage duration!static}%
All variables which do not have dynamic storage duration, do not have thread
storage duration, and are not local
have \defn{static storage duration}. The
storage for these entities lasts for the duration of the
program~(\ref{basic.start.static}, \ref{basic.start.term}).

\pnum
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~\ref{class.copy.elision}.

\pnum
\indextext{object!local static@local \tcode{static}}%
The keyword \tcode{static} can be used to declare a local variable with
static storage duration.
\begin{note}
\ref{stmt.dcl} describes the
initialization of local \tcode{static} variables; \ref{basic.start.term}
describes the destruction of local \tcode{static} variables.
\end{note}

\pnum
\indextext{member!class static@class \tcode{static}}%
The keyword \tcode{static} applied to a class data member in a class
definition gives the data member static storage duration.

\rSec3[basic.stc.thread]{Thread storage duration}

\pnum
All variables declared with the \tcode{thread_local} keyword have
\defnadj{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.

\pnum
\begin{note}
A variable with thread storage duration is initialized as specified
in~\ref{basic.start.static}, \ref{basic.start.dynamic}, and \ref{stmt.dcl}
and, if constructed, is destroyed on thread exit\iref{basic.start.term}.
\end{note}

\rSec3[basic.stc.auto]{Automatic storage duration}

\pnum
\indextext{storage duration!local object}%
Block-scope variables
not explicitly declared \tcode{static}, \tcode{thread_local}, or \tcode{extern} have
\defnadj{automatic}{storage duration}. The storage
for these entities lasts until the block in which they are created exits.

\pnum
\begin{note}
These variables are initialized and destroyed as described in~\ref{stmt.dcl}.
\end{note}

\pnum
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~\ref{class.copy.elision}.

\rSec3[basic.stc.dynamic]{Dynamic storage duration}%
\indextext{storage duration!dynamic|(}

\pnum
Objects can be created dynamically during program
execution\iref{intro.execution}, using
\indextext{\idxcode{new}}%
\grammarterm{new-expression}{s}\iref{expr.new}, and destroyed using
\indextext{\idxcode{delete}}%
\grammarterm{delete-expression}{s}\iref{expr.delete}. A \Cpp{} implementation
provides access to, and management of, dynamic storage via the global
\defn{allocation functions} \tcode{operator new} and \tcode{operator
new[]} and the global \defn{deallocation functions} \tcode{operator
delete} and \tcode{operator delete[]}.
\begin{note}
The non-allocating forms described in \ref{new.delete.placement}
do not perform allocation or deallocation.
\end{note}

\pnum
The library provides default definitions for the global allocation and
deallocation functions. Some global allocation and deallocation
functions are replaceable\iref{new.delete}. A \Cpp{} 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\iref{replacement.functions}. The
following allocation and deallocation functions\iref{support.dynamic}
are implicitly declared in global scope in each translation unit of a
program.

\begin{codeblock}
[[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;
\end{codeblock}

These implicit declarations introduce only the function names
\tcode{operator} \tcode{new}, \tcode{operator} \tcode{new[]},
\tcode{op\-er\-a\-tor} \tcode{delete}, and \tcode{operator}
\tcode{delete[]}.
\begin{note}
The implicit declarations do not introduce
the names \tcode{std},
\tcode{std::size_t},
\tcode{std::align_val_t},
or any other names that the library uses to
declare these names. Thus, a \grammarterm{new-expression},
\grammarterm{delete-expression}, or function call that refers to one of
these functions without importing or including the header \libheaderref{new} is
well-formed. However, referring to \tcode{std}
or \tcode{std::size_t}
or \tcode{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\iref{class.free}.

\pnum
If the behavior of an allocation or deallocation function
does not satisfy the semantic constraints
specified in~\ref{basic.stc.dynamic.allocation}
and~\ref{basic.stc.dynamic.deallocation},
the behavior is undefined.

\rSec4[basic.stc.dynamic.allocation]{Allocation functions}

\pnum
\indextext{function!allocation}%
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 \tcode{void*}. The first
parameter shall have type \tcode{std::size_t}\iref{support.types}. The
first parameter shall not have an associated default
argument\iref{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.

\pnum
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\iref{conv.ptr}
\tcode{p0} different from any previously returned value \tcode{p1},
unless that value \tcode{p1} was subsequently passed to a
replaceable deallocation function.
Furthermore, for the library allocation functions
in~\ref{new.delete.single} and~\ref{new.delete.array},
\tcode{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.\footnote{The intent is
to have \tcode{operator new()} implementable by
calling \tcode{std::malloc()} or \tcode{std::calloc()}, so the rules are
substantially the same. \Cpp{} differs from C in requiring a zero request
to return a non-null pointer.}

\pnum
For an allocation function other than
a reserved placement allocation function\iref{new.delete.placement},
the pointer returned on a successful call
shall represent the address of storage that is aligned as follows:
\begin{itemize}
\item
  If the allocation function takes an argument
  of type \tcode{std::align_val_t},
  the storage will have the alignment specified
  by the value of this argument.
\item
  Otherwise, if the allocation function is named \tcode{operator new[]},
  the storage is aligned for any object that
  does not have new-extended alignment\iref{basic.align} and
  is no larger than the requested size.
\item
  Otherwise, the storage is aligned for any object that
  does not have new-extended alignment and is of the requested size.
\end{itemize}

\pnum
An allocation function that fails to allocate storage can invoke the
currently installed new-handler function\iref{new.handler}, if any.
\begin{note}
\indextext{\idxcode{new_handler}}%
A program-supplied allocation function can obtain the address of the
currently installed \tcode{new_handler} using the
\tcode{std::get_new_handler} function\iref{get.new.handler}.
\end{note}
An allocation function that has a non-throwing
exception specification\iref{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\iref{except.throw} of a type
that would match a handler\iref{except.handle} of type
\tcode{std::bad_alloc}\iref{bad.alloc}.

\pnum
A global allocation function is only called as the result of a new
expression\iref{expr.new}, or called directly using the function call
syntax\iref{expr.call}, or called indirectly to allocate storage for
a coroutine state\iref{dcl.fct.def.coroutine},
or called indirectly through calls to the
functions in the \Cpp{} standard library.
\begin{note}
In particular, a
global allocation function is not called to allocate storage for objects
with static storage duration\iref{basic.stc.static}, for objects or references
with thread storage duration\iref{basic.stc.thread}, for objects of
type \tcode{std::type_info}\iref{expr.typeid}, or for an
exception object\iref{except.throw}.
\end{note}

\rSec4[basic.stc.dynamic.deallocation]{Deallocation functions}

\pnum
\indextext{function!deallocation}%
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.

\pnum
A deallocation function
is a \defnadj{destroying}{operator delete}
if it has at least two parameters
and its second parameter
is of type \tcode{std::destroying_delete_t}.
A destroying operator delete
shall be a class member function named \tcode{operator delete}.
\begin{note}
Array deletion cannot use a destroying operator delete.
\end{note}

\pnum
\indextext{\idxcode{delete}!overloading and}%
Each deallocation function shall return \tcode{void}.
If the function is a destroying operator delete
declared in class type \tcode{C},
the type of its first parameter shall be \tcode{C*};
otherwise, the type of its first
parameter shall be \tcode{void*}. A deallocation function may have more
than one parameter.
\indextext{deallocation function!usual}%
A \defn{usual deallocation function} is a deallocation function
whose parameters after the first are
\begin{itemize}
\item
optionally, a parameter of type \tcode{std::destroying_delete_t}, then
\item
optionally, a parameter of type \tcode{std::size_t}%
\footnote{The global \tcode{operator delete(void*, std::size_t)}
precludes use of an
allocation function \tcode{void operator new(std::size_t, std::size_t)} as a placement
allocation function~(\ref{diff.cpp11.basic}).}, then
\item
optionally, a parameter of type \tcode{std::align_val_t}.
\end{itemize}
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.

\pnum
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.

\pnum
If the argument given to a deallocation function in the standard library
is a pointer that is not the null pointer value\iref{conv.ptr}, the
deallocation function shall deallocate the storage referenced by the
pointer, ending the duration of the region of storage.

\rSec4[basic.stc.dynamic.safety]{Safely-derived pointers}

\pnum
\indextext{pointer!safely-derived|(}%
\indextext{pointer!to traceable object}%
A \defn{traceable pointer object} is
\begin{itemize}
\item an object of an object pointer
type\iref{basic.compound}, or
\item an object of an integral type that is at least as large as \tcode{std::intptr_t},
or
\item a sequence of elements in an array of narrow character
type\iref{basic.fundamental}, where the size and alignment of the sequence
match those of some object pointer type.
\end{itemize}

\pnum
A pointer value is a \defn{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:
\begin{itemize}
\item the value returned by a call to the \Cpp{} standard library implementation of
\tcode{::operator new(std::\brk{}size_t)} or
\tcode{::operator new(std::size_t, std::align_val_t)}%
;\footnote{This subclause does not impose restrictions
on indirection through pointers to memory not allocated by \tcode{::operator new}. This
maintains the ability of many \Cpp{} 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 \tcode{std::malloc} is not restricted.}

\item 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;

\item the result of well-defined pointer arithmetic\iref{expr.add} using a safely-derived pointer
value;

\item the result of a well-defined pointer
conversion~(\ref{conv.ptr}, \ref{expr.type.conv}, \ref{expr.static.cast},
\ref{expr.cast}) of a safely-derived pointer value;

\item the result of a \tcode{reinterpret_cast} of a safely-derived pointer value;

\item the result of a \tcode{reinterpret_cast} of an integer representation of a
safely-derived pointer value;

\item 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.
\end{itemize}

\pnum
\indextext{integer representation}%
\indextext{pointer!integer representation of safely-derived}%
An integer value is an \defnx{integer representation of a safely-derived pointer}{safely-derived pointer!integer representation}
only if its type is at least as large as \tcode{std::intptr_t} and it is one of the
following:
\begin{itemize}
\item the result of a \tcode{reinterpret_cast} of a safely-derived pointer value;

\item the result of a valid conversion of an integer representation of a safely-derived
pointer value;

\item 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;

\item the result of an additive or bitwise operation, one of whose operands is an
integer representation of a safely-derived pointer value \tcode{P}, if that result
converted by \tcode{reinterpret_cast<void*>} would compare equal to a safely-derived
pointer computable from \tcode{reinterpret_cast<void*>(P)}.
\end{itemize}

\pnum
An implementation may have \defn{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 \defn{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\iref{util.dynamic.safety}.
\begin{note}
The effect of using an invalid pointer value (including passing it to a
deallocation function) is undefined, see~\ref{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
\impldef{whether an implementation has relaxed or strict pointer
safety} whether an implementation has relaxed or strict pointer safety.%
\indextext{pointer!safely-derived|)}%
\indextext{storage duration!dynamic|)}

\rSec3[basic.stc.inherit]{Duration of subobjects}

\pnum
\indextext{storage duration!class member}%
The storage duration of subobjects and reference members
is that of their complete object\iref{intro.object}.
\indextext{storage duration|)}%

\rSec2[basic.align]{Alignment}

\pnum
Object types have \defnx{alignment requirements}{alignment requirement!implementation-defined}~(\ref{basic.fundamental}, \ref{basic.compound})
which place restrictions on the addresses at which an object of that type
may be allocated. An \defn{alignment} is an \impldef{alignment}
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\iref{dcl.align}.

\pnum
\indextext{alignment!fundamental}%
A \defn{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
\tcode{alignof(std::max_align_t)}\iref{support.types}.
The alignment required for a type might be different when it is used as the type
of a complete object and when it is used as the type of a subobject.
\begin{example}
\begin{codeblock}
struct B { long double d; };
struct D : virtual B { char c; };
\end{codeblock}

When \tcode{D} is the type of a complete object, it will have a subobject of
type \tcode{B}, so it must be aligned appropriately for a \tcode{long double}.
If \tcode{D} appears as a subobject of another object that also has \tcode{B}
as a virtual base class, the \tcode{B} subobject might be part of a different
subobject, reducing the alignment requirements on the \tcode{D} subobject.
\end{example}
The result of the \tcode{alignof} operator reflects the alignment
requirement of the type in the complete-object case.

\pnum
\indextext{alignment!extended}%
\indextext{alignment!new-extended}%
\indextext{over-aligned type|see{type, over-aligned}}%
An \defn{extended alignment} is represented by an alignment
greater than \tcode{alignof(std::max_align_t)}. It is \impldef{support for extended alignments}
whether any extended alignments are supported and the contexts in which they are
supported\iref{dcl.align}. A type having an extended alignment
requirement is an \defnadj{over-aligned}{type}.
\begin{note}
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 \defn{new-extended alignment} is represented by
an alignment greater than \mname{STDCPP_DEFAULT_NEW_ALIGNMENT}\iref{cpp.predefined}.

\pnum
Alignments are represented as values of the type \tcode{std::size_t}.
Valid alignments include only those values returned by an \tcode{alignof}
expression for the fundamental types plus an additional \impldef{alignment additional
values}
set of values, which may be empty.
Every alignment value shall be a non-negative integral power of two.

\pnum
Alignments have an order from \defnx{weaker}{alignment!weaker} to
\defnx{stronger}{alignment!stronger} or \defnx{stricter}{alignment!stricter} alignments. Stricter
alignments have larger alignment values. An address that satisfies an alignment
requirement also satisfies any weaker valid alignment requirement.

\pnum
The alignment requirement of a complete type can be queried using an
\tcode{alignof} expression\iref{expr.alignof}. Furthermore,
the narrow character types\iref{basic.fundamental} shall have the weakest
alignment requirement.
\begin{note}
This enables the ordinary character types to be used as the
underlying type for an aligned memory area\iref{dcl.align}.
\end{note}

\pnum
Comparing alignments is meaningful and provides the obvious results:

\begin{itemize}
\item Two alignments are equal when their numeric values are equal.
\item Two alignments are different when their numeric values are not equal.
\item When an alignment is larger than another it represents a stricter alignment.
\end{itemize}

\pnum
\begin{note}
The runtime pointer alignment function\iref{ptr.align}
can be used to obtain an aligned pointer within a buffer; the aligned-storage templates
in the library\iref{meta.trans.other} can be used to obtain aligned storage.
\end{note}

\pnum
If a request for a specific extended alignment in a specific context is not
supported by an implementation, the program is ill-formed.

\rSec2[class.temporary]{Temporary objects}

\pnum
\indextext{object temporary|see{temporary}}%
\indextext{temporary}%
\indextext{optimization of temporary|see{temporary, elimination of}}%
\indextext{temporary!elimination of}%
\indextext{temporary!implementation-defined generation of}%
Temporary objects are created
\begin{itemize}
\item
when a prvalue is converted to an xvalue\iref{conv.rval},
\item
when needed by the implementation to pass or return an object of trivially-copyable type (see below),
and
\item
when throwing an exception\iref{except.throw}.
\begin{note}
The lifetime of exception objects is described in~\ref{except.throw}.
\end{note}
\end{itemize}
Even when the creation of the temporary object is
unevaluated\iref{expr.prop},
all the semantic restrictions shall be respected as if the temporary object
had been created and later destroyed.
\begin{note}
This includes accessibility\iref{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
\grammarterm{decltype-specifier}\iref{expr.call}, no temporary is introduced,
so the foregoing does not apply to such a prvalue.
\end{note}

\pnum
The materialization of a temporary object is generally
delayed as long as possible
in order to avoid creating unnecessary temporary objects.
\begin{note}
Temporary objects are materialized:
\begin{itemize}
\item
when binding a reference to a prvalue~(\ref{dcl.init.ref}, \ref{expr.type.conv},
\ref{expr.dynamic.cast}, \ref{expr.static.cast}, \ref{expr.const.cast}, \ref{expr.cast}),
\item
when performing member access on a class prvalue~(\ref{expr.ref}, \ref{expr.mptr.oper}),
\item
when performing an array-to-pointer conversion or subscripting on an array prvalue~(\ref{conv.array}, \ref{expr.sub}),
\item
when initializing an object of type \tcode{std::initializer_list<T>} from a \grammarterm{braced-init-list}\iref{dcl.init.list},
\item
for certain unevaluated operands~(\ref{expr.typeid}, \ref{expr.sizeof}), and
\item
when a prvalue that has type other than \cv{}~\tcode{void} appears as a discarded-value expression\iref{expr.prop}.
\end{itemize}
\end{note}
\begin{example}
Consider the following code:
\begin{codeblock}
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);
}
\end{codeblock}

\indextext{class object copy|see{constructor, copy}}%
\indextext{constructor!copy}%
\tcode{X(2)} is constructed in the space used to hold \tcode{f()}'s argument and
\tcode{Y(3)} is constructed in the space used to hold \tcode{g()}'s argument.
Likewise,
\tcode{f()}'s result is constructed directly in \tcode{b} and
\tcode{g()}'s result is constructed directly in \tcode{c}.
On the other hand, the expression
\tcode{a = f(a)}
requires a temporary for
the result of \tcode{f(a)},
which is materialized so that the reference parameter
of \tcode{X::operator=(const X\&)} can bind to it.
\end{example}

\pnum
When an object of class type \tcode{X}
is passed to or returned from a function,
if \tcode{X} has at least one eligible copy or move constructor\iref{special},
each such constructor is trivial,
and the destructor of \tcode{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).
\begin{note}
This latitude is granted to allow objects of class type to be passed to or returned from functions in registers.
\end{note}

\pnum
\indextext{temporary!constructor for}%
\indextext{temporary!destructor for}%
\indextext{temporary!destruction of}%
When an implementation introduces a temporary object of a class that has a
non-trivial constructor~(\ref{class.default.ctor}, \ref{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\iref{class.dtor}.
Temporary objects are destroyed as the last step
in evaluating
the full-expression\iref{intro.execution}
that (lexically) contains the point where
they were created.
This is true even if that evaluation ends in throwing an exception.
The
\indextext{value computation}%
value computations and
\indextext{side effects}%
side effects of destroying a temporary object
are associated only with the full-expression, not with any specific
subexpression.

\pnum
\indextext{initializer!temporary and declarator}%
\indextext{temporary!order of destruction of}%
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\iref{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~(\ref{expr.prim.lambda.capture}, \ref{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.

\pnum
The third context is when a reference is bound to a
temporary object.\footnote{The same rules apply to initialization of an
  \tcode{initializer_list} object\iref{dcl.init.list} with its
  underlying temporary array.}
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:
\begin{itemize}
\item
  a temporary materialization conversion\iref{conv.rval},
\item
  \tcode{(} \grammarterm{expression} \tcode{)},
  where \grammarterm{expression} is one of these expressions,
\item
  subscripting\iref{expr.sub} of an array operand,
  where that operand is one of these expressions,
\item
  a class member access\iref{expr.ref} using the \tcode{.} operator
  where the left operand is one of these expressions and
  the right operand designates a non-static data member of non-reference type,
\item
  a pointer-to-member operation\iref{expr.mptr.oper} using the \tcode{.*} operator
  where the left operand is one of these expressions and
  the right operand is a pointer to data member of non-reference type,
\item
  a
  \begin{itemize}
  \item \tcode{const_cast}\iref{expr.const.cast},
  \item \tcode{static_cast}\iref{expr.static.cast},
  \item \tcode{dynamic_cast}\iref{expr.dynamic.cast}, or
  \item \tcode{reinterpret_cast}\iref{expr.reinterpret.cast}
  \end{itemize}
  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,
\item
  a conditional expression\iref{expr.cond} that is a glvalue
  where the second or third operand is one of these expressions, or
\item
  a comma expression\iref{expr.comma} that is a glvalue
  where the right operand is one of these expressions.
\end{itemize}
\begin{example}
\begin{codeblock}
template<typename T> using id = T;

int i = 1;
int&& a = id<int[3]>{1, 2, 3}[i];           // temporary array has same lifetime as \tcode{a}
const int& b = static_cast<const int&>(0);  // temporary \tcode{int} has same lifetime as \tcode{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{codeblock}
\end{example}
\begin{note}
An explicit type conversion~(\ref{expr.type.conv}, \ref{expr.cast})
is interpreted as
a sequence of elementary casts,
covered above.
\begin{example}
\begin{codeblock}
const int& x = (const int&)1;   // temporary for value 1 has same lifetime as x
\end{codeblock}
\end{example}
\end{note}
\begin{note}
If a temporary object has a reference member initialized by another temporary object,
lifetime extension applies recursively to such a member's initializer.
\begin{example}
\begin{codeblock}
struct S {
  const int& m;
};
const S& s = S{1};              // both \tcode{S} and \tcode{int} temporaries have lifetime of \tcode{s}
\end{codeblock}
\end{example}
\end{note}

The exceptions to this lifetime rule are:
\begin{itemize}
\item A temporary object bound to a reference parameter in a function call\iref{expr.call}
persists until the completion of the full-expression containing the call.

\item A temporary object bound to a reference element of
an aggregate of class type initialized from
a parenthesized \grammarterm{expression-list}\iref{dcl.init}
persists until the completion of the full-expression
containing the \grammarterm{expression-list}.

\item The lifetime of a temporary bound to the returned value in a function \tcode{return} statement\iref{stmt.return} is not extended; the temporary is destroyed at the end of the full-expression in the \tcode{return} statement.

\item A temporary bound to a reference in a \grammarterm{new-initializer}\iref{expr.new} persists until the completion of the full-expression containing the \grammarterm{new-initializer}.
\begin{note}
This may introduce a dangling reference.
\end{note}
\begin{example}
\begin{codeblock}
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{codeblock}
\end{example}
\end{itemize}

\pnum
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~(\ref{basic.stc.static}, \ref{basic.stc.thread}, \ref{basic.stc.auto});
that is, if
\tcode{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
\tcode{obj1}
is destroyed;
if
\tcode{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
\tcode{obj2}
is destroyed.

\pnum
\begin{example}
\begin{codeblock}
struct S {
  S();
  S(int);
  friend S operator+(const S&, const S&);
  ~S();
};
S obj1;
const S& cr = S(16)+S(23);
S obj2;
\end{codeblock}

The expression
\tcode{S(16) + S(23)}
creates three temporaries:
a first temporary
\tcode{T1}
to hold the result of the expression
\tcode{S(16)},
a second temporary
\tcode{T2}
to hold the result of the expression
\tcode{S(23)},
and a third temporary
\tcode{T3}
to hold the result of the addition of these two expressions.
The temporary
\tcode{T3}
is then bound to the reference
\tcode{cr}.
It is unspecified whether
\tcode{T1}
or
\tcode{T2}
is created first.
On an implementation where
\tcode{T1}
is created before
\tcode{T2},
\tcode{T2}
shall be destroyed before
\tcode{T1}.
The temporaries
\tcode{T1}
and
\tcode{T2}
are bound to the reference parameters of
\tcode{operator+};
these temporaries are destroyed at the end of the full-expression
containing the call to
\tcode{operator+}.
The temporary
\tcode{T3}
bound to the reference
\tcode{cr}
is destroyed at the end of
\tcode{cr}'s
lifetime, that is, at the end of the program.
In addition, the order in which
\tcode{T3}
is destroyed takes into account the destruction order of other objects with
static storage duration.
That is, because
\tcode{obj1}
is constructed before
\tcode{T3},
and
\tcode{T3}
is constructed before
\tcode{obj2},
\tcode{obj2}
shall be destroyed before
\tcode{T3},
and
\tcode{T3}
shall be destroyed before
\tcode{obj1}.
\end{example}

\rSec1[basic.types]{Types}%
\indextext{type|(}

\pnum
\begin{note}
\ref{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\iref{intro.object},
references\iref{dcl.ref},
or functions\iref{dcl.fct}.
\end{note}

\pnum
\indextext{object!byte copying and|(}%
\indextext{type!trivially copyable}%
For any object (other than a potentially-overlapping subobject) of trivially copyable type
\tcode{T}, whether or not the object holds a valid value of type
\tcode{T}, the underlying bytes\iref{intro.memory} making up the
object can be copied into an array of
\tcode{char},
\tcode{unsigned char}, or
\tcode{std::byte}\iref{cstddef.syn}.%
\footnote{By using, for example, the library
functions\iref{headers} \tcode{std::memcpy} or \tcode{std::memmove}.}
If the content of that array
is copied back into the object, the object shall
subsequently hold its original value.
\begin{example}
\begin{codeblock}
constexpr std::size_t N = sizeof(T);
char buf[N];
T obj;                          // \tcode{obj} initialized to its original value
std::memcpy(buf, &obj, N);      // between these two calls to \tcode{std::memcpy}, \tcode{obj} might be modified
std::memcpy(&obj, buf, N);      // at this point, each subobject of \tcode{obj} of scalar type holds its original value
\end{codeblock}
\end{example}

\pnum
For any trivially copyable type \tcode{T}, if two pointers to \tcode{T} point to
distinct \tcode{T} objects \tcode{obj1} and \tcode{obj2}, where neither
\tcode{obj1} nor \tcode{obj2} is a potentially-overlapping subobject, if the underlying
bytes\iref{intro.memory} making up
\tcode{obj1} are copied into \tcode{obj2},\footnote{By using, for example,
the library functions\iref{headers} \tcode{std::memcpy} or \tcode{std::memmove}.}
 \tcode{obj2} shall subsequently hold the same value as
\tcode{obj1}.
\begin{example}
\begin{codeblock}
T* t1p;
T* t2p;
    // provided that \tcode{t2p} points to an initialized object ...
std::memcpy(t1p, t2p, sizeof(T));
    // at this point, every subobject of trivially copyable type in \tcode{*t1p} contains
    // the same value as the corresponding subobject in \tcode{*t2p}
\end{codeblock}
\end{example}
\indextext{object!byte copying and|)}

\pnum
The \defnx{object representation}{representation!object}
of an object of type \tcode{T} is the
sequence of \placeholder{N} \tcode{unsigned char} objects taken up
by the object of type \tcode{T}, where \placeholder{N} equals
\tcode{sizeof(T)}.
The \defnx{value representation}{representation!value}
of an object of type \tcode{T} is the set of bits
that participate in representing a value of type \tcode{T}.
Bits in the object representation that are not part of the value representation
are \defn{padding bits}.
For trivially copyable types, the value representation is
a set of bits in the object representation that determines a
\defn{value}, which is one discrete element of an
\impldef{values of a trivially copyable type} set of values.\footnote{The
intent is that the memory model of \Cpp{} is compatible
with that of ISO/IEC 9899 Programming Language C.}

\pnum
\indextext{type!incompletely-defined object}%
A class that has been declared but not defined, an enumeration type in certain
contexts\iref{dcl.enum}, or an array of unknown
bound or of incomplete element type, is an
\defnadj{incompletely-defined}{object type}.%
\footnote{The size and layout of an instance of an incompletely-defined
object type is unknown.}
Incompletely-defined object types and \cv{}~\tcode{void} are
\defnx{incomplete types}{type!incomplete}\iref{basic.fundamental}.
Objects shall not be defined to have an
incomplete type.

\pnum
A class type (such as ``\tcode{class X}'') might be incomplete at one
point in a translation unit and complete later on; the type
``\tcode{class X}'' is the same type at both points. The declared type
of an array object might 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
might 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 \tcode{T}'' and ``array of
\tcode{N} \tcode{T}'') are different types. The type of a pointer to array of
unknown bound, or of a type defined by a \tcode{typedef} declaration to
be an array of unknown bound, cannot be completed.
\begin{example}
\indextext{type!example of incomplete}%
\begin{codeblock}
class X;                        // \tcode{X} is an incomplete type
extern X* xp;                   // \tcode{xp} is a pointer to an incomplete type
extern int arr[];               // the type of arr is incomplete
typedef int UNKA[];             // \tcode{UNKA} is an incomplete type
UNKA* arrp;                     // \tcode{arrp} is a pointer to an incomplete type
UNKA** arrpp;

void foo() {
  xp++;                         // ill-formed: \tcode{X} is incomplete
  arrp++;                       // ill-formed: incomplete type
  arrpp++;                      // OK: sizeof \tcode{UNKA*} is known
}

struct X { int i; };            // now \tcode{X} is a complete type
int  arr[10];                   // now the type of \tcode{arr} is complete

X x;
void bar() {
  xp = &x;                      // OK; type is ``pointer to \tcode{X}''
  arrp = &arr;                  // ill-formed: different types
  xp++;                         // OK:  \tcode{X} is complete
  arrp++;                       // ill-formed: \tcode{UNKA} can't be completed
}
\end{codeblock}
\end{example}

\pnum
\begin{note}
The rules for declarations and expressions describe in which
contexts incomplete types are prohibited.
\end{note}

\pnum
An \defn{object type} is a (possibly cv-qualified) type that is not
a function type, not a reference type, and not \cv{}~\tcode{void}.

\pnum
\indextext{class!trivial}%
\indextext{class!trivially copyable}%
\indextext{class!standard-layout}%
Arithmetic types\iref{basic.fundamental}, enumeration types,
pointer types, pointer-to-member types\iref{basic.compound},
\tcode{std::nullptr_t},
and
cv-qualified\iref{basic.type.qualifier} versions of these
types are collectively called
\defnx{scalar types}{scalar type}.
Scalar types, trivially copyable class types\iref{class.prop},
arrays of such types, and cv-qualified versions of these
types are collectively called \defn{trivially copyable types}.
Scalar types, trivial class types\iref{class.prop},
arrays of such types and cv-qualified versions of these
types are collectively called
\defn{trivial types}. Scalar types, standard-layout class
types\iref{class.prop}, arrays of such types and
cv-qualified versions of these types
are collectively called \defn{standard-layout types}.

\pnum
A type is a \defn{literal type} if it is:
\begin{itemize}
\item possibly cv-qualified \tcode{void}; or
\item a scalar type; or
\item a reference type; or
\item an array of literal type; or
\item a possibly cv-qualified class type\iref{class} that
has all of the following properties:
\begin{itemize}
\item it has a constexpr destructor\iref{dcl.constexpr},
\item it is either a closure type\iref{expr.prim.lambda.closure},
an aggregate type\iref{dcl.init.aggr}, or
has at least one constexpr constructor or constructor template
(possibly inherited\iref{namespace.udecl} from a base class)
that is not a copy or move constructor,
\item if it is a union, at least one of its non-static data members is
of non-volatile literal type, and
\item if it is not a union, all of its non-static data members and base classes are
of non-volatile literal types.
\end{itemize}
\end{itemize}
\begin{note}
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}

\pnum
\indextext{layout-compatible type}%
Two types \cvqual{cv1} \tcode{T1} and \cvqual{cv2} \tcode{T2} are
\defn{layout-compatible} types
if \tcode{T1} and \tcode{T2} are the same type,
layout-compatible enumerations\iref{dcl.enum}, or
layout-compatible standard-layout class types\iref{class.mem}.

\rSec2[basic.fundamental]{Fundamental types}

\pnum
\indextext{type!implementation-defined \tcode{sizeof}}%
\indextext{type!standard signed integer}%
There are five \defnx{standard signed integer types}{standard signed integer type} :
\indextext{type!\idxcode{signed char}}%
\indextext{type!\idxcode{short}}%
\indextext{type!\idxcode{int}}%
\indextext{type!\idxcode{long}}%
\indextext{type!\idxcode{long long}}%
``\tcode{signed char}'', ``\tcode{short int}'', ``\tcode{int}'',
``\tcode{long int}'', and ``\tcode{long long int}''. In
this list, each type provides at least as much storage as those
preceding it in the list.
\indextext{type!extended signed integer}%
\indextext{type!signed integer}%
There may also be \impldef{extended signed integer types}
\defnx{extended signed integer types}{extended signed integer type}.
The standard and extended signed integer types are collectively called
\defnx{signed integer types}{signed integer type}.
The range of representable values for a signed integer type is
$-2^{N-1}$ to $2^{N-1}-1$ (inclusive),
where \placeholder{N} is called the \defn{width} of the type.
\indextext{integral type!implementation-defined \tcode{sizeof}}%
\begin{note}
Plain \tcode{int}s are intended to have
the natural size suggested by the architecture of the execution environment;
the other signed integer types are provided to meet special needs.
\end{note}

\pnum
\indextext{type!\idxcode{unsigned}}%
\indextext{type!unsigned integer}%
For each of the standard signed integer types,
there exists a corresponding (but different)
\indextext{type!standard unsigned integer}%
\defn{standard unsigned integer type}:
\indextext{type!\idxcode{unsigned char}}%
\indextext{type!\idxcode{unsigned short}}%
\indextext{type!\idxcode{unsigned int}}%
\indextext{type!\idxcode{unsigned long}}%
\indextext{type!\idxcode{unsigned long long}}%
``\tcode{unsigned char}'', ``\tcode{unsigned short int}'',
``\tcode{unsigned int}'', ``\tcode{unsigned long int}'', and
``\tcode{unsigned long long int}''.
\indextext{type!extended unsigned integer}%
Likewise, for each of the extended signed integer types,
there exists a corresponding \defn{extended unsigned integer type}.
The standard and extended unsigned integer types
are collectively called \defnx{unsigned integer types}{unsigned integer type}.
An unsigned integer type has the same width \placeholder{N}
as the corresponding signed integer type.
\indextext{arithmetic!\idxcode{unsigned}}%
The range of representable values for the unsigned type is
$0$ to $2^N-1$ (inclusive);
arithmetic for the unsigned type is performed modulo $2^N$.
\begin{note}
Unsigned arithmetic does not overflow.
Overflow for signed arithmetic yields undefined behavior\iref{expr.pre}.
\end{note}

\pnum
\indextext{signed integer representation!two's complement}%
An unsigned integer type has the same
object representation,
value representation, and
alignment requirements\iref{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 $2^N$ has the same value
of corresponding bits in its value representation.\footnote{This
is also known as two's complement representation.}
\begin{example}
The value $-1$ of a signed integer type has the same representation as
the largest value of the corresponding unsigned type.
\end{example}

\begin{floattable}{Minimum width}{basic.fundamental.width}{ll}
\topline
\lhdr{Type} & \rhdr{Minimum width $N$} \\
\capsep
\tcode{signed char} & 8 \\
\tcode{short} & 16 \\
\tcode{int} & 16 \\
\tcode{long} & 32 \\
\tcode{long long} & 64 \\
\end{floattable}

\pnum
The width of each signed integer type
shall not be less than the values specified in \tref{basic.fundamental.width}.
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\iref{basic.types}
in the object representation are
alternative representations of the value specified by the value representation.
\begin{note}
Padding bits have unspecified value, but do not cause traps.
See also ISO C 6.2.6.2.
\end{note}
\begin{note}
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
\impldef{width of integral type}.

\pnum
Each value $x$ of an unsigned integer type with width $N$ has
a unique representation $x = x_0 2^0 + x_1 2^1 + \ldots + x_{N-1} 2^{N-1}$,
where each coefficient $x_i$ is either 0 or 1;
this is called the \defn{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.
\indextext{type!standard integer}%
\indextext{type!extended integer}%
The standard signed integer types and standard unsigned integer types
are collectively called the \defnx{standard integer types}{standard integer type}, and the extended
signed integer types and extended
unsigned integer types are collectively called the
\defnx{extended integer types}{extended integer type}.

\pnum
\indextext{underlying type|see{type, underlying}}%
A fundamental type specified to have
a signed or unsigned integer type as its \defn{underlying type} has
the same object representation,
value representation,
alignment requirements\iref{basic.align}, and
range of representable values as the underlying type.
Further, each value has the same representation in both types.

\pnum
\indextext{type!\idxcode{char}}%
\indextext{type!character}%
\indextext{type!ordinary character}%
\indextext{type!narrow character}%
\indextext{\idxcode{char}!implementation-defined sign of}%
\indextext{type!\idxcode{signed char}}%
\indextext{character!\idxcode{signed}}%
\indextext{type!\idxcode{unsigned char}}%
Type \tcode{char} is a distinct type
that has an \impldef{underlying type of \tcode{char}} choice of
``\tcode{signed char}'' or ``\tcode{unsigned char}'' as its underlying type.
The values of type \tcode{char} can represent distinct codes
for all members of the implementation's basic character set.
The three types \tcode{char}, \tcode{signed char}, and \tcode{unsigned char}
are collectively called
\defnx{ordinary character types}{type!ordinary character}.
The ordinary character types and \tcode{char8_t}
are collectively called \defnx{narrow character types}{narrow character type}.
For narrow character types,
each possible bit pattern of the object representation represents
a distinct value.
\begin{note}
This requirement does not hold for other types.
\end{note}
\begin{note}
A bit-field of narrow character type whose width is larger than
the width of that type has padding bits; see \ref{basic.types}.
\end{note}

\pnum
\indextext{\idxcode{wchar_t}|see{type, \tcode{wchar_t}}}%
\indextext{type!\idxcode{wchar_t}}%
\indextext{type!underlying!\idxcode{wchar_t}}%
Type \tcode{wchar_t} is a distinct type that has
an \impldef{underlying type of \tcode{wchar_t}}
signed or unsigned integer type as its underlying type.
The values of type \tcode{wchar_t} can represent
distinct codes for all members of the largest extended character set
specified among the supported locales\iref{locale}.

\pnum
\indextext{\idxcode{char8_t}|see{type, \tcode{char8_t}}}%
\indextext{type!\idxcode{char8_t}}%
\indextext{type!underlying!\idxcode{char8_t}}%
Type \tcode{char8_t} denotes a distinct type
whose underlying type is \tcode{unsigned char}.
\indextext{\idxcode{char16_t}|see{type, \tcode{char16_t}}}%
\indextext{\idxcode{char32_t}|see{type, \tcode{char32_t}}}%
\indextext{type!\idxcode{char16_t}}%
\indextext{type!\idxcode{char32_t}}%
\indextext{type!underlying!\idxcode{char16_t}}%
\indextext{type!underlying!\idxcode{char32_t}}%
Types \tcode{char16_t} and \tcode{char32_t} denote distinct types
whose underlying types are \tcode{uint_least16_t} and \tcode{uint_least32_t},
respectively, in \libheaderref{cstdint}.

\pnum
\indextext{Boolean type}%
\indextext{type!Boolean}%
Type \tcode{bool} is a distinct type that has
the same object representation,
value representation, and
alignment requirements as
an \impldef{underlying type of \tcode{bool}} unsigned integer type.
The values of type \tcode{bool} are
\tcode{true} and \tcode{false}.
\begin{note}
There are no \tcode{signed}, \tcode{unsigned},
\tcode{short}, or \tcode{long bool} types or values.
\end{note}

\pnum
\indextext{type!integral}%
Types
\tcode{bool},
\tcode{char}, \tcode{wchar_t},
\tcode{char8_t}, \tcode{char16_t}, \tcode{char32_t},
and the signed and unsigned integer types are
collectively called
\defnx{integral types}{integral type}.
A synonym for integral type is \defn{integer type}.
\begin{note}
Enumerations\iref{dcl.enum} are not integral;
however, unscoped enumerations can be promoted to integral types
as specified in \ref{conv.prom}.
\end{note}

\pnum
\indextext{floating-point type|see{type, floating-point}}%
There are three \defnx{floating-point types}{type!floating-point}:
\indextext{type!\idxcode{float}}%
\tcode{float},
\indextext{type!\idxcode{double}}%
\tcode{double},
and
\indextext{type!\idxcode{long double}}%
\tcode{long double}. The type \tcode{double} provides at least as much
precision as \tcode{float}, and the type \tcode{long double} provides at
least as much precision as \tcode{double}. The set of values of the type
\tcode{float} is a subset of the set of values of the type
\tcode{double}; the set of values of the type \tcode{double} is a subset
of the set of values of the type \tcode{long double}. The value
representation of floating-point types is \impldef{value representation of
floating-point types}.
\indextext{floating-point type!implementation-defined}%
\begin{note}
This document imposes no requirements on the accuracy of
floating-point operations; see also~\ref{support.limits}.
\end{note}
Integral and floating-point types are collectively
called \defnx{arithmetic}{type!arithmetic} types.
\indextext{\idxcode{numeric_limits}!specializations for arithmetic types}%
Specializations of the standard library template
\tcode{std::numeric_limits}\iref{support.limits} shall specify the
maximum and minimum values of each arithmetic type for an
implementation.

\pnum
\indextext{type!\idxcode{void}}%
A type \cv{}~\tcode{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{}~\tcode{void}~(\ref{expr.type.conv},
\ref{expr.static.cast}, \ref{expr.cast}).
An expression of type \cv{}~\tcode{void} shall
be used only as an expression statement\iref{stmt.expr}, as an operand
of a comma expression\iref{expr.comma}, as a second or third operand
of \tcode{?:}\iref{expr.cond}, as the operand of
\tcode{typeid}, \tcode{noexcept}, or \tcode{decltype}, as
the expression in a \tcode{return} statement\iref{stmt.return} for a function
with the return type \cv{}~\tcode{void}, or as the operand of an explicit conversion
to type \cv{}~\tcode{void}.

\pnum
A value of type \tcode{std::nullptr_t} is a null pointer
constant\iref{conv.ptr}. Such values participate in the pointer and the
pointer-to-member conversions~(\ref{conv.ptr}, \ref{conv.mem}).
\tcode{sizeof(std::nullptr_t)} shall be equal to \tcode{sizeof(void*)}.

\pnum
\indextext{type!fundamental}%
The types described in this subclause
are called \defnx{fundamental types}{fundamental type}.
\begin{note}
Even if the implementation defines two or more fundamental types to have the
same value representation, they are nevertheless different types.
\end{note}

\rSec2[basic.compound]{Compound types}

\pnum
\indextext{type!compound}%
Compound types can be constructed in the following ways:
\begin{itemize}
\item \defnx{arrays}{type!array} of objects of a given type, \ref{dcl.array};

\item \defnx{functions}{type!function}, which have parameters of given types and return
\tcode{void} or references or objects of a given type, \ref{dcl.fct};

\item \defnx{pointers}{type!pointer} to \cv{}~\tcode{void} or objects or functions (including
static members of classes) of a given type, \ref{dcl.ptr};

\item %
\indextext{reference!lvalue}%
\indextext{reference!rvalue}%
\defnx{references}{reference} to objects or functions of a given
type, \ref{dcl.ref}. There are two types of references:
\begin{itemize}
\item lvalue reference
\item rvalue reference
\end{itemize}

\item
\defnx{classes}{class} containing a sequence of objects of various types\iref{class},
a set of types, enumerations and functions for
manipulating these objects\iref{class.mfct}, and a set of restrictions
on the access to these entities\iref{class.access};

\item
\defnx{unions}{\idxcode{union}}, which are classes capable of containing objects of
different types at different times, \ref{class.union};

\item
\defnx{enumerations}{\idxcode{enum}}, which comprise a set of named constant values.
Each distinct enumeration constitutes a different
\defnadj{enumerated}{type}, \ref{dcl.enum};

\item \indextext{member pointer to|see{pointer to member}}%
\defnx{pointers to non-static class members}{pointer to member},%
\footnote{Static class members are objects or functions, and pointers to them are
ordinary pointers to objects or functions.}
which identify members of a given
type within objects of a given class, \ref{dcl.mptr}.
Pointers to data members and pointers to member functions are collectively
called \term{pointer-to-member} types.
\end{itemize}

\pnum
These methods of constructing types can be applied recursively;
restrictions are mentioned in~\ref{dcl.meaning}.
Constructing a type such that the number of
bytes in its object representation exceeds the maximum value representable in
the type \tcode{std::size_t}\iref{support.types} is ill-formed.

\pnum
\indextext{terminology!pointer}%
The type of a pointer to \cv{}~\tcode{void} or a pointer to an object type is
called an \defn{object pointer type}.
\begin{note}
A pointer to \tcode{void}
does not have a pointer-to-object type, however, because \tcode{void} is not
an object type.
\end{note}
The type of a pointer that can designate a function
is called a \defn{function pointer type}.
A pointer to an object of type \tcode{T} is referred to as a ``pointer to
\tcode{T}''.
\begin{example}
A pointer to an object of type \tcode{int} is
referred to as ``pointer to \tcode{int}'' and a pointer to an object of
class \tcode{X} is called a ``pointer to \tcode{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\iref{basic.align}.
\indextext{address}%
Every value of pointer type is one of the following:
\begin{itemize}
\item
a \defn{pointer to} an object or function (the pointer is said to \defn{point} to the object or function), or
\item
a \defn{pointer past the end of} an object\iref{expr.add}, or
\item
\indextext{null pointer value|see{value, null pointer}}
the \defnx{null pointer value}{value!null pointer}\iref{conv.ptr} for that type, or
\item
\indextext{invalid pointer value|see{value, invalid pointer}}
an \defnx{invalid pointer value}{value!invalid pointer}.
\end{itemize}
A value of a
pointer type
that is a pointer to or past the end of an object
\defn{represents the address} of
the first byte in memory\iref{intro.memory} occupied by the object%
\footnote{For an object that is not within its lifetime,
this is the first byte in memory that it will occupy or used to occupy.}
or the first byte in memory
after the end of the storage occupied by the object,
respectively.
\begin{note}
A pointer past the end of an object\iref{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 \ref{basic.stc}.
\end{note}
For purposes of pointer arithmetic\iref{expr.add}
and comparison~(\ref{expr.rel}, \ref{expr.eq}),
a pointer past the end of the last element of
an array \tcode{x} of $n$ elements
is considered to be equivalent to
a pointer to a hypothetical array element $n$ of \tcode{x} and
an object of type \tcode{T} that is not an array element
is considered to belong to an array with one element of type \tcode{T}.
The value representation of
pointer types is \impldef{value representation of pointer types}. Pointers to
layout-compatible types shall
have the same value representation and alignment
requirements\iref{basic.align}.
\begin{note}
Pointers to over-aligned types\iref{basic.align} have no special
representation, but their range of valid values is restricted by the extended
alignment requirement.
\end{note}

\pnum
Two objects \placeholder{a} and \placeholder{b} are \defn{pointer-interconvertible} if:
\begin{itemize}
\item
they are the same object, or
\item
one is a union object and
the other is a non-static data member of that object\iref{class.union}, or
\item
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\iref{class.mem}, or
\item
there exists an object \placeholder{c} such that
\placeholder{a} and \placeholder{c} are pointer-interconvertible, and
\placeholder{c} and \placeholder{b} are pointer-interconvertible.
\end{itemize}
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 \tcode{reinterpret_cast}\iref{expr.reinterpret.cast}.
\begin{note}
An array object and its first element are not pointer-interconvertible,
even though they have the same address.
\end{note}

\pnum
\indextext{pointer|seealso{\tcode{void*}}}%
\indextext{\idxcode{void*}!type}%
A pointer to \cv-qualified\iref{basic.type.qualifier} or \cv-unqualified
\tcode{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{}~\tcode{void*}
shall have the same representation and alignment
requirements as \cv{}~\tcode{char*}.

\rSec2[basic.type.qualifier]{CV-qualifiers}

\pnum
\indextext{cv-qualifier}%
\indextext{\idxcode{const}}%
\indextext{\idxcode{volatile}}%
A type mentioned in~\ref{basic.fundamental} and~\ref{basic.compound} is
a \defnadj{cv-unqualified}{type}. Each type which is a
cv-unqualified complete or incomplete object type or is
\tcode{void}\iref{basic.types} has three corresponding cv-qualified
versions of its type: a \defn{const-qualified} version, a
\defn{volatile-qualified} version, and a
\defn{const-volatile-qualified} version. The
type of an object\iref{intro.object} includes the \grammarterm{cv-qualifier}{s}
specified in the \grammarterm{decl-specifier-seq}\iref{dcl.spec},
\grammarterm{declarator}\iref{dcl.decl},
\grammarterm{type-id}\iref{dcl.name}, or
\grammarterm{new-type-id}\iref{expr.new} when the object is created.
\begin{itemize}
\item A \defnadj{const}{object} is an object of type \tcode{const T} or a
  non-mutable subobject of a const object.

\item A \defnadj{volatile}{object} is an object of type
  \tcode{volatile T} or a subobject of a volatile object.

\item A \defnadj{const volatile}{object} is an object of type
  \tcode{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.
\end{itemize}
The cv-qualified or
cv-unqualified versions of a type
are distinct types; however, they shall have the same representation and
alignment requirements\iref{basic.align}.\footnote{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.}

\pnum
\indextext{array!\idxcode{const}}%
A compound type\iref{basic.compound} is not cv-qualified by the
cv-qualifiers (if any) of the types from which it is compounded. Any
cv-qualifiers applied to an array type
affect the array element type\iref{dcl.array}.

\pnum
See~\ref{dcl.fct} and~\ref{class.this} regarding function
types that have \grammarterm{cv-qualifier}{s}.

\pnum
There is a partial ordering on cv-qualifiers, so that a type can be
said to be \defn{more cv-qualified} than another.
\tref{basic.type.qualifier.rel} shows the relations that
constitute this ordering.

\begin{floattable}{Relations on \tcode{const} and \tcode{volatile}}{basic.type.qualifier.rel}
{ccc}
\topline
\cvqual{no cv-qualifier}    &<& \tcode{const}           \\
\cvqual{no cv-qualifier}    &<& \tcode{volatile}        \\
\cvqual{no cv-qualifier}    &<& \tcode{const volatile}  \\
\tcode{const}               &<& \tcode{const volatile}  \\
\tcode{volatile}            &<& \tcode{const volatile}  \\
\end{floattable}

\pnum
In this document, the notation \cv{} (or
\cvqual{cv1}, \cvqual{cv2}, etc.), used in the description of types,
represents an arbitrary set of cv-qualifiers, i.e., one of
\{\tcode{const}\}, \{\tcode{volatile}\}, \{\tcode{const},
\tcode{volatile}\}, or the empty set.
For a type \cv{}~\tcode{T}, the \defnx{top-level cv-qualifiers}{cv-qualifier!top-level}
of that type are those denoted by \cv.
\begin{example}
The type corresponding to the \grammarterm{type-id}
\tcode{const int\&}
has no top-level cv-qualifiers.
The type corresponding to the \grammarterm{type-id}
\tcode{volatile int * const}
has the top-level cv-qualifier \tcode{const}.
For a class type \tcode{C},
the type corresponding to the \grammarterm{type-id}
\tcode{void (C::* volatile)(int) const}
has the top-level cv-qualifier \tcode{volatile}.
\end{example}

\pnum
Cv-qualifiers applied to an array
type attach to the underlying element type, so the notation
``\cv{}~\tcode{T}'', where \tcode{T} is an array type, refers to
an array whose elements are so-qualified. An array type whose elements
are cv-qualified is also considered to have the same cv-qualifications
as its elements.
\begin{example}
\begin{codeblock}
typedef char CA[5];
typedef const char CC;
CC arr1[5] = { 0 };
const CA arr2 = { 0 };
\end{codeblock}
The type of both \tcode{arr1} and \tcode{arr2} is ``array of 5
\tcode{const char}'', and the array type is considered to be
const-qualified.
\end{example}
\indextext{type|)}

\rSec2[conv.rank]{Integer conversion rank}%
\indextext{conversion!integer rank}

\pnum
Every integer type has an \term{integer conversion rank} defined as follows:

\begin{itemize}
\item No two signed integer types other than \tcode{char} and \tcode{signed
char} (if \tcode{char} is signed) shall have the same rank, even if they have
the same representation.

\item The rank of a signed integer type shall be greater than the rank
of any signed integer type with a smaller size.

\item The rank of \tcode{long long int} shall be greater
than the rank of \tcode{long int}, which shall be greater than
the rank of \tcode{int}, which shall be greater than the rank of
\tcode{short int}, which shall be greater than the rank of
\tcode{signed char}.

\item The rank of any unsigned integer type shall equal the rank of the
corresponding signed integer type.

\item The rank of any standard integer type shall be greater than the
rank of any extended integer type with the same size.

\item The rank of \tcode{char} shall equal the rank of \tcode{signed char}
and \tcode{unsigned char}.

\item The rank of \tcode{bool} shall be less than the rank of all other
standard integer types.

\indextext{type!\idxcode{wchar_t}}%
\indextext{type!\idxcode{char16_t}}%
\indextext{type!\idxcode{char32_t}}%
\item The ranks of \tcode{char8_t}, \tcode{char16_t}, \tcode{char32_t}, and
\tcode{wchar_t} shall equal the ranks of their underlying
types\iref{basic.fundamental}.

\item The rank of any extended signed integer type relative to another
extended signed integer type with the same size is \impldef{rank of extended signed
integer type}, but still subject to the other rules for determining the integer
conversion rank.

\item For all integer types \tcode{T1}, \tcode{T2}, and \tcode{T3}, if
\tcode{T1} has greater rank than \tcode{T2} and \tcode{T2} has greater
rank than \tcode{T3}, then \tcode{T1} shall have greater rank than
\tcode{T3}.
\end{itemize}

\begin{note}
The integer conversion rank is used in the definition of the integral
promotions\iref{conv.prom} and the usual arithmetic
conversions\iref{expr.arith.conv}.
\end{note}

\rSec1[basic.exec]{Program execution}

\rSec2[intro.execution]{Sequential execution}

\pnum
An instance of each object with automatic storage
duration\iref{basic.stc.auto} is associated with each entry into its
block. Such an object exists and retains its last-stored value during
the execution of the block and while the block is suspended (by a call
of a function, suspension of a coroutine\iref{expr.await}, or receipt of a signal).

\pnum
A \defn{constituent expression} is defined as follows:
\begin{itemize}
\item
The constituent expression of an expression is that expression.
\item
The constituent expressions of a \grammarterm{braced-init-list} or
of a (possibly parenthesized) \grammarterm{expression-list}
are the constituent expressions of the elements of the respective list.
\item
The constituent expressions of a \grammarterm{brace-or-equal-initializer}
of the form \tcode{=}~\grammarterm{initializer-clause}
are the constituent expressions of the \grammarterm{initializer-clause}.
\end{itemize}
\begin{example}
\begin{codeblock}
struct A { int x; };
struct B { int y; struct A a; };
B b = { 5, { 1+1 } };
\end{codeblock}
The constituent expressions of the \grammarterm{initializer}
used for the initialization of \tcode{b} are \tcode{5} and \tcode{1+1}.
\end{example}

\pnum
The \defnx{immediate subexpressions}{immediate subexpression} of an expression \tcode{e} are
\begin{itemize}
\item
the constituent expressions of \tcode{e}'s operands\iref{expr.prop},
\item
any function call that \tcode{e} implicitly invokes,
\item
if \tcode{e} is a \grammarterm{lambda-expression}\iref{expr.prim.lambda},
the initialization of the entities captured by copy and
the constituent expressions of the \grammarterm{initializer} of the \grammarterm{init-capture}{s},
\item
if \tcode{e} is a function call\iref{expr.call} or implicitly invokes a function,
the constituent expressions of each default argument\iref{dcl.fct.default}
used in the call, or
\item
if \tcode{e} creates an aggregate object\iref{dcl.init.aggr},
the constituent expressions of each default member initializer\iref{class.mem}
used in the initialization.
\end{itemize}

\pnum
A \defn{subexpression} of an expression \tcode{e} is
an immediate subexpression of \tcode{e} or
a subexpression of an immediate subexpression of \tcode{e}.
\begin{note}
Expressions appearing in the \grammarterm{compound-statement} of a \grammarterm{lambda-expression}
are not subexpressions of the \grammarterm{lambda-expression}.
\end{note}

\pnum
A \defn{full-expression} is
\begin{itemize}
\item
an unevaluated operand\iref{expr.prop},
\item
a \grammarterm{constant-expression}\iref{expr.const},
\item
an immediate invocation\iref{expr.const},
\item
an \grammarterm{init-declarator}\iref{dcl.decl} or
a \grammarterm{mem-initializer}\iref{class.base.init},
including the constituent expressions of the initializer,
\item
an invocation of a destructor generated at the end of the lifetime
of an object other than a temporary object\iref{class.temporary}
whose lifetime has not been extended, or
\item
an expression that is not a subexpression of another expression and
that is not otherwise part of a full-expression.
\end{itemize}
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.
\begin{example}
\begin{codeblock}
struct S {
  S(int i): I(i) { }            // full-expression is initialization of \tcode{I}
  int& v() { return I; }
  ~S() noexcept(false) { }
private:
  int I;
};

S s1(1);                        // full-expression comprises call of \tcode{S::S(int)}
void f() {
  S s2 = 2;                     // full-expression comprises call of \tcode{S::S(int)}
  if (S(3).v())                 // full-expression includes lvalue-to-rvalue and \tcode{int} to \tcode{bool} conversions,
                                // performed before temporary is deleted at end of full-expression
  { }
  bool b = noexcept(S());       // exception specification of destructor of \tcode{S} considered for \tcode{noexcept}

  // full-expression is destruction of \tcode{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{codeblock}
\end{example}

\pnum
\begin{note}
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\iref{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}

\pnum
\indextext{value computation|(}%
Reading an object designated by a \tcode{volatile}
glvalue\iref{basic.lval}, modifying an object, calling a library I/O
function, or calling a function that does any of those operations are
all
\defn{side effects}, which are changes in the state of the execution
environment. \defnx{Evaluation}{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 \tcode{volatile} access
may not have completed yet.

\pnum
\defnx{Sequenced before}{sequenced before} is an asymmetric, transitive, pair-wise relation between
evaluations executed by a single thread\iref{intro.multithread}, which induces
a partial order among those evaluations. Given any two evaluations \placeholder{A} and
\placeholder{B}, if \placeholder{A} is sequenced before \placeholder{B}
(or, equivalently, \placeholder{B} is \defn{sequenced after} \placeholder{A}),
then the execution of
\placeholder{A} shall precede the execution of \placeholder{B}. If \placeholder{A} is not sequenced
before \placeholder{B} and \placeholder{B} is not sequenced before \placeholder{A}, then \placeholder{A} and
\placeholder{B} are \defn{unsequenced}.
\begin{note}
The execution of unsequenced
evaluations can overlap.
\end{note}
Evaluations \placeholder{A} and \placeholder{B} are
\defn{indeterminately sequenced} when either \placeholder{A} is sequenced before
\placeholder{B} or \placeholder{B} is sequenced before \placeholder{A}, but it is unspecified which.
\begin{note}
Indeterminately sequenced evaluations cannot overlap, but either
could be executed first.
\end{note}
An expression \placeholder{X}
is said to be sequenced before
an expression \placeholder{Y} if
every value computation and every side effect
associated with the expression \placeholder{X}
is sequenced before
every value computation and every side effect
associated with the expression \placeholder{Y}.

\pnum
Every
\indextext{value computation}%
value computation and
\indextext{side effects}%
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.\footnote{As specified
in~\ref{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.}

\pnum
\indextext{evaluation!unspecified order of}%
Except where noted, evaluations of operands of individual operators and
of subexpressions of individual expressions are unsequenced.
\begin{note}
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
\indextext{side effects}%
side effect on a memory location\iref{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\iref{intro.multithread},
the behavior is undefined.
\begin{note}
The next subclause imposes similar, but more complex restrictions on
potentially concurrent computations.
\end{note}

\begin{example}
\begin{codeblock}
void g(int i) {
  i = 7, i++, i++;              // \tcode{i} becomes \tcode{9}

  i = i++ + 1;                  // the value of \tcode{i} is incremented
  i = i++ + i;                  // the behavior is undefined
  i = i + 1;                    // the value of \tcode{i} is incremented
}
\end{codeblock}
\end{example}

\pnum
When calling a function (whether or not the function is inline), every
\indextext{value computation}%
value computation and
\indextext{side effects}%
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 \placeholder{F},
for every evaluation \placeholder{A} that occurs within \placeholder{F} and
every evaluation \placeholder{B} that does not occur within \placeholder{F} but
is evaluated on the same thread and as part of the same signal handler (if any),
either \placeholder{A} is sequenced before \placeholder{B} or
\placeholder{B} is sequenced before \placeholder{A}.\footnote{In other words,
function executions do not interleave with each other.}
\begin{note}
If \placeholder{A} and \placeholder{B} would not otherwise be sequenced then they are
indeterminately sequenced.
\end{note}
Several contexts in \Cpp{} cause evaluation of a function call, even
though no corresponding function call syntax appears in the translation
unit.
\begin{example}
Evaluation of a \grammarterm{new-expression} invokes one or more allocation
and constructor functions; see~\ref{expr.new}. For another example,
invocation of a conversion function\iref{class.conv.fct} can arise in
contexts in which no function call syntax appears.
\end{example}
The sequencing constraints on the execution of the called function (as
described above) are features of the function calls as evaluated,
whatever the syntax of the expression that calls the function might be.%
\indextext{value computation|)}%

\indextext{behavior!on receipt of signal}%
\indextext{signal}%
\pnum
If a signal handler is executed as a result of a call to the \tcode{std::raise}
function, then the execution of the handler is sequenced after the invocation
of the \tcode{std::raise} function and before its return.
\begin{note}
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}
\indextext{program execution|)}

\rSec2[intro.multithread]{Multi-threaded executions and data races}

\pnum
\indextext{threads!multiple|(}%
\indextext{atomic!operation|(}%
A \defn{thread of execution} (also known as a \defn{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.
\begin{note}
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.\footnote{An object
with automatic or thread storage duration\iref{basic.stc} is associated with
one specific thread, and can be accessed by a different thread only indirectly
through a pointer or reference\iref{basic.compound}.} Under a hosted
implementation, a \Cpp{} 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.
\begin{note}
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 \impldef{number of
threads in a program under a freestanding implementation} whether a program can
have more than one thread of execution.

\pnum
For a signal handler that is not executed as a result of a call to the
\tcode{std::raise} function, it is unspecified which thread of execution
contains the signal handler invocation.

\rSec3[intro.races]{Data races}

\pnum
The value of an object visible to a thread \placeholder{T} at a particular point is the
initial value of the object, a value assigned to the object by \placeholder{T}, or a
value assigned to the object by another thread, according to the rules below.
\begin{note}
In some cases, there may 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}

\pnum
Two expression evaluations \defn{conflict} if one of them modifies a memory
location\iref{intro.memory} and the other one reads or modifies the same
memory location.

\pnum
The library defines a number of atomic operations\iref{atomics} and
operations on mutexes\iref{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.
\begin{note}
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
\placeholder{A} forces prior
\indextext{side effects}%
side effects on other memory locations to become visible
to other threads that later perform a consume or an acquire operation on
\placeholder{A}. ``Relaxed'' atomic operations are not synchronization operations even
though, like synchronization operations, they cannot contribute to data races.
\end{note}

\pnum
All modifications to a particular atomic object \placeholder{M} occur in some
particular total order, called the \defn{modification order} of \placeholder{M}.
\begin{note}
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 may observe modifications to different objects in inconsistent orders.
\end{note}

\pnum
A \defn{release sequence} headed
by a release operation \placeholder{A} on an atomic object \placeholder{M}
is a maximal contiguous sub-sequence of
\indextext{side effects}%
side effects in the modification order of \placeholder{M},
where the first operation is \placeholder{A}, and
every subsequent operation is an atomic read-modify-write operation.

\pnum
Certain library calls \defn{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\iref{atomics.order}.
\begin{note}
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}
\begin{note}
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}

\pnum
An evaluation \placeholder{A} \defn{carries a dependency} to an evaluation \placeholder{B} if
\begin{itemize}
\item
the value of \placeholder{A} is used as an operand of \placeholder{B}, unless:
\begin{itemize}
\item
\placeholder{B} is an invocation of any specialization of
\tcode{std::kill_dependency}\iref{atomics.order}, or
\item
\placeholder{A} is the left operand of a built-in logical \logop{AND} (\tcode{\&\&},
see~\ref{expr.log.and}) or logical \logop{OR} (\tcode{||}, see~\ref{expr.log.or})
operator, or
\item
\placeholder{A} is the left operand of a conditional (\tcode{?:}, see~\ref{expr.cond})
operator, or
\item
\placeholder{A} is the left operand of the built-in comma (\tcode{,})
operator\iref{expr.comma}; \end{itemize} or
\item
\placeholder{A} writes a scalar object or bit-field \placeholder{M}, \placeholder{B} reads the value
written by \placeholder{A} from \placeholder{M}, and \placeholder{A} is sequenced before \placeholder{B}, or
\item
for some evaluation \placeholder{X}, \placeholder{A} carries a dependency to \placeholder{X}, and
\placeholder{X} carries a dependency to \placeholder{B}.
\end{itemize}
\begin{note}
``Carries a dependency to'' is a subset of ``is sequenced before'',
and is similarly strictly intra-thread.
\end{note}

\pnum
An evaluation \placeholder{A} is \defn{dependency-ordered before} an evaluation
\placeholder{B} if
\begin{itemize}
\item
\placeholder{A} performs a release operation on an atomic object \placeholder{M}, and, in
another thread, \placeholder{B} performs a consume operation on \placeholder{M} and reads
the value written by \placeholder{A}, or

\item
for some evaluation \placeholder{X}, \placeholder{A} is dependency-ordered before \placeholder{X} and
\placeholder{X} carries a dependency to \placeholder{B}.

\end{itemize}
\begin{note}
The relation ``is dependency-ordered before'' is analogous to
``synchronizes with'', but uses release/consume in place of release/acquire.
\end{note}

\pnum
An evaluation \placeholder{A} \defn{inter-thread happens before} an evaluation \placeholder{B}
if
\begin{itemize}
\item
  \placeholder{A} synchronizes with \placeholder{B}, or
\item
  \placeholder{A} is dependency-ordered before \placeholder{B}, or
\item
  for some evaluation \placeholder{X}
  \begin{itemize}
  \item
    \placeholder{A} synchronizes with \placeholder{X} and \placeholder{X}
    is sequenced before \placeholder{B}, or
  \item
    \placeholder{A} is sequenced before \placeholder{X} and \placeholder{X}
    inter-thread happens before \placeholder{B}, or
  \item
    \placeholder{A} inter-thread happens before \placeholder{X} and \placeholder{X}
    inter-thread happens before \placeholder{B}.
  \end{itemize}
\end{itemize}
\begin{note}
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}

\pnum
An evaluation \placeholder{A} \defn{happens before} an evaluation \placeholder{B}
(or, equivalently, \placeholder{B} \defn{happens after} \placeholder{A}) if:
\begin{itemize}
\item \placeholder{A} is sequenced before \placeholder{B}, or
\item \placeholder{A} inter-thread happens before \placeholder{B}.
\end{itemize}
The implementation shall ensure that no program execution demonstrates a cycle
in the ``happens before'' relation.
\begin{note}
This cycle would otherwise be
possible only through the use of consume operations.
\end{note}

\pnum
An evaluation \placeholder{A} \defn{simply happens before} an evaluation \placeholder{B}
if either
\begin{itemize}
\item \placeholder{A} is sequenced before \placeholder{B}, or
\item \placeholder{A} synchronizes with \placeholder{B}, or
\item \placeholder{A} simply happens before \placeholder{X} and
\placeholder{X} simply happens before \placeholder{B}.
\end{itemize}
\begin{note}
In the absence of consume operations,
the happens before and simply happens before relations are identical.
\end{note}

\pnum
An evaluation \placeholder{A} \defn{strongly happens before}
an evaluation \placeholder{D} if, either
\begin{itemize}
\item \placeholder{A} is sequenced before \placeholder{D}, or
\item \placeholder{A} synchronizes with \placeholder{D}, and
both \placeholder{A} and \placeholder{D} are
sequentially consistent atomic operations\iref{atomics.order}, or
\item there are evaluations \placeholder{B} and \placeholder{C}
such that \placeholder{A} is sequenced before \placeholder{B},
\placeholder{B} simply happens before \placeholder{C}, and
\placeholder{C} is sequenced before \placeholder{D}, or
\item there is an evaluation \placeholder{B} such that
\placeholder{A} strongly happens before \placeholder{B}, and
\placeholder{B} strongly happens before \placeholder{D}.
\end{itemize}
\begin{note}
Informally, if \placeholder{A} strongly happens before \placeholder{B},
then \placeholder{A} appears to be evaluated before \placeholder{B}
in all contexts. Strongly happens before excludes consume operations.
\end{note}

\pnum
A \defnadj{visible}{side effect} \placeholder{A} on a scalar object or bit-field \placeholder{M}
with respect to a value computation \placeholder{B} of \placeholder{M} satisfies the
conditions:
\begin{itemize}
\item \placeholder{A} happens before \placeholder{B} and
\item there is no other
\indextext{side effects}%
side effect \placeholder{X} to \placeholder{M} such that \placeholder{A}
happens before \placeholder{X} and \placeholder{X} happens before \placeholder{B}.
\end{itemize}

The value of a non-atomic scalar object or bit-field \placeholder{M}, as determined by
evaluation \placeholder{B}, shall be the value stored by the
\indextext{side effects!visible}%
visible side effect
\placeholder{A}.
\begin{note}
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}
\begin{note}
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}

\pnum
The value of an
atomic object \placeholder{M}, as determined by evaluation \placeholder{B}, shall be the value
stored by some
side effect \placeholder{A} that modifies \placeholder{M}, where \placeholder{B} does not happen
before \placeholder{A}.
\begin{note}
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}

\pnum
\indextext{coherence!write-write}%
If an operation \placeholder{A} that modifies an atomic object \placeholder{M} happens before
an operation \placeholder{B} that modifies \placeholder{M}, then \placeholder{A} shall be earlier
than \placeholder{B} in the modification order of \placeholder{M}.
\begin{note}
This requirement
is known as write-write coherence.
\end{note}

\pnum
\indextext{coherence!read-read}%
If a
\indextext{value computation}%
value computation \placeholder{A} of an atomic object \placeholder{M} happens before a
value computation \placeholder{B} of \placeholder{M}, and \placeholder{A} takes its value from a side
effect \placeholder{X} on \placeholder{M}, then the value computed by \placeholder{B} shall either be
the value stored by \placeholder{X} or the value stored by a
\indextext{side effects}%
side effect \placeholder{Y} on
\placeholder{M}, where \placeholder{Y} follows \placeholder{X} in the modification order of \placeholder{M}.
\begin{note}
This requirement is known as read-read coherence.
\end{note}

\pnum
\indextext{coherence!read-write}%
If a
\indextext{value computation}%
value computation \placeholder{A} of an atomic object \placeholder{M} happens before an
operation \placeholder{B} that modifies \placeholder{M}, then \placeholder{A} shall take its value from a side
effect \placeholder{X} on \placeholder{M}, where \placeholder{X} precedes \placeholder{B} in the
modification order of \placeholder{M}.
\begin{note}
This requirement is known as
read-write coherence.
\end{note}

\pnum
\indextext{coherence!write-read}%
If a
\indextext{side effects}%
side effect \placeholder{X} on an atomic object \placeholder{M} happens before a value
computation \placeholder{B} of \placeholder{M}, then the evaluation \placeholder{B} shall take its
value from \placeholder{X} or from a
\indextext{side effects}%
side effect \placeholder{Y} that follows \placeholder{X} in the
modification order of \placeholder{M}.
\begin{note}
This requirement is known as
write-read coherence.
\end{note}

\pnum
\begin{note}
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 \Cpp{} atomic operations.
\end{note}

\pnum
\begin{note}
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}

\pnum
Two actions are \defn{potentially concurrent} if
\begin{itemize}
\item they are performed by different threads, or
\item they are unsequenced, at least one is performed by a signal handler, and
they are not both performed by the same signal handler invocation.
\end{itemize}
The execution of a program contains a \defn{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.
\begin{note}
It can be shown that programs that correctly use mutexes
and \tcode{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
\indextext{value computation}%
value computation of an
object being taken from the last
\indextext{side effects}%
side effect on that object in that
interleaving. This is normally referred to as ``sequential consistency''.
However, this applies only to data-race-free programs, and data-race-free
programs cannot observe most program transformations that do not change
single-threaded program semantics. In fact, most single-threaded program
transformations continue to be allowed, since any program that behaves
differently as a result must perform an undefined operation.
\end{note}

\pnum
Two accesses to the same object of type \tcode{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 \placeholder{A} and \placeholder{B}, such that no evaluations in
\placeholder{B} happen before evaluations in \placeholder{A}, and the
evaluations of such \tcode{volatile std::sig_atomic_t} objects take values as though
all evaluations in \placeholder{A} happened before the execution of the signal
handler and the execution of the signal handler happened before all evaluations
in \placeholder{B}.

\pnum
\begin{note}
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
may alias is also generally precluded, since this may violate the coherence
rules.
\end{note}

\pnum
\begin{note}
Transformations that introduce a speculative read of a potentially
shared memory location may not preserve the semantics of the \Cpp{} 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}

\rSec3[intro.progress]{Forward progress}

\pnum
The implementation may assume that any thread will eventually do one of the
following:
\begin{itemize}
\item terminate,
\item make a call to a library I/O function,
\item perform an access through a volatile glvalue, or
\item perform a synchronization operation or an atomic operation.
\end{itemize}
\begin{note}
This is intended to allow compiler transformations such as removal of
empty loops, even when termination cannot be proven.
\end{note}

\pnum
Executions of atomic functions
that are either defined to be lock-free\iref{atomics.flag}
or indicated as lock-free\iref{atomics.lockfree}
are \defnx{lock-free executions}{lock-free execution}.
\begin{itemize}
\item
  If there is only one thread that is not blocked\iref{defns.block}
  in a standard library function,
  a lock-free execution in that thread shall complete.
  \begin{note}
    Concurrently executing threads
    may prevent progress of a lock-free execution.
    For example,
    this situation can occur
    with load-locked store-conditional implementations.
    This property is sometimes termed obstruction-free.
  \end{note}
\item
  When one or more lock-free executions run concurrently,
  at least one should complete.
  \begin{note}
    It is difficult for some implementations
    to provide absolute guarantees to this effect,
    since repeated and particularly inopportune interference
    from other threads
    may prevent forward progress,
    e.g.,
    by repeatedly stealing a cache line
    for unrelated purposes
    between load-locked and store-conditional instructions.
    Implementations should ensure
    that such effects cannot indefinitely delay progress
    under expected operating conditions,
    and that such anomalies
    can therefore safely be ignored by programmers.
    Outside this document,
    this property is sometimes termed lock-free.
  \end{note}
\end{itemize}

\pnum
During the execution of a thread of execution, each of the following is termed
an \defn{execution step}:
\begin{itemize}
\item termination of the thread of execution,
\item performing an access through a volatile glvalue, or
\item completion of a call to a library I/O function, a
      synchronization operation, or an atomic operation.
\end{itemize}

\pnum
An invocation of a standard library function that blocks\iref{defns.block}
is considered to continuously execute execution steps while waiting for the
condition that it blocks on to be satisfied.
\begin{example}
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}

\pnum
\begin{note}
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}

\pnum
A thread of execution \defnx{makes progress}{make progress!thread}
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).

\pnum
\indextext{forward progress guarantees!concurrent}%
For a thread of execution providing \defn{concurrent forward progress guarantees},
the implementation ensures that the thread will eventually make progress for as
long as it has not terminated.
\begin{note}
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}

\pnum
It is \impldef{whether the thread that executes \tcode{main} and the threads created
by \tcode{std::thread} or \tcode{std::jthread} provide concurrent forward progress guarantees} whether the
implementation-created thread of execution that executes
\tcode{main}\iref{basic.start.main} and the threads of execution created by
\tcode{std::thread}\iref{thread.thread.class}
or \tcode{std::jthread}\iref{thread.jthread.class}
provide concurrent forward progress guarantees.
\begin{note}
General-purpose implementations should provide these guarantees.
\end{note}

\pnum
\indextext{forward progress guarantees!parallel}%
For a thread of execution providing \defn{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.

\pnum
\begin{note}
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}

\pnum
\indextext{forward progress guarantees!weakly parallel}%
For a thread of execution providing \defn{weakly parallel forward progress
guarantees}, the implementation does not ensure that the thread will eventually
make progress.

\pnum
\begin{note}
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}

\pnum
Concurrent forward progress guarantees are stronger than parallel forward progress
guarantees, which in turn are stronger than weakly parallel forward progress
guarantees.
\begin{note}
For example, some kinds of synchronization between threads of execution may 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}

\pnum
\indextext{forward progress guarantees!delegation of}%
When a thread of execution \placeholder{P} is specified to \defnx{block with forward
progress guarantee delegation}{block (execution)!with forward
progress guarantee delegation} on the completion of a set \placeholder{S} of threads
of execution, then throughout the whole time of \placeholder{P} being blocked on
\placeholder{S}, the implementation shall ensure that the forward progress guarantees
provided by at least one thread of execution in \placeholder{S} is at least as strong
as \placeholder{P}'s forward progress guarantees.
\begin{note}
It is unspecified which thread or threads of execution in \placeholder{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 \placeholder{P} is blocked, the implementation has to eventually
select and potentially strengthen a thread of execution in \placeholder{S}.
\end{note}
Once a thread of execution in \placeholder{S} terminates, it is removed from \placeholder{S}.
Once \placeholder{S} is empty, \placeholder{P} is unblocked.

\pnum
\begin{note}
A thread of execution \placeholder{B} thus can temporarily provide an effectively
stronger forward progress guarantee for a certain amount of time, due to a
second thread of execution \placeholder{A} being blocked on it with forward
progress guarantee delegation. In turn, if \placeholder{B} then blocks with
forward progress guarantee delegation on \placeholder{C}, this may also temporarily
provide a stronger forward progress guarantee to \placeholder{C}.
\end{note}

\pnum
\begin{note}
If all threads of execution in \placeholder{S} finish executing (e.g., they terminate
and do not use blocking synchronization incorrectly), then \placeholder{P}'s execution
of the operation that blocks with forward progress guarantee delegation will not
result in \placeholder{P}'s progress guarantee being effectively weakened.
\end{note}

\pnum
\begin{note}
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}

\pnum
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.%
\indextext{atomic!operation|)}%
\indextext{threads!multiple|)}

\rSec2[basic.start]{Start and termination}

\rSec3[basic.start.main]{\tcode{main} function}
\indextext{\idxcode{main} function|(}

\pnum
\indextext{program!start|(}%
A program shall contain a global function called \tcode{main}
attached to the global module.
Executing a program starts a main thread of execution~(\ref{intro.multithread}, \ref{thread.threads})
in which the \tcode{main} function is invoked,
and in which variables of static storage duration
might be initialized\iref{basic.start.static} and destroyed\iref{basic.start.term}.
It is \impldef{defining \tcode{main} in freestanding environment}
whether a program in a freestanding environment is required to define a \tcode{main}
function.
\begin{note}
In a freestanding environment, start-up and termination is
\impldef{start-up and termination in freestanding environment}; start-up 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}

\pnum
An implementation shall not predefine the \tcode{main} function. This
function shall not be overloaded.  Its type shall have \Cpp{} language linkage
and it shall have a declared return type of type
\tcode{int}, but otherwise its type is \impldef{parameters to \tcode{main}}.
\indextext{\idxcode{main} function!implementation-defined parameters to}%
An implementation shall allow both
\begin{itemize}
\item a function of \tcode{()} returning \tcode{int} and
\item a function of \tcode{(int}, pointer to pointer to \tcode{char)} returning \tcode{int}
\end{itemize}
\indextext{\idxcode{argc}}%
\indextext{\idxcode{argv}}%
as the type of \tcode{main}\iref{dcl.fct}.
\indextext{\idxcode{main} function!parameters to}%
\indextext{environment!program}%
In the latter form, for purposes of exposition, the first function
parameter is called \tcode{argc} and the second function parameter is
called \tcode{argv}, where \tcode{argc} shall be the number of
arguments passed to the program from the environment in which the
program is run. If
\tcode{argc} is nonzero these arguments shall be supplied in
\tcode{argv[0]} through \tcode{argv[argc-1]} as pointers to the initial
characters of null-terminated multibyte strings (\ntmbs{}s)\iref{multibyte.strings}
and \tcode{argv[0]} shall be the pointer to
the initial character of a \ntmbs{} that represents the name used to
invoke the program or \tcode{""}. The value of \tcode{argc} shall be
non-negative. The value of \tcode{argv[argc]} shall be 0.
\begin{note}
It
is recommended that any further (optional) parameters be added after
\tcode{argv}.
\end{note}

\pnum
The function \tcode{main} shall not be used within
a program.
\indextext{\idxcode{main} function!implementation-defined linkage of}%
The linkage\iref{basic.link} of \tcode{main} is
\impldef{linkage of \tcode{main}}. A program that defines \tcode{main} as
deleted or that declares \tcode{main} to be
\tcode{inline}, \tcode{static}, or \tcode{constexpr} is ill-formed.
The function \tcode{main} shall not be a coroutine\iref{dcl.fct.def.coroutine}.
The \tcode{main} function shall not be declared with a
\grammarterm{linkage-specification}\iref{dcl.link}.
A program that declares a variable \tcode{main} at global scope,
or that declares a function \tcode{main} at global scope attached to a named module,
or that declares the name \tcode{main} with C language linkage (in any namespace)
is ill-formed.
The name \tcode{main} is
not otherwise reserved.
\begin{example}
Member functions, classes, and
enumerations can be called \tcode{main}, as can entities in other
namespaces.
\end{example}

\pnum
\indextext{\idxcode{exit}}%
\indexlibraryglobal{exit}%
\indextext{termination!program}%
Terminating the program
without leaving the current block (e.g., by calling the function
\tcode{std::exit(int)}\iref{support.start.term}) does not destroy any
objects with automatic storage duration\iref{class.dtor}. If
\tcode{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.

\pnum
\indextext{termination!program}%
\indextext{\idxcode{main} function!return from}%
A \tcode{return} statement\iref{stmt.return} in \tcode{main} has the effect of leaving the main
function (destroying any objects with automatic storage duration) and
calling \tcode{std::exit} with the return value as the argument.
If control flows off the end of
the \grammarterm{compound-statement} of \tcode{main},
the effect is equivalent to a \tcode{return} with operand \tcode{0}
(see also \ref{except.handle}).
\indextext{\idxcode{main} function|)}

\rSec3[basic.start.static]{Static initialization}

\pnum
\indextext{initialization}%
\indextext{initialization!static and thread}%
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.

\pnum
\indextext{initialization!static object@\tcode{static} object}%
\indextext{initialization!constant}%
\defnx{Constant initialization}{constant initialization} is performed
if a variable or temporary object with static or thread storage duration
is constant-initialized\iref{expr.const}.
\indextext{initialization!zero-initialization}%
If constant initialization is not performed, a variable with static
storage duration\iref{basic.stc.static} or thread storage
duration\iref{basic.stc.thread} is zero-initialized\iref{dcl.init}.
Together, zero-initialization and constant initialization are called
\indextext{initialization!dynamic}%
\defn{static initialization};
all other initialization is \defn{dynamic initialization}.
All static initialization strongly happens before\iref{intro.races}
any dynamic initialization.
\begin{note}
The dynamic initialization of non-local variables is described
in~\ref{basic.start.dynamic}; that of local static variables is described
in~\ref{stmt.dcl}.
\end{note}

\pnum
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
\begin{itemize}
\item
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

\item
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.
\end{itemize}
\begin{note}
As a consequence, if the initialization of an object \tcode{obj1} refers to an
object \tcode{obj2} of namespace scope potentially requiring dynamic initialization and defined
later in the same translation unit, it is unspecified whether the value of \tcode{obj2} used
will be the value of the fully initialized \tcode{obj2} (because \tcode{obj2} was statically
initialized) or will be the value of \tcode{obj2} merely zero-initialized. For example,
\begin{codeblock}
inline double fd() { return 1.0; }
extern double d1;
double d2 = d1;     // unspecified:
                    // may be statically initialized to \tcode{0.0} or
                    // dynamically initialized to \tcode{0.0} if \tcode{d1} is
                    // dynamically initialized, or \tcode{1.0} otherwise
double d1 = fd();   // may be initialized statically or dynamically to \tcode{1.0}
\end{codeblock}
\end{note}

\rSec3[basic.start.dynamic]{Dynamic initialization of non-local variables}

\pnum
\indextext{initialization!dynamic non-local}%
\indextext{start!program}%
\indextext{initialization!order of}%
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.
\begin{note}
An explicitly specialized non-inline static data member or
variable template specialization has ordered initialization.
\end{note}

\pnum
A declaration \tcode{D} is
\defn{appearance-ordered} before a declaration \tcode{E} if
\begin{itemize}
\item \tcode{D} appears in the same translation unit as \tcode{E}, or
\item the translation unit containing \tcode{E}
has an interface dependency on the translation unit containing \tcode{D},
\end{itemize}
in either case prior to \tcode{E}.

\pnum
Dynamic initialization of non-local variables \tcode{V} and \tcode{W}
with static storage duration are ordered as follows:
\begin{itemize}
\item
If \tcode{V} and \tcode{W} have ordered initialization and
the definition of \tcode{V}
is appearance-ordered before the definition of \tcode{W}, or
if \tcode{V} has partially-ordered initialization,
\tcode{W} does not have unordered initialization, and
for every definition \tcode{E} of \tcode{W}
there exists a definition \tcode{D} of \tcode{V}
such that \tcode{D} is appearance-ordered before \tcode{E}, then
\begin{itemize}
\item
if the program does not start a thread\iref{intro.multithread}
other than the main thread\iref{basic.start.main}
or \tcode{V} and \tcode{W} have ordered initialization and
they are defined in the same translation unit,
the initialization of \tcode{V}
is sequenced before
the initialization of \tcode{W};
\item
otherwise,
the initialization of \tcode{V}
strongly happens before
the initialization of \tcode{W}.
\end{itemize}

\item
Otherwise, if the program starts a thread
other than the main thread
before either \tcode{V} or \tcode{W} is initialized,
it is unspecified in which threads
the initializations of \tcode{V} and \tcode{W} occur;
the initializations are unsequenced if they occur in the same thread.

\item
Otherwise, the initializations of \tcode{V} and \tcode{W} are indeterminately sequenced.
\end{itemize}
\begin{note}
This definition permits initialization of a sequence of
ordered variables concurrently with another sequence.
\end{note}

\pnum
\indextext{non-initialization odr-use|see{odr-use, non-initialization}}%
A \defnx{non-initialization odr-use}{odr-use!non-initialization}
is an odr-use\iref{basic.def.odr} not caused directly or indirectly by
the initialization of a non-local static or thread storage duration variable.

\pnum
\indextext{evaluation!unspecified order of}%
It is \impldef{dynamic initialization of static variables before \tcode{main}}
whether the dynamic initialization of a
non-local non-inline variable with static storage duration
is sequenced before the first statement of \tcode{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.%
\footnote{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~(\ref{basic.def.odr}, \ref{basic.stc.static}).}
It is \impldef{threads and program points at which deferred dynamic initialization is performed}
in which threads and at which points in the program such deferred dynamic initialization occurs.
\begin{note}
Such points should be chosen in a way that allows the programmer to avoid deadlocks.
\end{note}
\begin{example}
\begin{codeblock}
// - 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();
}
\end{codeblock}

It is \impldef{dynamic initialization of static variables before \tcode{main}}
whether either \tcode{a} or \tcode{b} is
initialized before \tcode{main} is entered or whether the
initializations are delayed until \tcode{a} is first odr-used in
\tcode{main}. In particular, if \tcode{a} is initialized before
\tcode{main} is entered, it is not guaranteed that \tcode{b} will be
initialized before it is odr-used by the initialization of \tcode{a}, that
is, before \tcode{A::A} is called. If, however, \tcode{a} is initialized
at some point after the first statement of \tcode{main}, \tcode{b} will
be initialized prior to its use in \tcode{A::A}.
\end{example}

\pnum
It is \impldef{dynamic initialization of static inline variables before \tcode{main}}
whether the dynamic initialization of a
non-local inline variable with static storage duration
is sequenced before the first statement of \tcode{main} or is deferred.
If it is deferred, it strongly happens before
any non-initialization odr-use
of that variable.
It is \impldef{threads and program points at which deferred dynamic initialization is performed}
in which threads and at which points in the program such deferred dynamic initialization occurs.

\pnum
It is \impldef{dynamic initialization of thread-local variables before entry}
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 \placeholder{t}
is sequenced before the first non-initialization odr-use by \placeholder{t}
of any non-inline variable with thread storage duration
defined in the same translation unit as the variable to be initialized.
It is \impldef{threads and program points at which deferred dynamic initialization is performed}
in which threads and at which points in the program such deferred dynamic initialization occurs.

\pnum
If the initialization of
a non-local variable with static or thread storage duration
exits via an exception,
the function \tcode{std::terminate} is called\iref{except.terminate}.%
\indextext{program!start|)}

\rSec3[basic.start.term]{Termination}

\pnum
\indextext{program!termination|(}%
\indextext{object!destructor static}%
\indextext{\idxcode{main} function!return from}%
Constructed objects\iref{dcl.init}
with static storage duration are destroyed
and functions registered with \tcode{std::atexit}
are called as part of a call to
\indextext{\idxcode{exit}}%
\indexlibraryglobal{exit}%
\tcode{std::exit}\iref{support.start.term}.
The call to \tcode{std::exit} is sequenced before
the destructions and the registered functions.
\begin{note}
Returning from \tcode{main} invokes \tcode{std::exit}\iref{basic.start.main}.
\end{note}

\pnum
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 \tcode{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.

\pnum
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 \tcode{std::terminate} is called\iref{except.terminate}.

\pnum
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.

\pnum
\indextext{\idxcode{atexit}}%
\indexlibraryglobal{atexit}%
If the completion of the initialization of an object with static storage
duration strongly happens before a call to \tcode{std::atexit}~(see
\libheader{cstdlib}, \ref{support.start.term}), the call to the function passed to
\tcode{std::atexit} is sequenced before the call to the destructor for the object. If a
call to \tcode{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 \tcode{std::atexit}. If a
call to \tcode{std::atexit} strongly happens before another call to \tcode{std::atexit}, the
call to the function passed to the second \tcode{std::atexit} call is sequenced before
the call to the function passed to the first \tcode{std::atexit} call.

\pnum
If there is a use of a standard library object or function not permitted within signal
handlers\iref{support.runtime} that does not happen before\iref{intro.multithread}
completion of destruction of objects with static storage duration and execution of
\tcode{std::atexit} registered functions\iref{support.start.term}, the program has
undefined behavior.
\begin{note}
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 \tcode{std::exit} or the exit from
\tcode{main} is sufficient, but not necessary, to satisfy these requirements. These
requirements permit thread managers as static-storage-duration objects.
\end{note}

\pnum
\indextext{\idxcode{abort}}%
\indexlibraryglobal{abort}%
\indextext{termination!program}%
Calling the function \tcode{std::abort()} declared in
\libheaderref{cstdlib} terminates the program without executing any destructors
and without calling
the functions passed to \tcode{std::atexit()} or \tcode{std::at_quick_exit()}.%
\indextext{program!termination|)}