basic.tex

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

\gramSec[gram.basic]{Basic concepts}

\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, function, enumerator, type,
class member, bit-field, template, template specialization, namespace, or
parameter pack.

\pnum
A \defn{name} is a use of an \grammarterm{identifier}~(\ref{lex.name}),
\grammarterm{operator-function-id}~(\ref{over.oper}),
\grammarterm{literal-operator-id}~(\ref{over.literal}),
\grammarterm{conversion-function-id}~(\ref{class.conv.fct}), or
\grammarterm{template-id}~(\ref{temp.names}) that denotes an entity or
\grammarterm{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~(\ref{stmt.goto}) or a
\grammarterm{labeled-statement}~(\ref{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
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}~(\ref{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~(\ref{temp.type}), or
\item they are the names of literal operators~(\ref{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~(\ref{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 (Clause~\ref{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 attributes of these names.
A declaration may also have effects including:
\begin{itemize}
\item a static assertion (Clause~\ref{dcl.dcl}),
\item controlling template instantiation~(\ref{temp.explicit}),
\item guiding template argument deduction for constructors~(\ref{temp.deduct.guide}),
\item use of attributes (Clause~\ref{dcl.dcl}), and
\item nothing (in the case of an \grammarterm{empty-declaration}).
\end{itemize}

\pnum
\indextext{declaration!function}%
\indextext{definition}%
A declaration is a \defn{definition} unless
\begin{itemize}
\item
it declares a function
without specifying the function's body~(\ref{dcl.fct.def}),
\item
it contains
the
\indextext{declaration!\idxcode{extern}}%
\tcode{extern} specifier~(\ref{dcl.stc}) or a
\grammarterm{linkage-specification}\footnote{Appearing inside the braced-enclosed
\grammarterm{declaration-seq} in a \grammarterm{linkage-specification} does
not affect whether a declaration is a definition.}
(\ref{dcl.link}) and neither an \grammarterm{initializer} nor a
\grammarterm{function-body},
\item
\indextext{declaration!\idxcode{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 a class name declaration~(\ref{class.name}),
\item
it is an
\indextext{declaration!opaque~enum}%
\grammarterm{opaque-enum-declaration}~(\ref{dcl.enum}),
\item
it is a
\indextext{parameter!template}\indextext{template parameter}%
\grammarterm{template-parameter}~(\ref{temp.param}),
\item
it is a
\indextext{declaration!parameter}\indextext{parameter declaration}%
\grammarterm{parameter-declaration}~(\ref{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~(\ref{dcl.typedef}),
\item it is
an \grammarterm{alias-declaration}~(\ref{dcl.typedef}),
\item it is
a
\grammarterm{using-declaration}~(\ref{namespace.udecl}),
\item it is
a \grammarterm{deduction-guide}~(\ref{temp.deduct.guide}),
\item it is
a \grammarterm{static_assert-declaration} (Clause~\ref{dcl.dcl}),
\item
it is an
\grammarterm{attribute-declaration} (Clause~\ref{dcl.dcl}),
\item
it is an
\grammarterm{empty-declaration} (Clause~\ref{dcl.dcl}),
\item it is
a \grammarterm{using-directive}~(\ref{namespace.udir}),
\item it is
an explicit instantiation declaration~(\ref{temp.explicit}), or
\item it is
an explicit specialization~(\ref{temp.expl.spec}) whose
\grammarterm{declaration} is not a definition.
\end{itemize}
\begin{example} all but one of the following are definitions:
\indextext{example!definition}%
\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:
\indextext{example!declaration}%
\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~(\ref{class.ctor}),
copy constructor~(\ref{class.copy}),
move constructor~(\ref{class.copy}),
copy assignment operator~(\ref{class.copy}),
move assignment operator~(\ref{class.copy}),
or destructor~(\ref{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 (Clause~\ref{strings})
};

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)) { }
    // \tcode{: 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; }
    // \tcode{\{ 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}~(\ref{dcl.type.elab}).
\end{note}

\pnum
\indextext{type!incomplete}%
A program is ill-formed if the definition of any object gives the object
an incomplete type~(\ref{basic.types}).

\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, or template.

\pnum
An expression is \defn{potentially evaluated} unless it is an
unevaluated operand (Clause~\ref{expr}) or a subexpression thereof.
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}~(\ref{expr.prim.id}), the set
contains only \tcode{e}.
\item If \tcode{e} is a subscripting operation~(\ref{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~(\ref{expr.ref}), the set contains the potential results of
the object expression.
\item If \tcode{e} is a pointer-to-member
expression~(\ref{expr.mptr.oper}) whose second operand is a constant
expression, the set contains the potential results of the object
expression.
\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~(\ref{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~(\ref{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 variable \tcode{x} whose name appears as a
potentially-evaluated expression \tcode{ex} is \defn{odr-used} by \tcode{ex} unless
applying the lvalue-to-rvalue conversion (\ref{conv.lval}) to \tcode{x} yields
a constant expression~(\ref{expr.const}) that does not invoke any non-trivial
functions
and, if \tcode{x} is an object, \tcode{ex} is an element of
the set of potential results of an expression \tcode{e}, where either the lvalue-to-rvalue
conversion~(\ref{conv.lval}) is applied to \tcode{e}, or \tcode{e} is
a discarded-value expression~(Clause \ref{expr}).
\tcode{this} is odr-used if it 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})).
A virtual member
function is odr-used if it is not pure.
A function whose name appears as a potentially-evaluated
expression is odr-used if it is the unique lookup result or the selected
member of a set of overloaded functions~(\ref{basic.lookup}, \ref{over.match}, \ref{over.over}),
unless it is a pure virtual function and either
its name is not explicitly qualified or
the expression forms a pointer to member~(\ref{expr.unary.op}).
\begin{note} This covers calls to named
functions~(\ref{expr.call}), operator overloading (Clause~\ref{over}),
user-defined conversions~(\ref{class.conv.fct}), allocation functions for
placement \grammarterm{new-expression}{s}~(\ref{expr.new}), as well as non-default
initialization~(\ref{dcl.init}). A constructor selected to copy or move an
object of class type is odr-used even if the
call is actually elided by the implementation~(\ref{class.copy}). \end{note} An allocation
or deallocation function for a class is odr-used by a \grammarterm{new-expression}
appearing in a potentially-evaluated expression as specified
in~\ref{expr.new} and~\ref{class.free}. A deallocation function for a
class is odr-used by a delete expression appearing in a
potentially-evaluated expression as specified in~\ref{expr.delete}
and~\ref{class.free}. 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~(\ref{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.}
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}.
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~(\ref{class.dtor}).

\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~(\ref{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.ctor}, \ref{class.dtor} and
\ref{class.copy}). An inline function or variable shall be defined in every
translation unit in which it is odr-used outside of a discarded statement.

\pnum
\indextext{type!incomplete}%
Exactly one definition of a class is required in a translation unit if
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~(\ref{basic.def}), or
\item a non-static class data member of type \tcode{T} is
declared~(\ref{class.mem}), or
\item \tcode{T} is used as the object type or array element type in a
\grammarterm{new-expression}~(\ref{expr.new}), or
\item an lvalue-to-rvalue conversion is applied to
a glvalue referring
to an object of type \tcode{T}~(\ref{conv.lval}), or
\item an expression is converted (either implicitly or explicitly) to
type \tcode{T} (Clause~\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
(Clause~\ref{conv}), a \tcode{dynamic_cast}~(\ref{expr.dynamic.cast}) or
a \tcode{static_cast}~(\ref{expr.static.cast}), or
\item a class member access operator is applied to an expression of type
\tcode{T}~(\ref{expr.ref}), or
\item the \tcode{typeid} operator~(\ref{expr.typeid}) or the
\tcode{sizeof} operator~(\ref{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~(\ref{basic.def}) or called~(\ref{expr.call}), or
\item a class with a base class of type \tcode{T} is
defined (Clause~\ref{class.derived}), or
\item an lvalue of type \tcode{T} is assigned to~(\ref{expr.ass}), or
\item the type \tcode{T} is the subject of an
\tcode{alignof} expression~(\ref{expr.alignof}), or
\item an \grammarterm{exception-declaration} has type \tcode{T}, reference to
\tcode{T}, or pointer to \tcode{T}~(\ref{except.handle}).
\end{itemize}
\end{note}

\pnum
There can be more than one definition of a class type
(Clause~\ref{class}), enumeration type~(\ref{dcl.enum}), inline function
with external linkage~(\ref{dcl.inline}), inline variable with external
linkage~(\ref{dcl.inline}), class template
(Clause~\ref{temp}), non-static function template~(\ref{temp.fct}),
static data member of a class template~(\ref{temp.static}), member
function of a class template~(\ref{temp.mem.func}), or template
specialization for which some template parameters are not
specified~(\ref{temp.spec}, \ref{temp.class.spec}) in a program provided
that each definition appears in a different translation unit, and
provided the definitions satisfy the following requirements. 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; and
\item in each definition of \tcode{D}, corresponding names, looked up
according to~\ref{basic.lookup}, shall refer to an entity defined within
the definition of \tcode{D}, or shall refer to the same entity, after
overload resolution~(\ref{over.match}) and after matching of partial
template specialization~(\ref{temp.over}), except that a name can refer to
\begin{itemize}
\item
a non-volatile \tcode{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~(\ref{expr.const}),
\item is not odr-used, 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}, 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, or to a function defined within the definition of \tcode{D};
and

\item in each definition of \tcode{D}, a default argument used by an
(implicit or explicit) function call is treated as if its token sequence
were present in the definition of \tcode{D}; that is, the default
argument is subject to the requirements described in this paragraph (and, if
the default argument has sub-expressions with default arguments, this
requirement applies recursively).\footnote{\ref{dcl.fct.default} 
describes how default argument names are looked up.}

\item if \tcode{D} is a class with an implicitly-declared
constructor~(\ref{class.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 d2;                           // \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;
};                              // \tcode{X(int, int, int)} called by \tcode{D()};
                                // \tcode{D()}'s implicit definition
                                // violates the ODR
\end{codeblock}
\end{example}
\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~(\ref{temp.nondep}), and also to dependent names at
the point of instantiation~(\ref{temp.dep}). If the definitions of
\tcode{D} satisfy all these requirements, then the behavior is
as if there were a single definition of \tcode{D}. If the definitions of
\tcode{D} do not satisfy these requirements, then the behavior is
undefined.%
\indextext{one-definition~rule|)}

\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 \defn{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~(\ref{class.friend}), certain uses of the
\grammarterm{elaborated-type-specifier}~(\ref{dcl.type.elab}), and
\grammarterm{using-directive}{s}~(\ref{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~(\ref{basic.scope.hiding}). \begin{note} A namespace name or a
class template name must be unique in its declarative
region~(\ref{namespace.alias}, Clause~\ref{temp}). \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}~(\ref{dcl.type.elab}) and
friend declarations~(\ref{class.friend}) may introduce a (possibly not
visible) name into an enclosing namespace; these restrictions apply to
that region. Local extern declarations~(\ref{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
\begin{note} The name lookup rules are summarized in~\ref{basic.lookup}.
\end{note}

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

\pnum
\indextext{name!point~of declaration}%
The \defn{point of declaration} for a name is immediately after its
complete declarator (Clause~\ref{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}
(Clause~\ref{class}). The point of declaration for an enumeration is
immediately after the \grammarterm{identifier} (if any) in either its
\grammarterm{enum-specifier}~(\ref{dcl.enum}) or its first
\grammarterm{opaque-enum-declaration}~(\ref{dcl.enum}), whichever comes first.
The point of declaration of an alias or alias template immediately
follows the \grammarterm{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}~(\ref{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 attribute-specifier-seq\opt 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
\grammarterm{injected-class-name} (Clause~\ref{class}) is immediately following
the opening brace of the class definition.

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

\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~(\ref{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|)}

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

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

\pnum
\indextext{parameter!scope~of}%
The potential scope of a function parameter name
(including one appearing in a 
\grammarterm{lambda-declarator})
or of a function-local predefined variable
in a function
definition~(\ref{dcl.fct.def}) begins at its point of declaration. If
the function has a \grammarterm{function-try-block} the potential scope of
a parameter
or of a function-local predefined variable
ends at the end of the last associated handler, otherwise it 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}.

\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;
see~\ref{stmt.select}.

\rSec2[basic.scope.proto]{Function prototype scope}

\pnum
\indextext{scope!function~prototype}%
\indextext{function~prototype}%
In a function declaration, or in any function declarator except the
declarator of a function definition~(\ref{dcl.fct.def}), names of
parameters (if supplied) have function prototype scope, which terminates
at the end of the nearest enclosing function declarator.

\rSec2[basic.funscope]{Function scope}

\pnum
\indextext{label!scope~of}%
Labels~(\ref{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~(\ref{basic.scope.pdecl}) onwards; and for each
\grammarterm{using-directive}~(\ref{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
A namespace member can also be referred to after the \tcode{::} scope
resolution operator~(\ref{expr.prim}) 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
\indextext{scope!global namespace}%
\indextext{scope!global}%
The outermost declarative region of a translation unit is also a
namespace, called the \defn{global namespace}. A name declared in
the global namespace has \defn{global namespace scope} (also called
\defn{global scope}). The potential scope of such a name begins at
its point of declaration~(\ref{basic.scope.pdecl}) and ends at the end
of the translation unit that is its declarative region.
\indextext{name!global}%
A name with global namespace scope is said to be a
\defnx{global name}{global}.

\rSec2[basic.scope.class]{Class scope}

\pnum
\indextext{scope!class}%
The following rules describe the scope of names declared in classes.

\begin{enumerate}
\item 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 function bodies, default arguments,
\grammarterm{noexcept-specifier}{s}, and
\grammarterm{brace-or-equal-initializers} of non-static data members
in that class (including such
things in nested classes).
\item 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.
\item 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.
\item The potential scope of a declaration 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~(\ref{dcl.fct.default})). \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}
\end{enumerate}

\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
(Clause~\ref{class.derived}) from its class,
\item after the \tcode{.} operator applied to an expression of the type
of its class~(\ref{expr.ref}) or a class derived from its class,
\item after the \tcode{->} operator applied to a pointer to an object of
its class~(\ref{expr.ref}) or a class derived from its class,
\item after the \tcode{::} scope resolution operator~(\ref{expr.prim})
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~(\ref{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 \tcode{\#1}, \tcode{\#2} and \tcode{\#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~(\ref{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 { /* ... */ };
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> { /* ... */ };
template<class T> class Y : public T { /* ... */ };
\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~(\ref{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~(\ref{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 name can be hidden by an explicit declaration of that same name in a
nested declarative region or derived class~(\ref{class.member.lookup}).

\pnum
\indextext{name~hiding}%
A class name~(\ref{class.name}) or enumeration name~(\ref{dcl.enum}) can
be hidden by the name of a variable, data member, function, or enumerator declared in
the same scope. If a class or enumeration name and a variable, data member, function,
or enumerator are declared in the same scope (in any order) with the
same name, 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 (Clause~\ref{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}~(\ref{dcl.typedef}),
\grammarterm{namespace-name}{s}~(\ref{basic.namespace}), and
\grammarterm{class-name}{s}~(\ref{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 declaration~(\ref{basic.def}) of
that name. Name lookup shall find an unambiguous declaration for the
name (see~\ref{class.member.lookup}). Name lookup may associate more
than one declaration with a name if it finds the name to be a function
name; the declarations are said to form a set of overloaded
functions~(\ref{over.load}). Overload resolution~(\ref{over.match})
takes place after name lookup has succeeded. The access rules
(Clause~\ref{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 attributes introduced by the name's
declaration used further in expression processing (Clause~\ref{expr}).

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

\pnum
The injected-class-name of a class (Clause~\ref{class}) 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. 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~(\ref{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
A name used in the definition of a function following 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.}
that is a member of namespace \tcode{N} (where, only for the purpose of
exposition, \tcode{N} could represent the global scope) shall be
declared before its use in the block in which it is used or in one of
its enclosing blocks~(\ref{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} outside of a member
function body, default argument, \grammarterm{noexcept-specifier},
\grammarterm{brace-or-equal-initializer} of a non-static data member,
or nested class definition\footnote{This refers to unqualified names
following the class name; such a name may be used in the
\grammarterm{base-clause} or may be used in the class definition.}
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}~(\ref{class.member.lookup}), or
\item if \tcode{X} is a nested class of class
\tcode{Y}~(\ref{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~(\ref{class.nest}).}
or
\item if \tcode{X} is a local class~(\ref{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 \tcode{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 member function
body, in a default argument, in a \grammarterm{noexcept-specifier}, in the
\grammarterm{brace-or-equal-initializer} of a non-static data
member~(\ref{class.mem}), 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~(\ref{stmt.block}), or

\item shall be a member of class \tcode{X} or be a member of a base
class of \tcode{X}~(\ref{class.member.lookup}), or

\item if \tcode{X}
is a nested class of class \tcode{Y}~(\ref{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~(\ref{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 \tcode{friend}
function~(\ref{class.friend}) defined inline in the class granting
friendship shall proceed as described for lookup in member function
definitions. If the \tcode{friend} function is not defined in the class
granting friendship, name lookup in the \tcode{friend} function
definition shall proceed as described for lookup in namespace member
function definitions.

\pnum
In a \tcode{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~(\ref{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~(\ref{dcl.fct.default}) in a function
\grammarterm{parameter-declaration-clause} or used in the
\grammarterm{expression} of a \grammarterm{mem-initializer} for a
constructor~(\ref{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}~(\ref{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}
(Clause~\ref{except}) 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~(\ref{expr.call}) is an \grammarterm{unqualified-id}, other namespaces not considered
during the usual unqualified lookup~(\ref{basic.lookup.unqual}) may be
searched, and in those namespaces, namespace-scope friend function or
function template declarations~(\ref{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 classes}{class!associated}
to be considered. The sets of namespaces and classes 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 classes are
determined in the following way:
\begin{itemize}
\item If \tcode{T} is a fundamental type, its associated sets of
namespaces and classes are both empty.

\item If \tcode{T} is a class type (including unions), its associated
classes 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 classes.
Furthermore, if \tcode{T} is a class template specialization, its
associated namespaces and classes also include: the namespaces and
classes associated with the types of the template arguments provided for
template type parameters (excluding template template parameters); 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. If it is a class member, its
associated class is the member's class; else it has no associated class.

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

\item If \tcode{T} is a function type, its associated namespaces and
classes 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 classes 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 classes are those associated with the member
type together with those associated with \tcode{X}.
\end{itemize}
If an associated namespace is an inline namespace~(\ref{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 classes
and namespaces are the union of those associated with each of the
members of the set, i.e., the classes 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 classes 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~(\ref{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 classes
associated with the argument types can include namespaces and classes
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, the lookup is the same as the
lookup performed when the associated namespace is used as a
qualifier~(\ref{namespace.qual}) except that:
\begin{itemize}
\item Any \grammarterm{using-directive}{s} in the associated namespace are
ignored.

\item Any namespace-scope friend functions or friend function templates
declared in associated classes are visible within their respective
namespaces even if they are not visible during an ordinary
lookup~(\ref{class.friend}).

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

\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~(\ref{expr.prim}) 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~(\ref{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];}
                    // 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{::}~(\ref{expr.prim})
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}~(\ref{namespace.qual}). The use of \tcode{::}
allows a global name to be referred to even if its identifier has been
hidden~(\ref{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
If a \grammarterm{pseudo-destructor-name}~(\ref{expr.pseudo}) contains a
\grammarterm{nested-name-specifier}, the \grammarterm{type-name}{s} are looked
up as types in the scope designated by the
\grammarterm{nested-name-specifier}. Similarly, in a
\grammarterm{qualified-id} of the form:

\begin{ncbnf}
nested-name-specifier\opt class-name \terminal{::} \terminal{\tilde} class-name
\end{ncbnf}

the second \grammarterm{class-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~(\ref{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 (Clause~\ref{class.derived}). \begin{note} A class member
can be referred to using a \grammarterm{qualified-id} at any point in its
potential scope~(\ref{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}~(\ref{namespace.udecl}) also finds class or
enumeration names hidden within the same
scope~(\ref{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} (Clause~\ref{class}), or
\item
in a \grammarterm{using-declarator} of
a \grammarterm{using-declaration}~(\ref{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}~(\ref{namespace.def}). 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-directives} 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}~(\ref{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}

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

\pnum
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
either introduce 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~(\ref{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}~(\ref{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~(\ref{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 attribute-specifier-seq\opt 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 attribute-specifier-seq\opt 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. \begin{example}

\begin{codeblock}
struct Node {
  struct Node* Next;            // OK: Refers to \tcode{Node} at global scope
  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~(\ref{dcl.type.elab})
  friend struct Glob;           // OK: Refers to (as yet) undeclared \tcode{Glob}
                                // at global scope.
  /* ... */
};

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 @\tcode{\{ /* ... */ \};}@   // Defines nested \tcode{Data}
};

struct Data;                    // OK: Redeclares \tcode{Data} at global scope
struct ::Data;                  // error: cannot introduce a qualified type~(\ref{dcl.type.elab})
struct Base::Data;              // error: cannot introduce a qualified type~(\ref{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~(\ref{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~(\ref{temp.names}) or a less-than operator. The identifier is first
looked up in the class of the object expression. If the identifier is
not found, it is then looked up in the context of the entire
\grammarterm{postfix-expression} and shall name a class template.

\pnum
If the \grammarterm{id-expression} in a class member
access~(\ref{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}.
For a pseudo-destructor call~(\ref{expr.pseudo}),
the \grammarterm{unqualified-id} is looked up in the context of the complete
\grammarterm{postfix-expression}.

\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 (possibly cv-qualified)
\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}
class-name-or-namespace-name::...
\end{codeblock}
the \grammarterm{class-name-or-namespace-name} following the \tcode{.} or
\tcode{->} operator is
first looked up in the class of the object expression 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}
::class-name-or-namespace-name::...
\end{codeblock}
the \grammarterm{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}~(\ref{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 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 \defnx{translation units}{translation unit}
(Clause~\ref{lex}) linked together. A translation unit consists
of a sequence of declarations.

\begin{bnf}
\nontermdef{translation-unit}\br
    declaration-seq\opt
\end{bnf}

\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 \defn{external linkage}\indextext{linkage!external},
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 \defn{internal linkage}\indextext{linkage!internal},
the entity it denotes
can be referred to by names from other scopes in the same translation
unit.

\item When a name has \defn{no linkage}\indextext{linkage!no}, 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~(\ref{basic.scope.namespace}) has internal
linkage if it is the name of
\begin{itemize}
\item
  a variable, function or function template that is
  explicitly declared \tcode{static}; or,
\item
  a non-inline variable of non-volatile const-qualified type that is
  neither explicitly declared \tcode{extern} nor previously
  declared to have external linkage; or
\item
  a data member of an anonymous union.
\end{itemize}

\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
has the same linkage as the enclosing namespace if it is the name of
\begin{itemize}
\item a variable; or
\item a function; or
\item \indextext{class!linkage~of}%
a named class (Clause~\ref{class}), or an unnamed class defined in a
typedef declaration in which the class has the typedef name for linkage
purposes~(\ref{dcl.typedef}); or
\item \indextext{enumeration!linkage~of}%
a named enumeration~(\ref{dcl.enum}), or an unnamed enumeration defined
in a typedef declaration in which the enumeration has the typedef name
for linkage purposes~(\ref{dcl.typedef}); or
\item an enumerator belonging to an enumeration with linkage; or
\item a template.
\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~(\ref{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 there is a visible declaration
of an entity with linkage having the same name and type, ignoring entities declared
outside the innermost enclosing namespace scope, 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. \begin{example}

\begin{codeblock}
static void f();
static int i = 0;               // \#1
void g() {
  extern void f();              // internal linkage
  int i;                        // \#2 \tcode{i} has no linkage
  {
    extern void f();            // internal linkage
    extern int i;               // \#3 external linkage
  }
}
\end{codeblock}

There are three objects named \tcode{i} in this program. The object with
internal linkage introduced by the declaration in global scope (line
\tcode{\#1} ), the object with automatic storage duration and no linkage
introduced by the declaration on line \tcode{\#2}, and the object with
static storage duration and external linkage introduced by the
declaration on line \tcode{\#3}. \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() @\tcode{\{ /* ... */ \}}@       // definition of \tcode{X::q}        
}

void q() @\tcode{\{ /* ... */ \}}@         // 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~(\ref{basic.scope.block}) has no
linkage. A type is said to have linkage if and only if:
\begin{itemize}
\item it is a class or enumeration type that is named (or has a name for
linkage purposes~(\ref{dcl.typedef})) and the name has linkage; or

\item it is an unnamed class or unnamed enumeration that is a member of a class
with linkage; or

\item it is a specialization of a class template (Clause~\ref{temp})\footnote{A class
template has the linkage of the innermost enclosing class or namespace in which
it is declared.};
or

\item it is a fundamental type~(\ref{basic.fundamental}); or

\item it is a compound type~(\ref{basic.compound}) other than a class or
enumeration, compounded exclusively from types that have linkage; or

\item it is a cv-qualified~(\ref{basic.type.qualifier}) version of a
type that has linkage.
\end{itemize}
A type without linkage shall not be used as the type of a variable or
function with external linkage unless
\begin{itemize}
\item the entity has C language linkage~(\ref{dcl.link}), or

\item the entity is declared within an unnamed
namespace~(\ref{namespace.def}), or

\item the entity is not odr-used~(\ref{basic.def.odr}) or is defined in
the same translation unit.
\end{itemize}
\begin{note}
In other words, a type without linkage contains a class or enumeration that
cannot be named outside its translation unit. An entity with external linkage declared
using such a type could not correspond to any other entity in another translation unit
of the program and thus must be defined in the
translation unit if it is odr-used. Also note that classes with linkage may contain members
whose types do not have linkage, and that typedef names are ignored in the determination
of whether a type has linkage.
\end{note}

\begin{example}
\begin{codeblock}
template <class T> struct B {
  void g(T) { }
  void h(T);
  friend void i(B, T) { }
};

void f() {
  struct A { int x; };  // no linkage
  A a = { 1 };
  B<A> ba;              // declares \tcode{B<A>::g(A)} and \tcode{B<A>::h(A)}
  ba.g(a);              // OK
  ba.h(a);              // error: \tcode{B<A>::h(A) not defined in the translation unit}
  i(ba, a);             // OK
}
\end{codeblock}
\end{example}

\pnum
Two names that are the same (Clause~\ref{basic}) and that are declared
in different scopes shall denote the same variable, function,
type, enumerator, template or namespace if
\begin{itemize}
\item both names have external linkage 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, the parameter-type-lists of the
functions~(\ref{dcl.fct}) are identical; and

\item when both names denote function templates, the
signatures~(\ref{temp.over.link}) are the same.
\end{itemize}

\pnum
\indextext{consistency!type declaration}%
\indextext{declaration!multiple}%
After all adjustments of types (during which
typedefs~(\ref{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~(\ref{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}~(\ref{dcl.link}). \end{note}%
\indextext{linkage|)}

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

\rSec2[basic.start.main]{Main function}

\pnum
\indextext{program!start|(}%
\indextext{\idxcode{main()}}%
A program shall contain a global function called \tcode{main}, which is the designated
start of the program. 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()}!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}~(\ref{dcl.fct}).
\indextext{\idxcode{main()}!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)~(\ref{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()}!implementation-defined linkage~of}%
The linkage~(\ref{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 \tcode{main} function shall not be declared with a
\grammarterm{linkage-specification}~(\ref{dcl.link}).  A program that
declares a variable \tcode{main} at global scope 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}}%
\indexlibrary{\idxcode{exit}}%
\indextext{termination!program}%
Terminating the program
without leaving the current block (e.g., by calling the function
\tcode{std::exit(int)} (\ref{support.start.term})) does not destroy any
objects with automatic storage duration~(\ref{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()}!return from}%
A return statement 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}).

\rSec2[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!\idxcode{static object}}%
\indextext{initialization!constant}%
A \defn{constant initializer} for an object \tcode{o} is an expression that is a
constant expression, except that it may also invoke \tcode{constexpr} constructors
for \tcode{o} and its subobjects even if those objects are of non-literal class
types. \begin{note} Such a class may have a non-trivial destructor. \end{note}
\defnx{Constant initialization}{constant initialization} is performed:
\begin{itemize}
\item
if each full-expression (including implicit conversions) that appears in
the initializer of a reference with static or thread storage duration is a
constant expression~(\ref{expr.const}) and the reference is bound to a glvalue
designating an object with static storage duration, to a temporary object
(see~\ref{class.temporary}) or subobject thereof, or to a function;

\item
if an object with static or thread storage duration is initialized
by a constructor call, and if the initialization full-expression is a constant
initializer for the object;

\item
if an object with static or thread storage duration is not initialized by a constructor call
and if either the object is value-initialized or every full-expression that
appears in its initializer is a constant expression.
\end{itemize}

\indextext{initialization!runtime}%
If constant initialization is not performed, a variable with static
storage duration~(\ref{basic.stc.static}) or thread storage
duration~(\ref{basic.stc.thread}) is zero-initialized~(\ref{dcl.init}).
Together, zero-initialization and constant initialization are called
\indextext{initialization!dynamic}%
\defn{static initialization};
all other initialization is \defn{dynamic initialization}.
Static initialization shall be performed before any dynamic initialization takes place.
\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}

\rSec2[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
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 \tcode{V} is defined before \tcode{W} within
a single translation unit, the initialization of \tcode{V} is sequenced
before the initialization of \tcode{W}.

\item
If \tcode{V} has partially-ordered initialization, \tcode{W} does not have
unordered initialization, and \tcode{V} is defined before \tcode{W} in
every translation unit in which \tcode{W} is defined, the initialization of
\tcode{V} is sequenced before the initialization of \tcode{W} if the
program does not start a thread (\ref{intro.multithread}) and otherwise
happens before the initialization of \tcode{W}.

\item
Otherwise, if a program starts a thread before either \tcode{V} or \tcode{W} is
initialized, the initializations of \tcode{V} and \tcode{W} are unsequenced.

\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{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
happens before the first statement of \tcode{main}. If the initialization is deferred to
happen after the first statement of \tcode{main}, it happens before the
first odr-use~(\ref{basic.def.odr}) 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 must be initialized even if it is not
odr-used (\ref{basic.def.odr},~\ref{basic.stc.static}).}
\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 happens before the
first statement of \tcode{main}. If the initialization is deferred
to happen after the first statement of \tcode{main}, it happens before
the first odr-use~(\ref{basic.def.odr}) of that variable.

\pnum
It is \impldef{dynamic initialization of thread-local variables before entry}
whether the dynamic initialization of a non-local non-inline variable with static
or thread storage duration is sequenced before
the first statement of the initial function of the thread.
If the initialization is deferred to some point in time sequenced after
the first statement of the initial function of the thread,
it is sequenced before the first odr-use~(\ref{basic.def.odr})
of any non-inline variable with thread storage duration defined
in the same translation unit as the variable to be initialized.

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

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

\pnum
\indextext{program!termination|(}%
\indextext{object!destructor static}%
\indextext{\idxcode{main()}!return from}%
Destructors~(\ref{class.dtor}) for initialized objects
(that is, objects whose lifetime~(\ref{basic.life}) has begun)
with static storage duration
are called as a result of returning from \tcode{main} and as a result of calling
\indextext{\idxcode{exit}}%
\indexlibrary{\idxcode{exit}}%
\tcode{std::exit}~(\ref{support.start.term}).
Destructors for initialized objects with thread storage duration within a given thread
are called as a result of returning from the initial function of that thread and as a
result of that thread calling \tcode{std::exit}.
The completions of the destructors for all initialized objects with thread storage
duration within that thread are sequenced before the initiation of the destructors of
any object with static storage duration.
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 the completion of the constructor or dynamic initialization of an object with static
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.
\begin{note} This definition permits concurrent destruction. \end{note} 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,
\tcode{std::terminate} is called~(\ref{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}}%
\indexlibrary{\idxcode{atexit}}%
If the completion of the initialization of an object with static storage
duration is sequenced before a call to \tcode{std::atexit}~(see
\tcode{<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} is sequenced 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} is sequenced 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~(\ref{support.runtime}) that does not happen before~(\ref{intro.multithread})
completion of destruction of objects with static storage duration and execution of
\tcode{std::atexit} registered functions~(\ref{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}}%
\indexlibrary{\idxcode{abort}}%
\indextext{termination!program}%
Calling the function \tcode{std::abort()} declared in
\indextext{\idxhdr{cstdlib}}%
\tcode{<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|)}

\rSec1[basic.stc]{Storage duration}

\pnum
\indextext{storage~duration|(}%
The \defnx{storage duration}{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~(\ref{basic.def}) and implicitly created by
the implementation~(\ref{class.temporary}). The dynamic storage duration
is associated with objects created with \tcode{operator}
\tcode{new}~(\ref{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~(\ref{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.}

\rSec2[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 shall last 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}.

\pnum
\indextext{object!\idxcode{local 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!\idxcode{class static}}%
The keyword \tcode{static} applied to a class data member in a class
definition gives the data member static storage duration.

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

\pnum
\indextext{storage~duration!thread}%
All variables declared with the \tcode{thread_local} keyword have \defn{thread
storage duration}. The storage for these entities shall last 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
A variable with thread storage duration shall be initialized before
its first odr-use~(\ref{basic.def.odr}) and, if constructed, shall be destroyed on thread exit.

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

\pnum
\indextext{storage~duration!automatic}%
\indextext{storage~duration!local object}%
Block-scope variables
not explicitly declared \tcode{static}, \tcode{thread_local}, or \tcode{extern} have
\defn{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}.

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

\pnum
Objects can be created dynamically during program
execution~(\ref{intro.execution}), using
\indextext{\idxcode{new}}%
\grammarterm{new-expression}{s}~(\ref{expr.new}), and destroyed using
\indextext{\idxcode{delete}}%
\grammarterm{delete-expression}{s}~(\ref{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~(\ref{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~(\ref{replacement.functions}). The
following allocation and deallocation functions~(\ref{support.dynamic})
are implicitly declared in global scope in each translation unit of a
program.

\begin{codeblock}
void* operator new(std::size_t);
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;

void* operator new[](std::size_t);
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\colcol{}size_t},
\tcode{std\colcol{}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 including the header \tcode{<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 including the appropriate header. \end{note} Allocation and/or
deallocation functions may also be declared and defined for any
class~(\ref{class.free}).

\pnum
Any allocation and/or deallocation functions defined in a \Cpp program,
including the default versions in the library, shall conform to the
semantics specified in~\ref{basic.stc.dynamic.allocation}
and~\ref{basic.stc.dynamic.deallocation}.

\rSec3[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}~(\ref{support.types}). The
first parameter shall not have an associated default
argument~(\ref{dcl.fct.default}). The value of the first parameter shall
be 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
The allocation function attempts to allocate the requested amount of
storage. If it is successful, it shall return the address of the start
of a block of storage whose length in bytes shall be at least as large
as the requested size. There are no constraints on the contents of the
allocated storage on return from the allocation function. The order,
contiguity, and initial value of storage allocated by successive calls
to an allocation function are unspecified. The pointer returned shall be
suitably aligned so that it can be converted to a pointer to any
suitable complete object type~(\ref{new.delete.single})
and then used to access the object or array in the
storage allocated (until the storage is explicitly deallocated by a call
to a corresponding deallocation function). Even if the size of the space
requested is zero, the request can fail. If the request succeeds, the
value returned shall be a non-null pointer value~(\ref{conv.ptr})
\tcode{p0} different from any previously returned value \tcode{p1},
unless that value \tcode{p1} was subsequently passed to an
\tcode{operator} \tcode{delete}.
Furthermore, for the library allocation functions
in~\ref{new.delete.single} and~\ref{new.delete.array},
\tcode{p0} shall represent 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 as 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
An allocation function that fails to allocate storage can invoke the
currently installed new-handler function~(\ref{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~(\ref{set.new.handler}). \end{note}
If an allocation function that has a non-throwing
exception specification~(\ref{except.spec})
fails to allocate storage, it shall return a null pointer. Any other
allocation function that fails to allocate storage shall indicate
failure only by throwing an exception~(\ref{except.throw}) of a type
that would match a handler~(\ref{except.handle}) of type
\tcode{std::bad_alloc}~(\ref{bad.alloc}).

\pnum
A global allocation function is only called as the result of a new
expression~(\ref{expr.new}), or called directly using the function call
syntax~(\ref{expr.call}), 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~(\ref{basic.stc.static}), for objects or references
with thread storage duration~(\ref{basic.stc.thread}), for objects of
type \tcode{std::type_info}~(\ref{expr.typeid}), or for an
exception object~(\ref{except.throw}).
\end{note}

\rSec3[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
\indextext{\idxcode{delete}!overloading~and}%
Each deallocation function shall return \tcode{void} and 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 that has:
\begin{itemize}
\item
exactly one parameter; or
\item
exactly two parameters,
the type of the second being either
\tcode{std::align_val_t} or
\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}).}; or
\item
exactly three parameters,
the type of the second being \tcode{std::size_t}
and
the type of the third being \tcode{std::align_val_t}.
\end{itemize}
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. \begin{note} That is, a deallocation function
template shall have a first parameter of type \tcode{void*} and a return
type of \tcode{void} (as specified above). \end{note} 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~(\ref{conv.ptr}), the
deallocation function shall deallocate the storage referenced by the
pointer, ending the duration of the region of storage.

\rSec3[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~(\ref{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~(\ref{basic.fundamental}), where the size and alignment of the sequence
match those of some object pointer type.
\end{itemize}

\pnum
\indextext{safely-derived pointer}%
A pointer value is a \grammarterm{safely-derived pointer} to a dynamic object only if it
has an object pointer type and it 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\colcol{}size_t)} or
\tcode{::operator new(std\colcol{}size_t, std\colcol{}align_val_t)}%
;\footnote{This section 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\colcol{}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~(\ref{expr.add}) using a safely-derived pointer
value;

\item the result of a well-defined pointer
conversion~(\ref{conv.ptr},~\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{safely-derived pointer!integer representation}%
\indextext{pointer, integer representation of safely-derived}%
An integer value is an \grammarterm{integer representation of a safely-derived pointer}
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~(\ref{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.dynamic.deallocation}.
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|)}

\rSec2[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~(\ref{intro.object}).
\indextext{storage~duration|)}%

\rSec1[basic.life]{Object lifetime}

\pnum
\indextext{object~lifetime|(}%
The \defn{lifetime} of an object or reference is a runtime property of the
object or reference.
An object is said to have \defnx{non-vacuous initialization}{initialization!non-vacuous} if it is of a class or
aggregate type and it or one of its subobjects is initialized by a constructor
other than a trivial default constructor. \begin{note} initialization by a
trivial copy/move constructor is non-vacuous initialization. \end{note}
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 if the object has non-vacuous initialization, its initialization is complete,
\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 class type with a non-trivial
destructor~(\ref{class.dtor}), 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}~(\ref{intro.object}).
\end{itemize}

\pnum
The lifetime of a reference begins when its initialization is complete.
The lifetime of a reference ends as if it were a scalar object.

\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 International
Standard 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 objects during the
construction and destruction phases. \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 with a non-trivial destructor. For an object of a
class type with a non-trivial destructor, 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}~(\ref{expr.delete})
is not used to release the storage, the destructor shall not be
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 of
non-POD class type~(\ref{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~(\ref{basic.stc.dynamic.deallocation}), 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~(\ref{conv.ptr}) to a pointer
to a virtual base class, or

\item the pointer is used as the operand of a
\tcode{static_cast}~(\ref{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 either \cv{}
\tcode{char} or \cv{} \tcode{unsigned char}, or

\item the pointer is used as the operand of a
\tcode{dynamic_cast}~(\ref{expr.dynamic.cast}). \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}
\end{itemize}

\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~(\ref{basic.stc.dynamic.deallocation}), 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~(\ref{dcl.init.ref}), or
\item the glvalue is used as the operand of a
\tcode{dynamic_cast}~(\ref{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 type of the original object is not const-qualified, and, if a
class type, does not contain any non-static data member whose type is
const-qualified or a reference type, and

\item the original object was a most derived object~(\ref{intro.object})
of type \tcode{T} and the new object is a most derived object of type
\tcode{T} (that is, they are not base class subobjects).
\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}~(\ref{support.dynamic}).
\end{note}

\pnum
If a program ends the lifetime of an object of type \tcode{T} with
static~(\ref{basic.stc.static}), thread~(\ref{basic.stc.thread}),
or automatic~(\ref{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 \tcode{const} complete
object with static, thread, or automatic storage duration occupies,
or within the storage that such a \tcode{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 section, ``before'' and ``after'' refer to the ``happens before''
relation~(\ref{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|)}

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

\pnum
\indextext{object!byte~copying~and|(}%
\indextext{type!trivially~copyable}%
For any object (other than a base-class subobject) of trivially copyable type
\tcode{T}, whether or not the object holds a valid value of type
\tcode{T}, the underlying bytes~(\ref{intro.memory}) making up the
object can be copied into an array of \tcode{char} or \tcode{unsigned}
\tcode{char}.\footnote{By using, for example, the library
functions~(\ref{headers}) \tcode{std::memcpy} or \tcode{std::memmove}.}
If the content of the array of \tcode{char} or \tcode{unsigned}
\tcode{char} is copied back into the object, the object shall
subsequently hold its original value. \begin{example}

\begin{codeblock}
#define 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 base-class subobject, if the underlying
bytes~(\ref{intro.memory}) making up
\tcode{obj1} are copied into \tcode{obj2},\footnote{By using, for example,
the library functions~(\ref{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 \defn{object representation}
\indextext{representation!object}%
of an object of type \tcode{T} is the
sequence of \placeholder{N} \tcode{unsigned} \tcode{char} objects taken up
by the object of type \tcode{T}, where \placeholder{N} equals
\tcode{sizeof(T)}. The
\indextext{representation!value}%
\defn{value representation}
of an object is the set of bits that hold
the value of type \tcode{T}. 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~(\ref{dcl.enum}), or an array of unknown
size or of incomplete element type, is an
\defnx{incompletely-defined object type}{object type!incompletely-defined}.%
\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}~(\ref{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 size, or of a type defined by a \tcode{typedef} declaration to
be an array of unknown size, 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
\indextext{object~type}%
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
Arithmetic types~(\ref{basic.fundamental}), enumeration types, pointer
types, pointer to member types~(\ref{basic.compound}),
\tcode{std::nullptr_t},
and
cv-qualified versions of these
types~(\ref{basic.type.qualifier}) are collectively called
\defnx{scalar types}{scalar~type}. Scalar types,
POD classes (Clause~\ref{class}), arrays of such types and
cv-qualified versions of these
types~(\ref{basic.type.qualifier}) are collectively called
\defnx{POD types}{type!POD}.
Cv-unqualified scalar types, trivially copyable class types (Clause~\ref{class}), arrays of
such types, and cv-qualified versions of these
types~(\ref{basic.type.qualifier}) are collectively called \defn{trivially
copyable types}.
Scalar types, trivial class types (Clause~\ref{class}),
arrays of such types and cv-qualified versions of these
types~(\ref{basic.type.qualifier}) are collectively called
\defn{trivial types}. Scalar types, standard-layout class
types (Clause~\ref{class}), arrays of such types and
cv-qualified versions of these types~(\ref{basic.type.qualifier})
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 (Clause~\ref{class}) that
has all of the following properties:
\begin{itemize}
\item it has a trivial destructor,
\item it is either a closure type~(\ref{expr.prim.lambda}),
an aggregate type~(\ref{dcl.init.aggr}), or
has at least one \tcode{constexpr} constructor or constructor template
(possibly inherited~(\ref{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}

\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~(\ref{dcl.enum}), or
layout-compatible standard-layout class types~(\ref{class.mem}).

\rSec2[basic.fundamental]{Fundamental types}

\pnum
\indextext{type!fundamental}%
\indextext{type!integral}%
\indextext{type!floating point}%
\indextext{type!implementation-defined @\tcode{sizeof}}%
\indextext{type!Boolean}%
\indextext{type!\idxcode{char}}%
\indextext{type!character}%
Objects declared as characters (\tcode{char}) shall be large enough to
store any member of the implementation's basic character set. If a
character from this set is stored in a character object, the integral
value of that character object is equal to the value of the single
character literal form of that character. It is \impldef{signedness of \tcode{char}}
whether a \tcode{char} object can hold negative values.
\indextext{\idxcode{char}!implementation-defined sign~of}%
\indextext{type!\idxcode{signed char}}%
\indextext{type!\idxcode{unsigned char}}%
Characters can be explicitly declared \tcode{unsigned} or
\tcode{signed}.
\indextext{character!\idxcode{signed}}%
Plain \tcode{char}, \tcode{signed char}, and \tcode{unsigned char} are
three distinct types, collectively called
\defnx{narrow character types}{type!narrow character}.
A \tcode{char}, a \tcode{signed char}, and an
\tcode{unsigned char} occupy the same amount of storage and have the
same alignment requirements~(\ref{basic.align}); that is, they have the
same object representation. For narrow character types, all bits of the object
representation participate in the value representation.
\begin{note}
A bit-field of narrow character type whose length is larger than
the number of bits in the object representation of that type has
padding bits; see~\ref{class.bit}.
\end{note}
For unsigned narrow
character types, each possible bit pattern of the value representation
represents a distinct number. These requirements do not hold for other types. In
any particular implementation, a plain \tcode{char} object can take on
either the same values as a \tcode{signed char} or an \tcode{unsigned
char}; which one is \impldef{representation of \tcode{char}}.
For each value \placeholder{i} of type \tcode{unsigned char} in the range
0 to 255 inclusive, there exists a value \placeholder{j} of type
\tcode{char} such that the result of an integral
conversion~(\ref{conv.integral}) from \placeholder{i} to \tcode{char} is
\placeholder{j}, and the result of an integral conversion from
\placeholder{j} to \tcode{unsigned char} is \placeholder{i}.

\pnum
\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} \tcode{long} \tcode{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}.
\indextext{integral~type!implementation-defined @\tcode{sizeof}}%
Plain
\tcode{int}s have the natural size suggested by the architecture of the
execution environment%
\footnote{\tcode{int} must also be large enough
to contain any value in the range
\crange{INT_MIN}{INT_MAX},
as defined in the header \tcode{<climits>}.};
the other signed integer types are provided to meet special needs.

\pnum
\indextext{type!\idxcode{unsigned}}%
For each of the standard signed integer types,
there exists a corresponding (but different)
\indextext{type!standard~unsigned~integer}%
\defnx{standard unsigned integer type}{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} \tcode{long} \tcode{long} \tcode{int}'', each of
which occupies the same amount of storage and has the same alignment
requirements~(\ref{basic.align}) as the corresponding signed integer
type\footnote{See~\ref{dcl.type.simple} regarding the correspondence between types and
the sequences of \grammarterm{type-specifier}{s} that designate them.};
that is, each signed integer type has the same object representation as
its corresponding unsigned integer type.
\indextext{type!extended~unsigned~integer}%
\indextext{type!unsigned~integer}%
Likewise, for each of the extended signed integer types there exists a
corresponding
\defnx{extended unsigned integer type}{extended~unsigned~integer~type} with the same amount of storage and alignment
requirements. The standard and extended unsigned integer types are
collectively called \defnx{unsigned integer types}{unsigned~integer~type}. The range of non-negative
values of a signed integer type is a subrange of the corresponding
unsigned integer type, and the value
representation of each corresponding signed/unsigned type shall be the
same.
\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}. The signed and unsigned integer types shall satisfy
the constraints given in the C standard, section 5.2.4.2.1.

\pnum
\indextext{arithmetic!\idxcode{unsigned}}%
Unsigned integers shall obey the laws of arithmetic modulo $2^n$ where $n$ is
the number of bits in the value representation of that particular size of
integer.\footnote{This implies that
unsigned arithmetic does not overflow because a result
that cannot be represented by the resulting unsigned integer type is
reduced modulo the number that is one greater than the largest value
that can be represented by the resulting unsigned integer type.}

\pnum
\indextext{\idxcode{char16_t}|see{type, \tcode{char16_t}}}%
\indextext{\idxcode{char32_t}|see{type, \tcode{char32_t}}}%
\indextext{\idxcode{wchar_t}|see{type, \tcode{wchar_t}}}%
\indextext{type!\idxcode{char16_t}}%
\indextext{type!\idxcode{char32_t}}%
\indextext{type!\idxcode{wchar_t}}%
\indextext{underlying~type|see{type, underlying}}%
\indextext{type!underlying!\idxcode{char16_t}}%
\indextext{type!underlying!\idxcode{char32_t}}%
Type \tcode{wchar_t} is a distinct type whose values can represent
distinct codes for all members of the largest extended character set
specified among the supported locales~(\ref{locale}). Type
\tcode{wchar_t} shall have the same size, signedness, and alignment
requirements~(\ref{basic.align}) as one of the other integral types,
called its \defnx{underlying type}{type!underlying!\idxcode{wchar_t}}. Types \tcode{char16_t} and
\tcode{char32_t} denote distinct types with the same size, signedness,
and alignment as \tcode{uint_least16_t} and \tcode{uint_least32_t},
respectively, in \tcode{<cstdint>}, called the underlying types.

\pnum
\indextext{Boolean~type}%
Values of type \tcode{bool} are either \tcode{true} or
\tcode{false}.\footnote{Using a \tcode{bool} value in ways described by this International
Standard as ``undefined,'' such as by examining the value of an
uninitialized automatic object, might cause it to behave as if it is
neither \tcode{true} nor \tcode{false}.}
\begin{note} There are no \tcode{signed}, \tcode{unsigned}, \tcode{short},
or \tcode{long bool} types or values. \end{note} Values of type
\tcode{bool} participate in integral promotions~(\ref{conv.prom}).

\pnum
Types \tcode{bool}, \tcode{char}, \tcode{char16_t}, \tcode{char32_t},
\tcode{wchar_t}, and the signed and unsigned integer types are
collectively called
\defnx{integral}{integral~type} types.\footnote{Therefore, enumerations~(\ref{dcl.enum}) are not integral; however,
enumerations can be promoted to integral types as specified
in~\ref{conv.prom}.}
A synonym for integral type is
\indextext{signed integer representation!ones' complement}%
\indextext{signed integer representation!two's complement}%
\indextext{signed integer representation!signed magnitude}%
\defnx{integer type}{integer~type}. The representations of integral types shall
define values by use of a pure binary numeration system.\footnote{A positional
representation for integers that uses the binary digits 0
and 1, in which the values represented by successive bits are additive,
begin with 1, and are multiplied by successive integral power of 2,
except perhaps for the bit with the highest position. (Adapted from the
\doccite{American National Dictionary for Information Processing Systems}.)}
\begin{example} this International Standard permits two's complement,
ones' complement and signed magnitude representations for integral types.
\end{example}

\pnum
There are three \defnx{floating point}{floating~point~type} types:
\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} \tcode{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 International Standard imposes no requirements on the accuracy of
floating-point operations; see also~\ref{limits}. 
\end{note}
Integral and floating 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}~(\ref{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.cast}).
An expression of type \cv{} \tcode{void} shall
be used only as an expression statement~(\ref{stmt.expr}), as an operand
of a comma expression~(\ref{expr.comma}), as a second or third operand
of \tcode{?:}~(\ref{expr.cond}), as the operand of
\tcode{typeid}, \tcode{noexcept}, or \tcode{decltype}, as
the expression in a return statement~(\ref{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~(\ref{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
\begin{note}
Even if the implementation defines two or more basic 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 \defnx{lvalue reference}{lvalue~reference}
\item \defnx{rvalue reference}{rvalue~reference}
\end{itemize}

\item
\defnx{classes}{class} containing a sequence of objects of various types
(Clause~\ref{class}), a set of types, enumerations and functions for
manipulating these objects~(\ref{class.mfct}), and a set of restrictions
on the access to these entities (Clause~\ref{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
\defnx{enumerated type}{type!enumerated},~\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}.
\end{itemize}

\pnum
These methods of constructing types can be applied recursively;
restrictions are mentioned in~\ref{dcl.ptr}, \ref{dcl.array},
\ref{dcl.fct}, and~\ref{dcl.ref}. 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}~(\ref{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 objects 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~(\ref{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 (\ref{expr.add}), or
\item
the \defn{null pointer value} (\ref{conv.ptr}) for that type, or
\item
an \defn{invalid pointer value}.
\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~(\ref{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~(\ref{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~(\ref{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 element $\mathtt{x[}n\mathtt{]}$.
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~(\ref{basic.align}).
\begin{note} Pointers to over-aligned types~(\ref{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 standard-layout union object and
the other is a non-static data member of that object~(\ref{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,
the first base class subobject of that object~(\ref{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}~(\ref{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~(\ref{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 \defnx{cv-unqualified type}{type!cv-unqualified}. Each type which is a
cv-unqualified complete or incomplete object type or is
\tcode{void}~(\ref{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 term
\term{object type}~(\ref{intro.object}) includes the cv-qualifiers
specified in the \grammarterm{decl-specifier-seq}~(\ref{dcl.spec}), 
\grammarterm{declarator} (Clause~\ref{dcl.decl}),
\grammarterm{type-id}~(\ref{dcl.name}), or 
\grammarterm{new-type-id}~(\ref{expr.new}) when the object is created.
\begin{itemize}
\item A \defnx{const object}{object!const} is an object of type \tcode{const T} or a
  non-mutable subobject of such an object.

\item A \defnx{volatile object}{object!volatile} is an object of type
  \tcode{volatile T}, a subobject of such an object, or a mutable
  subobject of a const volatile object.

\item A \defnx{const volatile object}{object!const volatile} is an object of type
  \tcode{const volatile T}, a non-mutable subobject of such an 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~(\ref{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~(\ref{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,
not the array type~(\ref{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 \grammarterm{more cv-qualified} than another.
Table~\ref{tab:relations.on.const.and.volatile} shows the relations that
constitute this ordering.

\begin{floattable}{Relations on \tcode{const} and \tcode{volatile}}{tab:relations.on.const.and.volatile}
{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 International Standard, 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.%
\indextext{type|)}
\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}

\rSec1[basic.lval]{Lvalues and rvalues}
\pnum
Expressions are categorized according to the taxonomy in Figure~\ref{fig:categories}.

\begin{importgraphic}
{Expression category taxonomy}
{fig:categories}
{valuecategories.pdf}
\end{importgraphic}

\begin{itemize}
\item A \defn{glvalue} is an expression whose evaluation determines the identity of an object, bit-field, or function.
\item A \defn{prvalue} is an expression whose evaluation initializes an object or a bit-field,
or computes the value of the operand of an operator,
as specified by the context in which it appears.
\item An \defn{xvalue} is a glvalue that denotes an object or bit-field whose resources can be reused (usually because it is near the end of its lifetime).
\begin{example}
Certain kinds of expressions involving rvalue references~(\ref{dcl.ref}) yield xvalues,
such as a call to a function whose return type is an rvalue reference
or a cast to an rvalue reference type.
\end{example}
\item An \defn{lvalue} is a glvalue that is not an xvalue.
\item An \defn{rvalue} is a prvalue or an xvalue.
\end{itemize}
\begin{note}
Historically, lvalues and rvalues were so-called
because they could appear on the left- and right-hand side of an assignment
(although this is no longer generally true);
glvalues are ``generalized'' lvalues,
prvalues are ``pure'' rvalues,
and xvalues are ``eXpiring'' lvalues.
Despite their names, these terms classify expressions, not values.
\end{note}
Every expression belongs to exactly one of the fundamental classifications in this
taxonomy: lvalue, xvalue, or prvalue. This property of an expression is called
its \defn{value category}. \begin{note} The discussion of each built-in operator in
Clause~\ref{expr} indicates the category of the value it yields and the value categories
of the operands it expects. For example, the built-in assignment operators expect that
the left operand is an lvalue and that the right operand is a prvalue and yield an
lvalue as the result. User-defined operators are functions, and the categories of
values they expect and yield are determined by their parameter and return types. \end{note}

\pnum
The \defnx{result}{result!prvalue} of a prvalue
is the value that the expression stores into its context.
A prvalue whose result is the value \placeholder{V}
is sometimes said to have or name the value \placeholder{V}.
The \defn{result object} of a prvalue
is the object initialized by the prvalue;
a prvalue
that is used to compute the value of an operand of an operator or
that has type (possibly cv-qualified) \tcode{void}
has no result object.
\begin{note}
Except when the prvalue is the operand of a \grammarterm{decltype-specifier},
a prvalue of class or array type always has a result object.
For a discarded prvalue, a temporary object is materialized; see Clause~\ref{expr}.
\end{note}
The \defnx{result}{result!glvalue} of a glvalue is the entity denoted by the expression.

\pnum
\begin{note}
Whenever a glvalue appears in a context where a prvalue is expected, the glvalue is converted
to a prvalue; see~\ref{conv.lval}, \ref{conv.array},
and~\ref{conv.func}.
An attempt to bind an rvalue reference to an lvalue is not such a context; see~\ref{dcl.init.ref}.
\end{note}
\begin{note}
There are no prvalue bit-fields; if a bit-field is converted to a
prvalue~(\ref{conv.lval}), a prvalue of the type of the bit-field is
created, which might then be promoted~(\ref{conv.prom}).
\end{note}

\pnum
\begin{note}
Whenever a prvalue appears in a context where a glvalue is expected,
the prvalue is converted to an xvalue; see~\ref{conv.rval}.
\end{note}

\pnum
The discussion of reference initialization in~\ref{dcl.init.ref} and of
temporaries in~\ref{class.temporary} indicates the behavior of lvalues
and rvalues in other significant contexts.

\pnum
Unless otherwise indicated~(\ref{expr.call}),
a prvalue shall always have complete type or the \tcode{void} type.
A glvalue shall not have type \cv{} \tcode{void}.
\begin{note}
A glvalue may have complete or incomplete non-\tcode{void} type.
Class and array prvalues can have cv-qualified types; other prvalues
always have cv-unqualified types. See Clause~\ref{expr}.
\end{note}

\pnum
An lvalue is \defn{modifiable} unless its type is const-qualified
or is a function type.
\begin{note}
A program that attempts
to modify an object through a nonmodifiable lvalue expression or through an rvalue expression
is ill-formed~(\ref{expr.ass}, \ref{expr.post.incr}, \ref{expr.pre.incr}).
\end{note}

\pnum
If a program attempts to access the stored value of an object through a glvalue
of other than one of the following types the behavior is
undefined:\footnote{The intent of this list is to specify those circumstances in which an
object may or may not be aliased.}
\begin{itemize}
\item the dynamic type of the object,

\item a cv-qualified version of the dynamic type of the object,

\item a type similar (as defined in~\ref{conv.qual}) to the dynamic type
of the object,

\item a type that is the signed or unsigned type corresponding to the
dynamic type of the object,

\item a type that is the signed or unsigned type corresponding to a
cv-qualified version of the dynamic type of the object,

\item an aggregate or union type that includes one of the aforementioned types among its
elements or non-static data members (including, recursively, an element or non-static data member of a
subaggregate or contained union),

\item a type that is a (possibly cv-qualified) base class type of the dynamic type of
the object,

\item a \tcode{char} or \tcode{unsigned} \tcode{char} type.
\end{itemize}

\rSec1[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~(\ref{dcl.align}).

\pnum
\indextext{alignment!fundamental}%
A \defnx{fundamental alignment}{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)}~(\ref{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}%
\indextext{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~(\ref{dcl.align}). A type having an extended alignment
requirement is an \grammarterm{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}~(\ref{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~(\ref{expr.alignof}). Furthermore,
the narrow character types~(\ref{basic.fundamental}) shall have the weakest
alignment requirement.
\begin{note} This enables the narrow character types to be used as the
underlying type for an aligned memory area~(\ref{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~(\ref{ptr.align})
can be used to obtain an aligned pointer within a buffer; the aligned-storage templates
in the library~(\ref{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.