%!TEX root = std.tex \rSec0[basic]{Basic concepts} %gram: \rSec1[gram.basic]{Basic concepts} %gram: \pnum \enternote This Clause presents the basic concepts of the \Cpp language. It explains the difference between an \term{object} and a \term{name} and how they relate to the value categories for expressions. It introduces the concepts of a \term{declaration} and a \term{definition} and presents \Cpp's notion of \term{type}, \term{scope}, \term{linkage}, and \term{storage} \term{duration}. The mechanisms for starting and terminating a program are discussed. Finally, this Clause presents the \term{fundamental} types of the language and lists the ways of constructing \term{compound} types from these.\exitnote \pnum \enternote This Clause does not cover concepts that affect only a single part of the language. Such concepts are discussed in the relevant Clauses. \exitnote \pnum \indextext{name}% \indextext{declaration}% \indextext{type}% \indextext{object}% \indextext{storage~class}% \indextext{scope}% \indextext{linkage}% \indextext{region!declarative}% \indextext{entity}% An \defn{entity} is a value, object, reference, function, enumerator, type, class member, bit-field, template, template specialization, namespace, parameter pack, or \tcode{this}. \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 \term{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 \indextext{lookup!name}% \term{name lookup}~(\ref{basic.lookup}). \pnum Two names are \term{the 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 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 it declares a function without specifying the function's body~(\ref{dcl.fct.def}), 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}, \indextext{declaration!\idxcode{static member}}% it declares a static data member in a class definition (\ref{class.mem},~\ref{class.static}), \indextext{declaration!class~name}% it is a class name declaration~(\ref{class.name}), it is an \indextext{declaration!opaque~enum}% \grammarterm{opaque-enum-declaration}~(\ref{dcl.enum}), it is a \indextext{parameter!template}\indextext{template parameter}% \grammarterm{template-parameter}~(\ref{temp.param}), 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}, or it is a \indextext{declaration!\idxcode{typedef}}% \tcode{typedef} declaration~(\ref{dcl.typedef}), an \grammarterm{alias-declaration}~(\ref{dcl.typedef}), a \grammarterm{using-declaration}~(\ref{namespace.udecl}), a \grammarterm{static_assert-declaration} (Clause~\ref{dcl.dcl}), an \grammarterm{attribute-declaration} (Clause~\ref{dcl.dcl}), an \grammarterm{empty-declaration} (Clause~\ref{dcl.dcl}), a \grammarterm{using-directive}~(\ref{namespace.udir}), an explicit instantiation declaration~(\ref{temp.explicit}), or an explicit specialization~(\ref{temp.expl.spec}) whose \grammarterm{declaration} is not a definition. \enterexample 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} \exitexample \pnum \enternote \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. \exitnote \enterexample given \begin{codeblock} #include 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(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(x.s); return *this; } // \tcode{\{ s = std::move(x.s); return *this; \}} ~C() { } }; \end{codeblock} \exitexample \pnum \enternote A class name can also be implicitly declared by an \grammarterm{elaborated-type-specifier}~(\ref{dcl.type.elab}). \exitnote \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.general}), the set contains only \tcode{e}. \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} \enternote 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}. \enterexample 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} \exitexample \exitnote \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}). \enternote This covers calls to named functions~(\ref{expr.call}), operator overloading (Clause~\ref{over}), user-defined conversions~(\ref{class.conv.fct}), allocation function for placement new~(\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}). \exitnote 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; 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 shall be defined in every translation unit in which it is odr-used. \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. \enterexample 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} \exitexample \enternote 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 \term{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} \exitnote \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.fct.spec}), 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 a non-volatile \tcode{const} object with internal or no linkage if the object has the same literal type in all definitions of \tcode{D}, and the object is initialized with a constant expression~(\ref{expr.const}), and the object is not odr-used, and the object has the same value in all definitions of \tcode{D}; 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 three requirements described above (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 base class or a class member of \tcode{D}. \enterexample \begin{codeblock} //translation unit 1: struct X { X(int); X(int, int); }; X::X(int = 0) { } class D: public X { }; D d2; // \tcode{X(int)} called by \tcode{D()} //translation unit 2: struct X { X(int); X(int, int); }; X::X(int = 0, int = 0) { } class D: public X { }; // \tcode{X(int, int)} called by \tcode{D()}; // \tcode{D()}'s implicit definition // violates the ODR \end{codeblock} \exitexample \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 \enterexample 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. \exitexample \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 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}). \enternote A namespace name or a class template name must be unique in its declarative region~(\ref{namespace.alias}, Clause~\ref{temp}). \exitnote \end{itemize} \enternote 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. \exitnote \pnum \enternote The name lookup rules are summarized in~\ref{basic.lookup}. \exitnote \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. \enterexample \begin{codeblock} unsigned char x = 12; { unsigned char x = x; } \end{codeblock} Here the second \tcode{x} is initialized with its own (indeterminate) value. \exitexample \pnum \enternote \indextext{name~hiding}% a name from an outer scope remains visible up to the point of declaration of the name that hides it.\enterexample \begin{codeblock} const int i = 2; { int i[i]; } \end{codeblock} declares a block-scope array of two integers. \exitexample \exitnote \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-declaration} that does not name a constructor is immediately after the \grammarterm{using-declaration}~(\ref{namespace.udecl}). \pnum \indextext{declaration!enumerator point~of}% The point of declaration for an enumerator is immediately after its \grammarterm{enumerator-definition}.\enterexample \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. \exitexample \pnum After the point of declaration of a class member, the member name can be looked up in the scope of its class. \enternote \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} \exitnote \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. \enternote These rules also apply within templates. \exitnote \enternote 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}. \exitnote \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}. \enterexample \begin{codeblock} typedef unsigned char T; template struct A { }; \end{codeblock} \exitexample \pnum \enternote 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. \exitnote \pnum \enternote For point of instantiation of a template, see~\ref{temp.point}.\exitnote% \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{for-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{scope!function}% \indextext{label!scope~of}% Labels~(\ref{stmt.label}) have \term{function scope} 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. \enterexample \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} \exitexample \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{enumeraten} \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{exception-specification}{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 If reordering member declarations in a class yields an alternate valid program under (1) and (2), the program is ill-formed, no diagnostic is required. \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})).\enterexample \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} \exitexample \end{enumeraten} \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. \enterexample \begin{codeblock} namespace N { template struct A { }; // \#1 template void f(U) { } // \#2 struct B { template 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.) \exitexample \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. \enternote 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 X { /* ... */ }; template 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 X : public Array { /* ... */ }; template 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. \exitnote \pnum The declarative region of the name of a template parameter is nested within the immediately-enclosing declarative region. \enternote As a result, a \grammarterm{template-parameter} hides any entity with the same name in an enclosing scope~(\ref{basic.scope.hiding}). \enterexample \begin{codeblock} typedef int N; template 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}. \exitexample\exitnote \pnum \enternote 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}. \exitnote \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 \enternote \ref{basic.link} discusses linkage issues. The notions of scope, point of declaration and name hiding are discussed in~\ref{basic.scope}. \exitnote \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}. \enternote 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. \exitnote \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. \enterexample \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} \exitexample \pnum A name used in the definition of a class \tcode{X} outside of a member function body, default argument, \grammarterm{exception-specification}, \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} \enterexample \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} \exitexample \enternote 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}. \exitnote \enternote \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. \exitnote \pnum For the members of a class \tcode{X}, a name used in a member function body, in a default argument, in an \grammarterm{exception-specification}, 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{exception-specification}.}, 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} \enterexample \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} \exitexample \enternote \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. \exitnote \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. \enterexample \begin{codeblock} struct A { typedef int AT; void f1(AT); void f2(float); template 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(); // template argument is \tcode{B::AT} }; \end{codeblock} \exitexample \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. \enternote \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}. \exitnote \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}. \enternote \ref{class.static.data} further describes the restrictions on the use of names in the definition of a \tcode{static} data member. \exitnote \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. \enterexample \begin{codeblock} namespace N { int i = 4; extern int j; } int i = 2; int N::j = i; // \tcode{N::j == 4} \end{codeblock} \exitexample \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}. \enternote But function parameter names are found. \exitnote \pnum \enternote The rules for name lookup in template definitions are described in~\ref{temp.res}. \exitnote \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). \enterexample \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} \exitexample \pnum For each argument type \tcode{T} in the function call, there is a set of zero or more associated namespaces and a set of zero or more associated classes to be considered. The sets of namespaces and classes is 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. \enternote Non-type template arguments do not contribute to the set of associated namespaces.\exitnote \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 \term{X} be the lookup set produced by unqualified lookup~(\ref{basic.lookup.unqual}) and let \term{Y} be the lookup set produced by argument dependent lookup (defined as follows). If \term{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 or a function template \end{itemize} then \term{Y} is empty. Otherwise \term{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 \term{X} and \term{Y}. \enternote The namespaces and classes associated with the argument types can include namespaces and classes already considered by the ordinary unqualified lookup. \exitnote \enterexample \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} \exitexample \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.\enterexample \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} \exitexample \pnum \enternote 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. \exitnote \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. \enterexample \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} \exitexample \pnum \indextext{scope~resolution~operator}% 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. \enterexample \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} \exitexample \enternote \ref{basic.lookup.classref} describes how name lookup proceeds after the \tcode{.} and \tcode{->} operators. \exitnote \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}). \enternote A class member can be referred to using a \grammarterm{qualified-id} at any point in its potential scope~(\ref{basic.scope.class}). \exitnote The exceptions to the name lookup rule above are the following: \begin{itemize} \item a destructor name is looked up 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-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}. \enternote 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. \exitnote 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}. \enterexample \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} \exitexample \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. \enterexample \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} \exitexample \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. \enterexample \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} \exitexample \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. \enterexample \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} \exitexample 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}. \enterexample \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} \exitexample \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. \enterexample \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} \exitexample % \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}. \enterexample \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}\exitexample \pnum If the \grammarterm{id-expression} in a class member access is a \grammarterm{qualified-id} of the form \begin{indented} \tcode{class-name-or-namespace-name::...} \end{indented} 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}. \enternote See~\ref{basic.lookup.qual}, which describes the lookup of a name before \tcode{::}, which will only find a type or namespace name. \exitnote \pnum If the \grammarterm{qualified-id} has the form \begin{indented} \tcode{::class-name-or-namespace-name::...} \end{indented} 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. \enterexample \begin{codeblock} struct A { }; namespace N { struct A { void g() { } template operator T(); }; } int main() { N::A a; a.operator A(); // calls \tcode{N::A::operator N::A} } \end{codeblock} \exitexample \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 \defn{translation units} (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 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.\enterexample \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}. \exitexample \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. \enterexample \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} \exitexample \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 enumeration 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} \enternote 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. \exitnote \enterexample \begin{codeblock} template 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 ba; // declares \tcode{B::g(A)} and \tcode{B::h(A)} ba.g(a); // OK ba.h(a); // error: \tcode{B::h(A) not defined in the translation unit} i(ba, a); // OK } \end{codeblock} \exitexample \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 \enternote Linkage to non-\Cpp declarations can be achieved using a \grammarterm{linkage-specification}~(\ref{dcl.link}). \exitnote% \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. \enternote 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. \exitnote \pnum An implementation shall not predefine the \tcode{main} function. This function shall not be overloaded. 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. \enternote It is recommended that any further (optional) parameters be added after \tcode{argv}. \exitnote \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 name \tcode{main} is not otherwise reserved. \enterexample member functions, classes, and enumerations can be called \tcode{main}, as can entities in other namespaces. \exitexample \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 reaches the end of \tcode{main} without encountering a \tcode{return} statement, the effect is that of executing \begin{codeblock} return 0; \end{codeblock} \rSec2[basic.start.init]{Initialization of non-local variables} \pnum \indextext{initialization}% \indextext{initialization!static and thread}% There are two broad classes of named non-local variables: those with static storage duration~(\ref{basic.stc.static}) and those with thread storage duration~(\ref{basic.stc.thread}). Non-local variables with static storage duration are initialized as a consequence of program initiation. Non-local 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!dynamic}% \indextext{initialization!run-time}% \indextext{start!program}% \indextext{initialization!order~of}% Variables with static storage duration~(\ref{basic.stc.static}) or thread storage duration~(\ref{basic.stc.thread}) shall be zero-initialized~(\ref{dcl.init}) before any other initialization takes place. A \term{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 \enternote such a class may have a non-trivial destructor \exitnote. \indextext{initialization!constant}% \term{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} Together, zero-initialization and constant initialization are called \defn{static initialization}; all other initialization is \defn{dynamic initialization}. Static initialization shall be performed before any dynamic initialization takes place. Dynamic initialization of a non-local variable with static storage duration is \defn{unordered} if the variable is an implicitly or explicitly instantiated specialization, and otherwise is \defn{ordered} \enternote an explicitly specialized static data member or variable template specialization has ordered initialization.\exitnote. Variables with ordered initialization defined within a single translation unit shall be initialized in the order of their definitions in the translation unit. If a program starts a thread~(\ref{thread.threads}), the subsequent initialization of a variable is unsequenced with respect to the initialization of a variable defined in a different translation unit. Otherwise, the initialization of a variable is indeterminately sequenced with respect to the initialization of a variable defined in a different translation unit. If a program starts a thread, the subsequent unordered initialization of a variable is unsequenced with respect to every other dynamic initialization. Otherwise, the unordered initialization of a variable is indeterminately sequenced with respect to every other dynamic initialization. \enternote This definition permits initialization of a sequence of ordered variables concurrently with another sequence. \exitnote \enternote The initialization of local static variables is described in~\ref{stmt.dcl}. \exitnote \pnum An implementation is permitted to perform the initialization of a non-local variable with static 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 namespace scope 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} % \item \enternote 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} \exitnote \pnum \indextext{evaluation!unspecified order~of}% It is \impldef{dynamic initialization of static objects before \tcode{main}} whether the dynamic initialization of a non-local variable with static storage duration is done before the first statement of \tcode{main}. If the initialization is deferred to some point in time after the first statement of \tcode{main}, it shall occur before the first odr-use~(\ref{basic.def.odr}) of any function or 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}).} \enterexample \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 implementation-defined 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}. \exitexample \pnum It is \impldef{dynamic initialization of thread-local objects before entry} whether the dynamic initialization of a non-local variable with static or thread storage duration is done before the first statement of the initial function of the thread. If the initialization is deferred to some point in time after the first statement of the initial function of the thread, it shall occur before the first odr-use~(\ref{basic.def.odr}) of any 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. \enternote This definition permits concurrent destruction. \exitnote 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{},~\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. \enternote 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. \exitnote \pnum \indextext{\idxcode{abort}}% \indexlibrary{\idxcode{abort}}% \indextext{termination!program}% Calling the function \tcode{std::abort()} declared in \indextext{\idxhdr{cstdlib}}% \tcode{} 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|(}% 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. The lifetime of a reference is its storage duration. \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.init}, \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. \enternote \ref{stmt.dcl} describes the initialization of local \tcode{static} variables; \ref{basic.start.term} describes the destruction of local \tcode{static} variables. \exitnote \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!\idxcode{register}}% \indextext{storage~duration!local object}% Block-scope variables explicitly declared \tcode{register} or 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 \enternote These variables are initialized and destroyed as described in~\ref{stmt.dcl}. \exitnote \pnum If a variable with automatic storage duration has initialization or a destructor with side effects, it shall not be destroyed before the end of its block, nor shall it be eliminated 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[]}. \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); void operator delete(void*) noexcept; void operator delete[](void*) noexcept; void operator delete(void*, std::size_t) noexcept; void operator delete[](void*, std::size_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[]}. \enternote The implicit declarations do not introduce the names \tcode{std}, \tcode{std\colcol{}size_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{} is well-formed. However, referring to \tcode{std} or \tcode{std::size_t} is ill-formed unless the name has been declared by including the appropriate header. \exitnote Allocation and/or deallocation functions can 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 of any complete object type with a fundamental alignment requirement~(\ref{basic.align}) 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 point to 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. \enternote \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}). \exitnote 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. \enternote 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}). \exitnote \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 can have more than one parameter. The global \tcode{operator delete} with exactly one parameter is a usual (non-placement) deallocation function. The global \tcode{operator delete} with exactly two parameters, the second of which has type \tcode{std::size_t}, is a usual deallocation function. Similarly, the global \tcode{operator delete[]} with exactly one parameter is a usual deallocation function. The global \tcode{operator delete[]} with exactly two parameters, the second of which has type \tcode{std::size_t}, is a usual deallocation function.\footnote{This deallocation function 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}).} If a class \tcode{T} has a member deallocation function named \tcode{operator} \tcode{delete} with exactly one parameter, then that function is a usual deallocation function. If class \tcode{T} does not declare such an \tcode{operator} \tcode{delete} but does declare a member deallocation function named \tcode{operator} \tcode{delete} with exactly two parameters, the second of which has type \tcode{std::size_t}, then this function is a usual deallocation function. Similarly, if a class \tcode{T} has a member deallocation function named \tcode{operator} \tcode{delete[]} with exactly one parameter, then that function is a usual (non-placement) deallocation function. If class \tcode{T} does not declare such an \tcode{operator} \tcode{delete[]} but does declare a member deallocation function named \tcode{operator} \tcode{delete[]} with exactly two parameters, the second of which has type \tcode{std::size_t}, then this function is a usual deallocation function. A deallocation function can be an instance of a function template. Neither the first parameter nor the return type shall depend on a template parameter. \enternote 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). \exitnote 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. Otherwise, the behavior is undefined if the value supplied to \tcode{operator} \tcode{delete(void*)} in the standard library is not one of the values returned by a previous invocation of either \tcode{operator} \tcode{new(std::size_t)} or \tcode{operator} \tcode{new(std::size_t,} \tcode{const} \tcode{std::nothrow_t\&)} in the standard library, and the behavior is undefined if the value supplied to \tcode{operator} \tcode{delete[](void*)} in the standard library is not one of the values returned by a previous invocation of either \tcode{operator} \tcode{new[](std::size_t)} or \tcode{operator} \tcode{new[](std::size_t,} \tcode{const} \tcode{std::nothrow_t\&)} in the standard library. \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, rendering invalid all pointers referring to any part of the deallocated storage. \indextext{object!undefined deleted}% Indirection through an invalid pointer value and passing an invalid pointer value to a deallocation function have undefined behavior. Any other use of an invalid pointer value has implementation-defined behavior.\footnote{Some implementations might define that copying an invalid pointer value causes a system-generated runtime fault.} \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)};\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} would compare equal to a safely-derived pointer computable from \tcode{reinterpret_cast(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}). \enternote 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. \exitnote It is implementation defined\indeximpldef{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 member subobjects, base class subobjects and array elements is that of their complete object~(\ref{intro.object}). \indextext{storage~duration|)}% \rSec1[basic.life]{Object lifetime} \pnum \indextext{object~lifetime|(}% \indextext{initialization!non-vacuous}% The \defn{lifetime} of an object is a runtime property of the object. An object is said to have \term{non-vacuous initialization} if it is of a class or aggregate type and it or one of its members is initialized by a constructor other than a trivial default constructor. \enternote initialization by a trivial copy/move constructor is non-vacuous initialization. \exitnote 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} The lifetime of an object 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 reused or released. \end{itemize} \pnum \enternote The lifetime of an array object starts as soon as storage with proper size and alignment is obtained, and its lifetime ends when the storage which the array occupies is reused or released. \ref{class.base.init} describes the lifetime of base and member subobjects. \exitnote \pnum The properties ascribed to objects throughout this International Standard apply for a given object only during its lifetime. \enternote 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. \exitnote \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 refers to 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 \term{cv} \tcode{void}, or to pointer to \term{cv} \tcode{void} and subsequently to pointer to either \term{cv} \tcode{char} or \term{cv} \tcode{unsigned char}, or \item the pointer is used as the operand of a \tcode{dynamic_cast}~(\ref{expr.dynamic.cast}). \enterexample \begin{codeblock} #include 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} \exitexample \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 an lvalue-to-rvalue conversion~(\ref{conv.lval}) is applied to such a glvalue, \item the glvalue is used to access a non-static data member or 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). \enterexample \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} \exitexample \end{itemize} \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. \enterexample \begin{codeblock} class T { }; struct B { ~B(); }; void h() { B b; new (&b) T; } // undefined behavior at block exit \end{codeblock} \exitexample \pnum Creating a new object at the storage location that a \tcode{const} object with static, thread, or automatic storage duration occupies or, at the storage location that such a \tcode{const} object used to occupy before its lifetime ended results in undefined behavior. \enterexample \begin{codeblock} struct B { B(); ~B(); }; const B b; void h() { b.~B(); new (const_cast(&b)) const B; // undefined behavior } \end{codeblock} \exitexample \pnum In this section, ``before'' and ``after'' refer to the ``happens before'' relation~(\ref{intro.multithread}). \enternote Therefore, undefined behavior results if an object that is being constructed in one thread is referenced from another thread without adequate synchronization. \exitnote% \indextext{object~lifetime|)} \rSec1[basic.types]{Types}% \indextext{type|(} \pnum \enternote \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}). \exitnote \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. \enterexample \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} \exitexample \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}. \enterexample \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} \exitexample% \indextext{object!byte~copying~and|)} \pnum The \defn{object representation} \indextext{representation!object}% of an object of type \tcode{T} is the sequence of \term{N} \tcode{unsigned} \tcode{char} objects taken up by the object of type \tcode{T}, where \term{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!incomplete}% \indextext{type!incompletely-defined object}% \indextext{object type!incompletely-defined}% 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 \defn{incompletely-defined object type}.\footnote{The size and layout of an instance of an incompletely-defined object type is unknown.} Incompletely-defined object types and the void types are \term{incomplete types}~(\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. \enterexample \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} \exitexample \pnum \enternote The rules for declarations and expressions describe in which contexts incomplete types are prohibited. \exitnote \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 a void type. \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 \indextext{scalar~type}% \term{scalar types}. Scalar types, POD classes (Clause~\ref{class}), arrays of such types and \grammarterm{cv-qualified} versions of these types~(\ref{basic.type.qualifier}) are collectively called \indextext{type!POD}% \term{POD types}. Cv-unqualified scalar types, trivially copyable class types (Clause~\ref{class}), arrays of such types, and non-volatile const-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 \tcode{void}; or \item a scalar type; or \item a reference type; or \item an array of literal type; or \item a class type (Clause~\ref{class}) that has all of the following properties: \begin{itemize} \item it has a trivial destructor, \item it is an aggregate type~(\ref{dcl.init.aggr}) or has at least one \tcode{constexpr} constructor or constructor template that is not a copy or move constructor, and \item 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}% \indextext{type!narrow 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 \term{narrow character types}. 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. 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}% \indextext{standard~signed~integer~type}% There are five \term{standard signed integer types} : \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{extended~signed~integer~type}% \indextext{type!signed~integer}% \indextext{signed~integer~type}% There may also be \impldef{extended signed integer types} \term{extended signed integer types}. The standard and extended signed integer types are collectively called \term{signed integer types}. \indextext{integral~type!implementation-defined @\tcode{sizeof}}% Plain \tcode{int}s have the natural size suggested by the architecture of the execution environment\footnote{that is, large enough to contain any value in the range of \tcode{INT_MIN} and \tcode{INT_MAX}, as defined in the header \tcode{}.}; 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}% \indextext{standard~unsigned~integer~type}% \term{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{extended~unsigned~integer~type}% \indextext{type!unsigned~integer}% \indextext{unsigned~integer~type}% Likewise, for each of the extended signed integer types there exists a corresponding \term{extended unsigned integer type} with the same amount of storage and alignment requirements. The standard and extended unsigned integer types are collectively called \term{unsigned integer types}. The range of non-negative values of a \term{signed integer} type is a subrange of the corresponding \term{unsigned integer} type, and the value representation of each corresponding signed/unsigned type shall be the same. \indextext{type!standard~integer}% \indextext{standard~integer~type}% \indextext{type!extended~integer}% \indextext{extended~integer~type}% The standard signed integer types and standard unsigned integer types are collectively called the \term{standard integer types}, and the extended signed integer types and extended unsigned integer types are collectively called the \term{extended integer types}. 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{type!\idxcode{char16_t}}% \indextext{type!\idxcode{char32_t}}% \indextext{\idxcode{wchar_t}!implementation-defined}% \indextext{type!\idxcode{wchar_t}}% \indextext{type!underlying wchar_t@underlying \tcode{wchar_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 \defn{underlying type}. 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{}, 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}.} \enternote There are no \tcode{signed}, \tcode{unsigned}, \tcode{short}, or \tcode{long bool} types or values. \exitnote 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 \indextext{integral~type}% \term{integral} 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{integer~type}% \term{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}.)} \enterexample this International Standard permits 2's complement, 1's complement and signed magnitude representations for integral types. \exitexample \pnum \indextext{floating~point~type}% There are three \term{floating point} 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}% \indextext{type!arithmetic}% \term{Integral} and \term{floating} types are collectively called \term{arithmetic} types. \indextext{\idxcode{numeric_limits}!specializations for arithmetic types}% Specializations of the standard 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}}% The \tcode{void} type has an empty set of values. The \tcode{void} type is an incomplete type that cannot be completed. It is used as the return type for functions that do not return a value. Any expression can be explicitly converted to type \term{cv} \tcode{void}~(\ref{expr.cast}). An expression of type \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 \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 \enternote Even if the implementation defines two or more basic types to have the same value representation, they are nevertheless different types. \exitnote \rSec2[basic.compound]{Compound types} \pnum \indextext{type!compound}% Compound types can be constructed in the following ways: \begin{itemize} \item \indextext{type!array}% \term{arrays} of objects of a given type,~\ref{dcl.array}; \item \indextext{type!function}% \term{functions}, which have parameters of given types and return \tcode{void} or references or objects of a given type,~\ref{dcl.fct}; \item \indextext{type!pointer}% \term{pointers} to \tcode{void} or objects or functions (including static members of classes) of a given type,~\ref{dcl.ptr}; \item % \indextext{reference}% \indextext{reference!lvalue}% \indextext{reference!rvalue}% \indextext{lvalue~reference}% \indextext{rvalue~reference}% \term{references} to objects or functions of a given type,~\ref{dcl.ref}. There are two types of references: \begin{itemize} \item \term{lvalue reference} \item \term{rvalue reference} \end{itemize} \item \indextext{class}% \term{classes} 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 \indextext{\idxcode{union}}% \term{unions}, which are classes capable of containing objects of different types at different times,~\ref{class.union}; \item \indextext{\idxcode{enum}}% \term{enumerations}, which comprise a set of named constant values. Each distinct enumeration constitutes a different \indextext{type!enumerated}% \term{enumerated type},~\ref{dcl.enum}; \item \indextext{member~pointer~to|see{pointer to member}}% \indextext{pointer~to~member}% \term{pointers to non-static} \footnote{Static class members are objects or functions, and pointers to them are ordinary pointers to objects or functions.} \term{class members}, 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 \tcode{void} or a pointer to an object type is called an \defn{object pointer type}. \enternote A pointer to \tcode{void} does not have a pointer-to-object type, however, because \tcode{void} is not an object type. \exitnote 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}.'' \enterexample 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}.'' \exitexample 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}% A valid value of an object pointer type represents either the address of a byte in memory~(\ref{intro.memory}) or a null pointer~(\ref{conv.ptr}). If an object of type \tcode{T} is located at an address \tcode{A}, a pointer of type \term{cv} \tcode{T*} whose value is the address \tcode{A} is said to \term{point to} that object, regardless of how the value was obtained. \enternote For instance, the address one past the end of an array~(\ref{expr.add}) would be considered to point to an unrelated object of the array's element type that might be located at that address. There are further restrictions on pointers to objects with dynamic storage duration; see~\ref{basic.stc.dynamic.safety}. \exitnote 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}). \enternote 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. This International Standard specifies only two ways of obtaining such a pointer: taking the address of a valid object with an over-aligned type, and using one of the runtime pointer alignment functions. An implementation may provide other means of obtaining a valid pointer value for an over-aligned type.\exitnote \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 \term{cv-unqualified type}. 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 \grammarterm{const-qualified} version, a \term{volatile-qualified} version, and a \term{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 \term{const object} is an object of type \tcode{const T} or a non-mutable subobject of such an object. \item A \term{volatile object} 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 \term{const volatile object} 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 \term{cv} (or \term{cv1}, \term{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. \indextext{cv-qualifier!top-level} For a type \cv\ \tcode{T}, the \term{top-level cv-qualifiers} of that type are those denoted by \cv. \enterexample 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}. \exitexample \pnum Cv-qualifiers applied to an array type attach to the underlying element type, so the notation ``\term{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|)} \enterexample \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 \tcode{const}-qualified. \exitexample \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 An \defn{lvalue} (so called, historically, because lvalues could appear on the left-hand side of an assignment expression) designates a function or an object. \enterexample If \tcode{E} is an expression of pointer type, then \tcode{*E} is an lvalue expression referring to the object or function to which \tcode{E} points. As another example, the result of calling a function whose return type is an lvalue reference is an lvalue. \exitexample \item An \defn{xvalue} (an ``eXpiring'' value) also refers to an object, usually near the end of its lifetime (so that its resources may be moved, for example). Certain kinds of expressions involving rvalue references~(\ref{dcl.ref}) yield xvalues. \enterexample The result of calling a function whose return type is an rvalue reference to an object type is an xvalue~(\ref{expr.call}). \exitexample \item A \defn{glvalue} (``generalized'' lvalue) is an lvalue or an xvalue. \item An \defn{rvalue} (so called, historically, because rvalues could appear on the right-hand side of an assignment expression) is an xvalue, a temporary object~(\ref{class.temporary}) or subobject thereof, or a value that is not associated with an object. \item A \defn{prvalue} (``pure'' rvalue) is an rvalue that is not an xvalue. \enterexample The result of calling a function whose return type is not a reference is a prvalue. The value of a literal such as \tcode{12}, \tcode{7.3e5}, or \tcode{true} is also a prvalue. \exitexample \end{itemize} 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}. \enternote 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. \exitnote \pnum 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}. \enternote An attempt to bind an rvalue reference to an lvalue is not such a context; see~\ref{dcl.init.ref}. \exitnote \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}), prvalues shall always have complete types or the \tcode{void} type; in addition to these types, glvalues can also have incomplete types. \enternote class and array prvalues can have cv-qualified types; other prvalues always have cv-unqualified types. See Clause~\ref{expr}. \exitnote \pnum An lvalue for an object is necessary in order to modify the object except that an rvalue of class type can also be used to modify its referent under certain circumstances. \enterexample a member function called for an object~(\ref{class.mfct}) can modify the object. \exitexample \pnum Functions cannot be modified, but pointers to functions can be modifiable. \pnum A pointer to an incomplete type can be modifiable. At some point in the program when the pointed to type is complete, the object at which the pointer points can also be modified. \pnum The referent of a \tcode{const}-qualified expression shall not be modified (through that expression), except that if it is of class type and has a \tcode{mutable} component, that component can be modified~(\ref{dcl.type.cv}). \pnum If an expression can be used to modify the object to which it refers, the expression is called \term{modifiable}. A program that attempts to modify an object through a nonmodifiable lvalue or rvalue expression is ill-formed. \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 \indextext{alignment~requirement!implementation-defined}% Object types have \term{alignment requirements} (\ref{basic.fundamental},~\ref{basic.compound}) which place restrictions on the addresses at which an object of that type may be allocated. An \term{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{fundamental~alignment}% \indextext{alignment!fundamental}% A \term{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. \enterexample \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. \exitexample The result of the \tcode{alignof} operator reflects the alignment requirement of the type in the complete-object case. \pnum \indextext{extended~alignment}% \indextext{alignment!extended}% \indextext{over-aligned~type}% \indextext{type!over-aligned}% An \term{extended alignment} is represented by an alignment greater than \tcode{alignof(std::max_align_t)}. It is implementation-defined 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}. \enternote every over-aligned type is or contains a class type to which extended alignment applies (possibly through a non-static data member). \exitnote \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 \term{weaker} to \term{stronger} or \term{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. \enternote This enables the narrow character types to be used as the underlying type for an aligned memory area~(\ref{dcl.align}).\exitnote \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 \enternote 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. \exitnote \pnum If a request for a specific extended alignment in a specific context is not supported by an implementation, the program is ill-formed. Additionally, a request for runtime allocation of dynamic storage for which the requested alignment cannot be honored shall be treated as an allocation failure.