1 Scope [intro.scope]

This document specifies requirements for implementations of the C++ programming language.
The first such requirement is that they implement the language, so this document also defines C++.
Other requirements and relaxations of the first requirement appear at various places within this document.
C++ is a general purpose programming language based on the C programming language as described in ISO/IEC 9899:2018 Programming languages — C (hereinafter referred to as the C standard).
C++ provides many facilities beyond those provided by C, including additional data types, classes, templates, exceptions, namespaces, operator overloading, function name overloading, references, free store management operators, and additional library facilities.

2 Normative references [intro.refs]

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document.
For dated references, only the edition cited applies.
For undated references, the latest edition of the referenced document (including any amendments) applies.
  • Ecma International, ECMAScript Language Specification, Standard Ecma-262, third edition, 1999.
  • ISO/IEC 2382 (all parts), Information technology — Vocabulary
  • ISO 8601:2004, Data elements and interchange formats — Information interchange — Representation of dates and times
  • ISO/IEC 9899:2018, Programming languages — C
  • ISO/IEC 9945:2003, Information Technology — Portable Operating System Interface (POSIX)
  • ISO/IEC 10646, Information technology — Universal Coded Character Set (UCS)
  • ISO/IEC 10646-1:1993, Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 1: Architecture and Basic Multilingual Plane
  • ISO/IEC/IEEE 60559:2011, Information technology — Microprocessor Systems — Floating-Point arithmetic
  • ISO 80000-2:2009, Quantities and units — Part 2: Mathematical signs and symbols to be used in the natural sciences and technology
  • The Unicode Consortium.
    Unicode Standard Annex, UAX #29, Unicode Text Segmentation [online].
    Edited by Mark Davis.
    Revision 35; issued for Unicode 12.0.0.
    2019-02-15 [viewed 2020-02-23].
The library described in Clause 7 of ISO/IEC 9899:2018 is hereinafter called the C standard library.1
The operating system interface described in ISO/IEC 9945:2003 is hereinafter called POSIX.
The ECMAScript Language Specification described in Standard Ecma-262 is hereinafter called ECMA-262.
Note
:
References to ISO/IEC 10646-1:1993 are used only to support deprecated features ([depr.locale.stdcvt]).
— end note
 ]
With the qualifications noted in [support] through [thread] and in [diff.library], the C standard library is a subset of the C++ standard library.

3 Terms and definitions [intro.defs]

For the purposes of this document, the terms and definitions given in ISO/IEC 2382-1:1993, the terms, definitions, and symbols given in ISO 80000-2:2009, and the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
[definitions] defines additional terms that are used only in [library] through [thread] and [depr].
Terms that are used only in a small portion of this document are defined where they are used and italicized where they are defined.

3.1[defns.access]access

⟨execution-time action⟩ read ([conv.lval]) or modify ([expr.ass], [expr.post.incr], [expr.pre.incr]) the value of an object
Note
:
Only objects of scalar type can be accessed.
Attempts to read or modify an object of class type typically invoke a constructor ([class.ctor]) or assignment operator ([class.copy.assign]); such invocations do not themselves constitute accesses, although they may involve accesses of scalar subobjects.
— end note
 ]

3.2[defns.argument]argument

⟨function call expression⟩ expression in the comma-separated list bounded by the parentheses ([expr.call])

3.3[defns.argument.macro]argument

⟨function-like macro⟩ sequence of preprocessing tokens in the comma-separated list bounded by the parentheses ([cpp.replace])

3.4[defns.argument.throw]argument

⟨throw expression⟩ operand of throw

3.5[defns.argument.templ]argument

⟨template instantiation⟩ constant-expression, type-id, or id-expression in the comma-separated list bounded by the angle brackets ([temp.arg])

3.6[defns.block]block

⟨execution⟩ wait for some condition (other than for the implementation to execute the execution steps of the thread of execution) to be satisfied before continuing execution past the blocking operation

3.7[defns.block.stmt]block

⟨statement⟩ compound statement ([stmt.block])

3.8[defns.cond.supp]conditionally-supported

program construct that an implementation is not required to support
Note
:
Each implementation documents all conditionally-supported constructs that it does not support.
— end note
 ]

3.9[defns.diagnostic]diagnostic message

message belonging to an implementation-defined subset of the implementation's output messages

3.10[defns.dynamic.type]dynamic type

⟨glvalue⟩ type of the most derived object ([intro.object]) to which the glvalue refers
Example
:
If a pointer p whose static type is “pointer to class B” is pointing to an object of class D, derived from B, the dynamic type of the expression *p is “D.
References are treated similarly.
— end example
 ]

3.11[defns.dynamic.type.prvalue]dynamic type

⟨prvalue⟩ static type of the prvalue expression

3.12[defns.ill.formed]ill-formed program

program that is not well-formed

3.13[defns.impl.defined]implementation-defined behavior

behavior, for a well-formed program construct and correct data, that depends on the implementation and that each implementation documents

3.14[defns.impl.limits]implementation limits

restrictions imposed upon programs by the implementation

3.15[defns.locale.specific]locale-specific behavior

behavior that depends on local conventions of nationality, culture, and language that each implementation documents

3.16[defns.multibyte]multibyte character

sequence of one or more bytes representing a member of the extended character set of either the source or the execution environment
Note
:
The extended character set is a superset of the basic character set ([lex.charset]).
— end note
 ]

3.17[defns.parameter]parameter

⟨function or catch clause⟩ object or reference declared as part of a function declaration or definition or in the catch clause of an exception handler that acquires a value on entry to the function or handler

3.18[defns.parameter.macro]parameter

⟨function-like macro⟩ identifier from the comma-separated list bounded by the parentheses immediately following the macro name

3.19[defns.parameter.templ]parameter

⟨template⟩ member of a template-parameter-list

3.20[defns.signature]signature

⟨function⟩ name, parameter-type-list ([dcl.fct]), and enclosing namespace (if any)
Note
:
Signatures are used as a basis for name mangling and linking.
— end note
 ]

3.21[defns.signature.friend]signature

⟨non-template friend function with trailing requires-clause⟩ name, parameter-type-list ([dcl.fct]), enclosing class, and trailing requires-clause ([dcl.decl])

3.22[defns.signature.templ]signature

⟨function template⟩ name, parameter-type-list ([dcl.fct]), enclosing namespace (if any), return type, template-head, and trailing requires-clause ([dcl.decl]) (if any)

3.23[defns.signature.templ.friend]signature

⟨friend function template with constraint involving enclosing template parameters⟩ name, parameter-type-list ([dcl.fct]), return type, enclosing class, template-head, and trailing requires-clause ([dcl.decl]) (if any)

3.24[defns.signature.spec]signature

⟨function template specialization⟩ signature of the template of which it is a specialization and its template arguments (whether explicitly specified or deduced)

3.25[defns.signature.member]signature

⟨class member function⟩ name, parameter-type-list ([dcl.fct]), class of which the function is a member, cv-qualifiers (if any), ref-qualifier (if any), and trailing requires-clause ([dcl.decl]) (if any)

3.26[defns.signature.member.templ]signature

⟨class member function template⟩ name, parameter-type-list ([dcl.fct]), class of which the function is a member, cv-qualifiers (if any), ref-qualifier (if any), return type (if any), template-head, and trailing requires-clause ([dcl.decl]) (if any)

3.27[defns.signature.member.spec]signature

⟨class member function template specialization⟩ signature of the member function template of which it is a specialization and its template arguments (whether explicitly specified or deduced)

3.28[defns.static.type]static type

type of an expression ([basic.types]) resulting from analysis of the program without considering execution semantics
Note
:
The static type of an expression depends only on the form of the program in which the expression appears, and does not change while the program is executing.
— end note
 ]

3.29[defns.unblock]unblock

satisfy a condition that one or more blocked threads of execution are waiting for

3.30[defns.undefined]undefined behavior

behavior for which this document imposes no requirements
Note
:
Undefined behavior may be expected when this document omits any explicit definition of behavior or when a program uses an erroneous construct or erroneous data.
Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).
Many erroneous program constructs do not engender undefined behavior; they are required to be diagnosed.
Evaluation of a constant expression never exhibits behavior explicitly specified as undefined in [intro] through [cpp] of this document ([expr.const]).
— end note
 ]

3.31[defns.unspecified]unspecified behavior

behavior, for a well-formed program construct and correct data, that depends on the implementation
Note
:
The implementation is not required to document which behavior occurs.
The range of possible behaviors is usually delineated by this document.
— end note
 ]

3.32[defns.well.formed]well-formed program

C++ program constructed according to the syntax rules, diagnosable semantic rules, and the one-definition rule

4 General principles [intro]

4.1 Implementation compliance [intro.compliance]

The set of diagnosable rules consists of all syntactic and semantic rules in this document except for those rules containing an explicit notation that “no diagnostic is required” or which are described as resulting in “undefined behavior”.
Although this document states only requirements on C++ implementations, those requirements are often easier to understand if they are phrased as requirements on programs, parts of programs, or execution of programs.
Such requirements have the following meaning:
  • If a program contains no violations of the rules in this document, a conforming implementation shall, within its resource limits, accept and correctly execute2 that program.
  • If a program contains a violation of any diagnosable rule or an occurrence of a construct described in this document as “conditionally-supported” when the implementation does not support that construct, a conforming implementation shall issue at least one diagnostic message.
  • If a program contains a violation of a rule for which no diagnostic is required, this document places no requirement on implementations with respect to that program.
Note
:
During template argument deduction and substitution, certain constructs that in other contexts require a diagnostic are treated differently; see [temp.deduct].
— end note
 ]
For classes and class templates, the library Clauses specify partial definitions.
Private members are not specified, but each implementation shall supply them to complete the definitions according to the description in the library Clauses.
For functions, function templates, objects, and values, the library Clauses specify declarations.
Implementations shall supply definitions consistent with the descriptions in the library Clauses.
The names defined in the library have namespace scope ([basic.namespace]).
A C++ translation unit ([lex.phases]) obtains access to these names by including the appropriate standard library header or importing the appropriate standard library named header unit ([using.headers]).
The templates, classes, functions, and objects in the library have external linkage.
The implementation provides definitions for standard library entities, as necessary, while combining translation units to form a complete C++ program ([lex.phases]).
Two kinds of implementations are defined: a hosted implementation and a freestanding implementation.
For a hosted implementation, this document defines the set of available libraries.
A freestanding implementation is one in which execution may take place without the benefit of an operating system, and has an implementation-defined set of libraries that includes certain language-support libraries ([compliance]).
A conforming implementation may have extensions (including additional library functions), provided they do not alter the behavior of any well-formed program.
Implementations are required to diagnose programs that use such extensions that are ill-formed according to this document.
Having done so, however, they can compile and execute such programs.
Each implementation shall include documentation that identifies all conditionally-supported constructs that it does not support and defines all locale-specific characteristics.3
“Correct execution” can include undefined behavior, depending on the data being processed; see [intro.defs] and [intro.execution].
This documentation also defines implementation-defined behavior; see [intro.abstract].

4.1.1 Abstract machine [intro.abstract]

The semantic descriptions in this document define a parameterized nondeterministic abstract machine.
This document places no requirement on the structure of conforming implementations.
In particular, they need not copy or emulate the structure of the abstract machine.
Rather, conforming implementations are required to emulate (only) the observable behavior of the abstract machine as explained below.4
Certain aspects and operations of the abstract machine are described in this document as implementation-defined (for example, sizeof(int)).
These constitute the parameters of the abstract machine.
Each implementation shall include documentation describing its characteristics and behavior in these respects.5
Such documentation shall define the instance of the abstract machine that corresponds to that implementation (referred to as the “corresponding instance” below).
Certain other aspects and operations of the abstract machine are described in this document as unspecified (for example, order of evaluation of arguments in a function call ([expr.call])).
Where possible, this document defines a set of allowable behaviors.
These define the nondeterministic aspects of the abstract machine.
An instance of the abstract machine can thus have more than one possible execution for a given program and a given input.
Certain other operations are described in this document as undefined (for example, the effect of attempting to modify a const object).
Note
:
This document imposes no requirements on the behavior of programs that contain undefined behavior.
— end note
 ]
A conforming implementation executing a well-formed program shall produce the same observable behavior as one of the possible executions of the corresponding instance of the abstract machine with the same program and the same input.
However, if any such execution contains an undefined operation, this document places no requirement on the implementation executing that program with that input (not even with regard to operations preceding the first undefined operation).
The least requirements on a conforming implementation are:
  • Accesses through volatile glvalues are evaluated strictly according to the rules of the abstract machine.
  • At program termination, all data written into files shall be identical to one of the possible results that execution of the program according to the abstract semantics would have produced.
  • The input and output dynamics of interactive devices shall take place in such a fashion that prompting output is actually delivered before a program waits for input. What constitutes an interactive device is implementation-defined.
These collectively are referred to as the observable behavior of the program.
Note
:
More stringent correspondences between abstract and actual semantics may be defined by each implementation.
— end note
 ]
This provision is sometimes called the “as-if” rule, because an implementation is free to disregard any requirement of this document as long as the result is as if the requirement had been obeyed, as far as can be determined from the observable behavior of the program.
For instance, an actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no side effects affecting the observable behavior of the program are produced.
This documentation also includes conditionally-supported constructs and locale-specific behavior.

4.2 Structure of this document [intro.structure]

[lex] through [cpp] describe the C++ programming language.
That description includes detailed syntactic specifications in a form described in [syntax].
For convenience, [gram] repeats all such syntactic specifications.
[support] through [thread] and [depr] (the library clauses) describe the C++ standard library.
That description includes detailed descriptions of the entities and macros that constitute the library, in a form described in [library].
[implimits] recommends lower bounds on the capacity of conforming implementations.
[diff] summarizes the evolution of C++ since its first published description, and explains in detail the differences between C++ and C.
Certain features of C++ exist solely for compatibility purposes; [depr] describes those features.
Throughout this document, each example is introduced by “[Example: ” and terminated by “end example]”.
Each note is introduced by “[Note: ” or “[Note n to entry: ” and terminated by “end note]”.
Examples and notes may be nested.

4.3 Syntax notation [syntax]

In the syntax notation used in this document, syntactic categories are indicated by italic type, and literal words and characters in constant width type.
Alternatives are listed on separate lines except in a few cases where a long set of alternatives is marked by the phrase “one of”.
If the text of an alternative is too long to fit on a line, the text is continued on subsequent lines indented from the first one.
An optional terminal or non-terminal symbol is indicated by the subscript “”, so
{ expression }
indicates an optional expression enclosed in braces.
Names for syntactic categories have generally been chosen according to the following rules:
  • X-name is a use of an identifier in a context that determines its meaning (e.g., class-name, typedef-name).
  • X-id is an identifier with no context-dependent meaning (e.g., qualified-id).
  • X-seq is one or more X's without intervening delimiters (e.g., declaration-seq is a sequence of declarations).
  • X-list is one or more X's separated by intervening commas (e.g., identifier-list is a sequence of identifiers separated by commas).

4.4 Acknowledgments [intro.ack]

The C++ programming language as described in this document is based on the language as described in Chapter R (Reference Manual) of Stroustrup: The C++ Programming Language (second edition, Addison-Wesley Publishing Company, ISBN 0-201-53992-6, copyright ©1991 AT&T).
That, in turn, is based on the C programming language as described in Appendix A of Kernighan and Ritchie: The C Programming Language (Prentice-Hall, 1978, ISBN 0-13-110163-3, copyright ©1978 AT&T).
Portions of the library Clauses of this document are based on work by P.J. Plauger, which was published as The Draft Standard C++ Library (Prentice-Hall, ISBN 0-13-117003-1, copyright ©1995 P.J. Plauger).
POSIX® is a registered trademark of the Institute of Electrical and Electronic Engineers, Inc.
ECMAScript® is a registered trademark of Ecma International.
Unicode® is a registered trademark of Unicode, Inc.
All rights in these originals are reserved.

5 Lexical conventions [lex]

5.1 Separate translation [lex.separate]

The text of the program is kept in units called source files in this document.
A source file together with all the headers and source files included via the preprocessing directive #include, less any source lines skipped by any of the conditional inclusion preprocessing directives, is called a translation unit.
Note
:
A C++ program need not all be translated at the same time.
— end note
 ]
Note
:
Previously translated translation units and instantiation units can be preserved individually or in libraries.
The separate translation units of a program communicate ([basic.link]) by (for example) calls to functions whose identifiers have external or module linkage, manipulation of objects whose identifiers have external or module linkage, or manipulation of data files.
Translation units can be separately translated and then later linked to produce an executable program.
— end note
 ]

5.2 Phases of translation [lex.phases]

The precedence among the syntax rules of translation is specified by the following phases.6
  1. 1.
    Physical source file characters are mapped, in an implementation-defined manner, to the basic source character set (introducing new-line characters for end-of-line indicators) if necessary.
    The set of physical source file characters accepted is implementation-defined.
    Any source file character not in the basic source character set is replaced by the universal-character-name that designates that character.
    An implementation may use any internal encoding, so long as an actual extended character encountered in the source file, and the same extended character expressed in the source file as a universal-character-name (e.g., using the \ uXXXX notation), are handled equivalently except where this replacement is reverted ([lex.pptoken]) in a raw string literal.
  2. 2.
    Each instance of a backslash character (\) immediately followed by a new-line character is deleted, splicing physical source lines to form logical source lines.
    Only the last backslash on any physical source line shall be eligible for being part of such a splice.
    Except for splices reverted in a raw string literal, if a splice results in a character sequence that matches the syntax of a universal-character-name, the behavior is undefined.
    A source file that is not empty and that does not end in a new-line character, or that ends in a new-line character immediately preceded by a backslash character before any such splicing takes place, shall be processed as if an additional new-line character were appended to the file.
  3. 3.
    The source file is decomposed into preprocessing tokens and sequences of white-space characters (including comments).
    A source file shall not end in a partial preprocessing token or in a partial comment.7
    Each comment is replaced by one space character.
    New-line characters are retained.
    Whether each nonempty sequence of white-space characters other than new-line is retained or replaced by one space character is unspecified.
    The process of dividing a source file's characters into preprocessing tokens is context-dependent.
    Example
    :
    See the handling of < within a #include preprocessing directive.
    — end example
     ]
  4. 4.
    Preprocessing directives are executed, macro invocations are expanded, and _­Pragma unary operator expressions are executed.
    If a character sequence that matches the syntax of a universal-character-name is produced by token concatenation, the behavior is undefined.
    A #include preprocessing directive causes the named header or source file to be processed from phase 1 through phase 4, recursively.
    All preprocessing directives are then deleted.
  5. 5.
    Each basic source character set member in a character-literal or a string-literal, as well as each escape sequence and universal-character-name in a character-literal or a non-raw string literal, is converted to the corresponding member of the execution character set ([lex.ccon], [lex.string]); if there is no corresponding member, it is converted to an implementation-defined member other than the null (wide) character.8
  6. 6.
    Adjacent string literal tokens are concatenated.
  7. 7.
    White-space characters separating tokens are no longer significant.
    Each preprocessing token is converted into a token ([lex.token]).
    The resulting tokens are syntactically and semantically analyzed and translated as a translation unit.
    Note
    :
    The process of analyzing and translating the tokens may occasionally result in one token being replaced by a sequence of other tokens ([temp.names]).
    — end note
     ]
    It is implementation-defined whether the sources for module units and header units on which the current translation unit has an interface dependency ([module.unit], [module.import]) are required to be available.
    Note
    :
    Source files, translation units and translated translation units need not necessarily be stored as files, nor need there be any one-to-one correspondence between these entities and any external representation.
    The description is conceptual only, and does not specify any particular implementation.
    — end note
     ]
  8. 8.
    Translated translation units and instantiation units are combined as follows:
    Note
    : Some or all of these may be supplied from a library. — end note
     ]
    Each translated translation unit is examined to produce a list of required instantiations.
    Note
    :
    This may include instantiations which have been explicitly requested ([temp.explicit]).
    — end note
     ]
    The definitions of the required templates are located.
    It is implementation-defined whether the source of the translation units containing these definitions is required to be available.
    Note
    :
    An implementation could encode sufficient information into the translated translation unit so as to ensure the source is not required here.
    — end note
     ]
    All the required instantiations are performed to produce instantiation units.
    Note
    :
    These are similar to translated translation units, but contain no references to uninstantiated templates and no template definitions.
    — end note
     ]
    The program is ill-formed if any instantiation fails.
  9. 9.
    All external entity references are resolved.
    Library components are linked to satisfy external references to entities not defined in the current translation.
    All such translator output is collected into a program image which contains information needed for execution in its execution environment.
Implementations must behave as if these separate phases occur, although in practice different phases might be folded together.
A partial preprocessing token would arise from a source file ending in the first portion of a multi-character token that requires a terminating sequence of characters, such as a header-name that is missing the closing " or >.
A partial comment would arise from a source file ending with an unclosed /* comment.
An implementation need not convert all non-corresponding source characters to the same execution character.

5.3 Character sets [lex.charset]

The basic source character set consists of 96 characters: the space character, the control characters representing horizontal tab, vertical tab, form feed, and new-line, plus the following 91 graphical characters:9
a b c d e f g h i j k l m n o p q r s t u v w x y z
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
0 1 2 3 4 5 6 7 8 9
_ { } [ ] # ( ) < > % : ; . ? * + - / ^ & | ~ ! = , \ " '
The universal-character-name construct provides a way to name other characters.
hex-quad:
	hexadecimal-digit hexadecimal-digit hexadecimal-digit hexadecimal-digit
universal-character-name:
	\u hex-quad
	\U hex-quad hex-quad
A universal-character-name designates the character in ISO/IEC 10646 (if any) whose code point is the hexadecimal number represented by the sequence of hexadecimal-digits in the universal-character-name.
The program is ill-formed if that number is not a code point or if it is a surrogate code point.
Noncharacter code points and reserved code points are considered to designate separate characters distinct from any ISO/IEC 10646 character.
If a universal-character-name outside the c-char-sequence, s-char-sequence, or r-char-sequence of a character-literal or string-literal (in either case, including within a user-defined-literal) corresponds to a control character or to a character in the basic source character set, the program is ill-formed.10
Note
:
ISO/IEC 10646 code points are integers in the range (hexadecimal).
A surrogate code point is a value in the range (hexadecimal).
A control character is a character whose code point is in either of the ranges or (hexadecimal).
— end note
 ]
The basic execution character set and the basic execution wide-character set shall each contain all the members of the basic source character set, plus control characters representing alert, backspace, and carriage return, plus a null character (respectively, null wide character), whose value is 0.
For each basic execution character set, the values of the members shall be non-negative and distinct from one another.
In both the source and execution basic character sets, the value of each character after 0 in the above list of decimal digits shall be one greater than the value of the previous.
The execution character set and the execution wide-character set are implementation-defined supersets of the basic execution character set and the basic execution wide-character set, respectively.
The values of the members of the execution character sets and the sets of additional members are locale-specific.
The glyphs for the members of the basic source character set are intended to identify characters from the subset of ISO/IEC 10646 which corresponds to the ASCII character set.
However, because the mapping from source file characters to the source character set (described in translation phase 1) is specified as implementation-defined, an implementation is required to document how the basic source characters are represented in source files.
A sequence of characters resembling a universal-character-name in an r-char-sequence does not form a universal-character-name.

5.4 Preprocessing tokens [lex.pptoken]

preprocessing-token:
	header-name
	import-keyword
	module-keyword
	export-keyword
	identifier
	pp-number
	character-literal
	user-defined-character-literal
	string-literal
	user-defined-string-literal
	preprocessing-op-or-punc
	each non-white-space character that cannot be one of the above
Each preprocessing token that is converted to a token shall have the lexical form of a keyword, an identifier, a literal, or an operator or punctuator.
A preprocessing token is the minimal lexical element of the language in translation phases 3 through 6.
The categories of preprocessing token are: header names, placeholder tokens produced by preprocessing import and module directives (import-keyword, module-keyword, and export-keyword), identifiers, preprocessing numbers, character literals (including user-defined character literals), string literals (including user-defined string literals), preprocessing operators and punctuators, and single non-white-space characters that do not lexically match the other preprocessing token categories.
If a ' or a " character matches the last category, the behavior is undefined.
Preprocessing tokens can be separated by white space; this consists of comments, or white-space characters (space, horizontal tab, new-line, vertical tab, and form-feed), or both.
As described in [cpp], in certain circumstances during translation phase 4, white space (or the absence thereof) serves as more than preprocessing token separation.
White space can appear within a preprocessing token only as part of a header name or between the quotation characters in a character literal or string literal.
If the input stream has been parsed into preprocessing tokens up to a given character:
  • If the next character begins a sequence of characters that could be the prefix and initial double quote of a raw string literal, such as R", the next preprocessing token shall be a raw string literal. Between the initial and final double quote characters of the raw string, any transformations performed in phases 1 and 2 (universal-character-names and line splicing) are reverted; this reversion shall apply before any d-char, r-char, or delimiting parenthesis is identified. The raw string literal is defined as the shortest sequence of characters that matches the raw-string pattern
    encoding-prefix R raw-string
    
  • Otherwise, if the next three characters are <​::​ and the subsequent character is neither : nor >, the < is treated as a preprocessing token by itself and not as the first character of the alternative token <:.
  • Otherwise, the next preprocessing token is the longest sequence of characters that could constitute a preprocessing token, even if that would cause further lexical analysis to fail, except that a header-name is only formed
Example
:
#define R "x"
const char* s = R"y";           // ill-formed raw string, not "x" "y"
— end example
 ]
The import-keyword is produced by processing an import directive ([cpp.import]), the module-keyword is produced by preprocessing a module directive ([cpp.module]), and the export-keyword is produced by preprocessing either of the previous two directives.
Note
:
None has any observable spelling.
— end note
 ]
Example
:
The program fragment 0xe+foo is parsed as a preprocessing number token (one that is not a valid integer-literal or floating-point-literal token), even though a parse as three preprocessing tokens 0xe, +, and foo might produce a valid expression (for example, if foo were a macro defined as 1).
Similarly, the program fragment 1E1 is parsed as a preprocessing number (one that is a valid floating-point-literal token), whether or not E is a macro name.
— end example
 ]
Example
:
The program fragment x+++++y is parsed as x ++ ++ + y, which, if x and y have integral types, violates a constraint on increment operators, even though the parse x ++ + ++ y might yield a correct expression.
— end example
 ]

5.5 Alternative tokens [lex.digraph]

Alternative token representations are provided for some operators and punctuators.11
In all respects of the language, each alternative token behaves the same, respectively, as its primary token, except for its spelling.12
The set of alternative tokens is defined in Table 1.
Table 1: Alternative tokens   [tab:lex.digraph]
Alternative
Primary
Alternative
Primary
Alternative
Primary
<%
{
and
&&
and_­eq
&=
%>
}
bitor
|
or_­eq
|=
<:
[
or
||
xor_­eq
^=
:>
]
xor
^
not
!
%:
#
compl
~
not_­eq
!=
%:%:
##
bitand
&
These include “digraphs” and additional reserved words.
The term “digraph” (token consisting of two characters) is not perfectly descriptive, since one of the alternative preprocessing-tokens is %:%: and of course several primary tokens contain two characters.
Nonetheless, those alternative tokens that aren't lexical keywords are colloquially known as “digraphs”.
Thus the “stringized” values of [ and <: will be different, maintaining the source spelling, but the tokens can otherwise be freely interchanged.

5.6 Tokens [lex.token]

token:
	identifier
	keyword
	literal
	operator-or-punctuator
There are five kinds of tokens: identifiers, keywords, literals,13 operators, and other separators.
Blanks, horizontal and vertical tabs, newlines, formfeeds, and comments (collectively, “white space”), as described below, are ignored except as they serve to separate tokens.
Note
:
Some white space is required to separate otherwise adjacent identifiers, keywords, numeric literals, and alternative tokens containing alphabetic characters.
— end note
 ]
Literals include strings and character and numeric literals.

5.7 Comments [lex.comment]

The characters /* start a comment, which terminates with the characters */.
These comments do not nest.
The characters // start a comment, which terminates immediately before the next new-line character.
If there is a form-feed or a vertical-tab character in such a comment, only white-space characters shall appear between it and the new-line that terminates the comment; no diagnostic is required.
Note
:
The comment characters //, /*, and */ have no special meaning within a // comment and are treated just like other characters.
Similarly, the comment characters // and /* have no special meaning within a /* comment.
— end note
 ]

5.8 Header names [lex.header]

header-name:
	< h-char-sequence >
	" q-char-sequence "
h-char-sequence:
	h-char
	h-char-sequence h-char
h-char:
	any member of the source character set except new-line and >
q-char-sequence:
	q-char
	q-char-sequence q-char
q-char:
	any member of the source character set except new-line and "
Note
:
Header name preprocessing tokens only appear within a #include preprocessing directive, a _­_­has_­include preprocessing expression, or after certain occurrences of an import token (see [lex.pptoken]).
— end note
 ]
The sequences in both forms of header-names are mapped in an implementation-defined manner to headers or to external source file names as specified in [cpp.include].
The appearance of either of the characters ' or \ or of either of the character sequences /* or // in a q-char-sequence or an h-char-sequence is conditionally-supported with implementation-defined semantics, as is the appearance of the character " in an h-char-sequence.14
Thus, a sequence of characters that resembles an escape sequence might result in an error, be interpreted as the character corresponding to the escape sequence, or have a completely different meaning, depending on the implementation.

5.9 Preprocessing numbers [lex.ppnumber]

pp-number:
	digit
	. digit
	pp-number digit
	pp-number identifier-nondigit
	pp-number ' digit
	pp-number ' nondigit
	pp-number e sign
	pp-number E sign
	pp-number p sign
	pp-number P sign
	pp-number .
Preprocessing number tokens lexically include all integer-literal tokens ([lex.icon]) and all floating-point-literal tokens ([lex.fcon]).
A preprocessing number does not have a type or a value; it acquires both after a successful conversion to an integer-literal token or a floating-point-literal token.

5.10 Identifiers [lex.name]

identifier:
	identifier-nondigit
	identifier identifier-nondigit
	identifier digit
identifier-nondigit:
	nondigit
	universal-character-name
nondigit: one of
	a b c d e f g h i j k l m
	n o p q r s t u v w x y z
	A B C D E F G H I J K L M
	N O P Q R S T U V W X Y Z _
digit: one of
	0 1 2 3 4 5 6 7 8 9
An identifier is an arbitrarily long sequence of letters and digits.
Each universal-character-name in an identifier shall designate a character whose encoding in ISO/IEC 10646 falls into one of the ranges specified in Table 2.
The initial element shall not be a universal-character-name designating a character whose encoding falls into one of the ranges specified in Table 3.
Upper- and lower-case letters are different.
All characters are significant.15
Table 2: Ranges of characters allowed   [tab:lex.name.allowed]
00A8
00AA
00AD
00AF
00B2-00B5
00B7-00BA
00BC-00BE
00C0-00D6
00D8-00F6
00F8-00FF
0100-167F
1681-180D
180F-1FFF
200B-200D
202A-202E
203F-2040
2054
2060-206F
2070-218F
2460-24FF
2776-2793
2C00-2DFF
2E80-2FFF
3004-3007
3021-302F
3031-D7FF
F900-FD3D
FD40-FDCF
FDF0-FE44
FE47-FFFD
10000-1FFFD
20000-2FFFD
30000-3FFFD
40000-4FFFD
50000-5FFFD
60000-6FFFD
70000-7FFFD
80000-8FFFD
90000-9FFFD
A0000-AFFFD
B0000-BFFFD
C0000-CFFFD
D0000-DFFFD
E0000-EFFFD
Table 3: Ranges of characters disallowed initially (combining characters)   [tab:lex.name.disallowed]
0300-036F
1DC0-1DFF
20D0-20FF
FE20-FE2F
The identifiers in Table 4 have a special meaning when appearing in a certain context.
When referred to in the grammar, these identifiers are used explicitly rather than using the identifier grammar production.
Unless otherwise specified, any ambiguity as to whether a given identifier has a special meaning is resolved to interpret the token as a regular identifier.
Table 4: Identifiers with special meaning   [tab:lex.name.special]
final
import
module
override
In addition, some identifiers are reserved for use by C++ implementations and shall not be used otherwise; no diagnostic is required.
  • Each identifier that contains a double underscore __ or begins with an underscore followed by an uppercase letter is reserved to the implementation for any use.
  • Each identifier that begins with an underscore is reserved to the implementation for use as a name in the global namespace.
On systems in which linkers cannot accept extended characters, an encoding of the universal-character-name may be used in forming valid external identifiers.
For example, some otherwise unused character or sequence of characters may be used to encode the \u in a universal-character-name.
Extended characters may produce a long external identifier, but C++ does not place a translation limit on significant characters for external identifiers.
In C++, upper- and lower-case letters are considered different for all identifiers, including external identifiers.

5.11 Keywords [lex.key]

keyword:
	any identifier listed in Table tab:lex.key
	import-keyword
	module-keyword
	export-keyword
The identifiers shown in Table 5 are reserved for use as keywords (that is, they are unconditionally treated as keywords in phase 7) except in an attribute-token.
Note
:
The register keyword is unused but is reserved for future use.
— end note
 ]
Table 5: Keywords   [tab:lex.key]
alignas
constinit
false
public
true
alignof
const_­cast
float
register
try
asm
continue
for
reinterpret_­cast
typedef
auto
co_­await
friend
requires
typeid
bool
co_­return
goto
return
typename
break
co_­yield
if
short
union
case
decltype
inline
signed
unsigned
catch
default
int
sizeof
using
char
delete
long
static
virtual
char8_­t
do
mutable
static_­assert
void
char16_­t
double
namespace
static_­cast
volatile
char32_­t
dynamic_­cast
new
struct
wchar_­t
class
else
noexcept
switch
while
concept
enum
nullptr
template
const
explicit
operator
this
consteval
export
private
thread_­local
constexpr
extern
protected
throw
Furthermore, the alternative representations shown in Table 6 for certain operators and punctuators ([lex.digraph]) are reserved and shall not be used otherwise.
Table 6: Alternative representations   [tab:lex.key.digraph]
and
and_­eq
bitand
bitor
compl
not
not_­eq
or
or_­eq
xor
xor_­eq

5.12 Operators and punctuators [lex.operators]

The lexical representation of C++ programs includes a number of preprocessing tokens that are used in the syntax of the preprocessor or are converted into tokens for operators and punctuators:
preprocessing-op-or-punc:
	preprocessing-operator
	operator-or-punctuator
preprocessing-operator: one of
	#        ##       %:       %:%:
operator-or-punctuator: one of
	{        }        [        ]        (        )
	<:       :>       <%       %>       ;        :        ...
	?        ::       .        .*       ->       ->*      ~
	!        +        -        *        /        %        ^        &        |
	=        +=       -=       *=       /=       %=       ^=       &=       |=
	==       !=       <        >        <=       >=       <=>      &&       ||
	<<       >>       <<=      >>=      ++       --       ,
	and      or       xor      not      bitand   bitor    compl
	and_eq   or_eq    xor_eq   not_eq
Each operator-or-punctuator is converted to a single token in translation phase 7.

5.13 Literals [lex.literal]

5.13.1 Kinds of literals [lex.literal.kinds]

The term “literal” generally designates, in this document, those tokens that are called “constants” in ISO C.

5.13.2 Integer literals [lex.icon]

integer-literal:
	binary-literal integer-suffix
	octal-literal integer-suffix
	decimal-literal integer-suffix
	hexadecimal-literal integer-suffix
binary-literal:
	0b binary-digit
	0B binary-digit
	binary-literal ' binary-digit
octal-literal:
	0
	octal-literal ' octal-digit
decimal-literal:
	nonzero-digit
	decimal-literal ' digit
hexadecimal-literal:
	hexadecimal-prefix hexadecimal-digit-sequence
binary-digit: one of
	0  1
octal-digit: one of
	0  1  2  3  4  5  6  7
nonzero-digit: one of
	1  2  3  4  5  6  7  8  9
hexadecimal-prefix: one of
	0x  0X
hexadecimal-digit-sequence:
	hexadecimal-digit
	hexadecimal-digit-sequence ' hexadecimal-digit
hexadecimal-digit: one of
	0  1  2  3  4  5  6  7  8  9
	a  b  c  d  e  f
	A  B  C  D  E  F
integer-suffix:
	unsigned-suffix long-suffix 
	unsigned-suffix long-long-suffix 
	long-suffix unsigned-suffix 
	long-long-suffix unsigned-suffix
unsigned-suffix: one of
	u  U
long-suffix: one of
	l  L
long-long-suffix: one of
	ll  LL
In an integer-literal, the sequence of binary-digits, octal-digits, digits, or hexadecimal-digits is interpreted as a base N integer as shown in table Table 7; the lexically first digit of the sequence of digits is the most significant.
Note
:
The prefix and any optional separating single quotes are ignored when determining the value.
— end note
 ]
Table 7: Base of integer-literals   [tab:lex.icon.base]
Kind of integer-literal
base N
binary-literal
2
octal-literal
8
decimal-literal
10
hexadecimal-literal
16
The hexadecimal-digits a through f and A through F have decimal values ten through fifteen.
Example
:
The number twelve can be written 12, 014, 0XC, or 0b1100.
The integer-literals 1048576, 1'048'576, 0X100000, 0x10'0000, and 0'004'000'000 all have the same value.
— end example
 ]
The type of an integer-literal is the first type in the list in Table 8 corresponding to its optional integer-suffix in which its value can be represented.
An integer-literal is a prvalue.
Table 8: Types of integer-literals   [tab:lex.icon.type]
integer-suffix
decimal-literal
integer-literal other than decimal-literal
none
int
int
long int
unsigned int
long long int
long int
unsigned long int
long long int
unsigned long long int
u or U
unsigned int
unsigned int
unsigned long int
unsigned long int
unsigned long long int
unsigned long long int
l or L
long int
long int
long long int
unsigned long int
long long int
unsigned long long int
Both u or U
unsigned long int
unsigned long int
and l or L
unsigned long long int
unsigned long long int
ll or LL
long long int
long long int
unsigned long long int
Both u or U
unsigned long long int
unsigned long long int
and ll or LL
If an integer-literal cannot be represented by any type in its list and an extended integer type ([basic.fundamental]) can represent its value, it may have that extended integer type.
If all of the types in the list for the integer-literal are signed, the extended integer type shall be signed.
If all of the types in the list for the integer-literal are unsigned, the extended integer type shall be unsigned.
If the list contains both signed and unsigned types, the extended integer type may be signed or unsigned.
A program is ill-formed if one of its translation units contains an integer-literal that cannot be represented by any of the allowed types.

5.13.3 Character literals [lex.ccon]

character-literal:
	encoding-prefix ' c-char-sequence '
encoding-prefix: one of
	u8  u  U  L
c-char-sequence:
	c-char
	c-char-sequence c-char
c-char:
	any member of the basic source character set except the single-quote ', backslash \, or new-line character
	escape-sequence
	universal-character-name
escape-sequence:
	simple-escape-sequence
	octal-escape-sequence
	hexadecimal-escape-sequence
simple-escape-sequence: one of
	\'  \"  \?  \\
	\a  \b  \f  \n  \r  \t  \v
octal-escape-sequence:
	\ octal-digit
	\ octal-digit octal-digit
	\ octal-digit octal-digit octal-digit
hexadecimal-escape-sequence:
	\x hexadecimal-digit
	hexadecimal-escape-sequence hexadecimal-digit
A character-literal that does not begin with u8, u, U, or L is an ordinary character literal.
An ordinary character literal that contains a single c-char representable in the execution character set has type char, with value equal to the numerical value of the encoding of the c-char in the execution character set.
An ordinary character literal that contains more than one c-char is a multicharacter literal.
A multicharacter literal, or an ordinary character literal containing a single c-char not representable in the execution character set, is conditionally-supported, has type int, and has an implementation-defined value.
A character-literal that begins with u8, such as u8'w', is a character-literal of type char8_­t, known as a UTF-8 character literal.
The value of a UTF-8 character literal is equal to its ISO/IEC 10646 code point value, provided that the code point value can be encoded as a single UTF-8 code unit.
Note
:
That is, provided the code point value is in the range (hexadecimal).
— end note
 ]
If the value is not representable with a single UTF-8 code unit, the program is ill-formed.
A UTF-8 character literal containing multiple c-chars is ill-formed.
A character-literal that begins with the letter u, such as u'x', is a character-literal of type char16_­t, known as a UTF-16 character literal.
The value of a UTF-16 character literal is equal to its ISO/IEC 10646 code point value, provided that the code point value is representable with a single 16-bit code unit.
Note
:
That is, provided the code point value is in the range (hexadecimal).
— end note
 ]
If the value is not representable with a single 16-bit code unit, the program is ill-formed.
A UTF-16 character literal containing multiple c-chars is ill-formed.
A character-literal that begins with the letter U, such as U'y', is a character-literal of type char32_­t, known as a UTF-32 character literal.
The value of a UTF-32 character literal containing a single c-char is equal to its ISO/IEC 10646 code point value.
A UTF-32 character literal containing multiple c-chars is ill-formed.
A character-literal that begins with the letter L, such as L'z', is a wide-character literal.
A wide-character literal has type wchar_­t.17
The value of a wide-character literal containing a single c-char has value equal to the numerical value of the encoding of the c-char in the execution wide-character set, unless the c-char has no representation in the execution wide-character set, in which case the value is implementation-defined.
Note
:
The type wchar_­t is able to represent all members of the execution wide-character set (see [basic.fundamental]).
— end note
 ]
The value of a wide-character literal containing multiple c-chars is implementation-defined.
Certain non-graphic characters, the single quote ', the double quote ", the question mark ?,18 and the backslash \, can be represented according to Table 9.
The double quote " and the question mark ?, can be represented as themselves or by the escape sequences \" and \? respectively, but the single quote ' and the backslash \ shall be represented by the escape sequences \' and \\ respectively.
Escape sequences in which the character following the backslash is not listed in Table 9 are conditionally-supported, with implementation-defined semantics.
An escape sequence specifies a single character.
Table 9: Escape sequences   [tab:lex.ccon.esc]
new-line
NL(LF)
\n
horizontal tab
HT
\t
vertical tab
VT
\v
backspace
BS
\b
carriage return
CR
\r
form feed
FF
\f
alert
BEL
\a
backslash
\
\\
question mark
?
\?
single quote
'
\'
double quote
"
\"
octal number
ooo
\ooo
hex number
hhh
\xhhh
The escape \ooo consists of the backslash followed by one, two, or three octal digits that are taken to specify the value of the desired character.
The escape \xhhh consists of the backslash followed by x followed by one or more hexadecimal digits that are taken to specify the value of the desired character.
There is no limit to the number of digits in a hexadecimal sequence.
A sequence of octal or hexadecimal digits is terminated by the first character that is not an octal digit or a hexadecimal digit, respectively.
The value of a character-literal is implementation-defined if it falls outside of the implementation-defined range defined for char (for character-literals with no prefix) or wchar_­t (for character-literals prefixed by L).
Note
:
If the value of a character-literal prefixed by u, u8, or U is outside the range defined for its type, the program is ill-formed.
— end note
 ]
A universal-character-name is translated to the encoding, in the appropriate execution character set, of the character named.
If there is no such encoding, the universal-character-name is translated to an implementation-defined encoding.
Note
:
In translation phase 1, a universal-character-name is introduced whenever an actual extended character is encountered in the source text.
Therefore, all extended characters are described in terms of universal-character-names.
However, the actual compiler implementation may use its own native character set, so long as the same results are obtained.
— end note
 ]
They are intended for character sets where a character does not fit into a single byte.
Using an escape sequence for a question mark is supported for compatibility with ISO C++ 2014 and ISO C.

5.13.4 Floating-point literals [lex.fcon]

floating-point-literal:
	decimal-floating-point-literal
	hexadecimal-floating-point-literal
decimal-floating-point-literal:
	fractional-constant exponent-part floating-point-suffix
	digit-sequence exponent-part floating-point-suffix
hexadecimal-floating-point-literal:
	hexadecimal-prefix hexadecimal-fractional-constant binary-exponent-part floating-point-suffix
	hexadecimal-prefix hexadecimal-digit-sequence binary-exponent-part floating-point-suffix
fractional-constant:
	digit-sequence . digit-sequence
	digit-sequence .
hexadecimal-fractional-constant:
	hexadecimal-digit-sequence . hexadecimal-digit-sequence
	hexadecimal-digit-sequence .
exponent-part:
	e sign digit-sequence
	E sign digit-sequence
binary-exponent-part:
	p sign digit-sequence
	P sign digit-sequence
sign: one of
	+  -
digit-sequence:
	digit
	digit-sequence ' digit
floating-point-suffix: one of
	f  l  F  L
The type of a floating-point-literal is determined by its floating-point-suffix as specified in Table 10.
Table 10: Types of floating-point-literals   [tab:lex.fcon.type]
floating-point-suffix
type
none
double
f or F
float
l or L
long double
In the significand, the sequence of digits or hexadecimal-digits and optional period are interpreted as a base N real number s, where N is 10 for a decimal-floating-point-literal and 16 for a hexadecimal-floating-point-literal.
Note
:
Any optional separating single quotes are ignored when determining the value.
— end note
 ]
If an exponent-part or binary-exponent-part is present, the exponent e of the floating-point-literal is the result of interpreting the sequence of an optional sign and the digits as a base 10 integer.
Otherwise, the exponent e is 0.
The scaled value of the literal is for a decimal-floating-point-literal and for a hexadecimal-floating-point-literal.
Example
:
The floating-point-literals 49.625 and 0xC.68p+2 have the same value.
The floating-point-literals 1.602'176'565e-19 and 1.602176565e-19 have the same value.
— end example
 ]
If the scaled value is not in the range of representable values for its type, the program is ill-formed.
Otherwise, the value of a floating-point-literal is the scaled value if representable, else the larger or smaller representable value nearest the scaled value, chosen in an implementation-defined manner.

5.13.5 String literals [lex.string]

string-literal:
	encoding-prefix " s-char-sequence "
	encoding-prefix R raw-string
s-char-sequence:
	s-char
	s-char-sequence s-char
s-char:
	any member of the basic source character set except the double-quote ", backslash \, or new-line character
	escape-sequence
	universal-character-name
raw-string:
	" d-char-sequence ( r-char-sequence ) d-char-sequence "
r-char-sequence:
	r-char
	r-char-sequence r-char
r-char:
	any member of the source character set, except a right parenthesis ) followed by
		the initial d-char-sequence (which may be empty) followed by a double quote ".
d-char-sequence:
	d-char
	d-char-sequence d-char
d-char:
	any member of the basic source character set except:
		space, the left parenthesis (, the right parenthesis ), the backslash \, and the control characters
		representing horizontal tab, vertical tab, form feed, and newline.
A string-literal that has an R in the prefix is a raw string literal.
The d-char-sequence serves as a delimiter.
The terminating d-char-sequence of a raw-string is the same sequence of characters as the initial d-char-sequence.
A d-char-sequence shall consist of at most 16 characters.
Note
:
The characters '(' and ')' are permitted in a raw-string.
Thus, R"delimiter((a|b))delimiter" is equivalent to "(a|b)".
— end note
 ]
Note
:
A source-file new-line in a raw string literal results in a new-line in the resulting execution string literal.
Assuming no whitespace at the beginning of lines in the following example, the assert will succeed:
const char* p = R"(a\
b
c)";
assert(std::strcmp(p, "a\\\nb\nc") == 0);
— end note
 ]
Example
:
The raw string
R"a(
)\
a"
)a"
is equivalent to "\n)\\\na\"\n".
The raw string
R"(x = "\"y\"")"
is equivalent to "x = \"\\\"y\\\"\"".
— end example
 ]
After translation phase 6, a string-literal that does not begin with an encoding-prefix is an ordinary string literal.
An ordinary string literal has type “array of n const char” where n is the size of the string as defined below, has static storage duration ([basic.stc]), and is initialized with the given characters.
A string-literal that begins with u8, such as u8"asdf", is a UTF-8 string literal.
A UTF-8 string literal has type “array of n const char8_­t”, where n is the size of the string as defined below; each successive element of the object representation ([basic.types]) has the value of the corresponding code unit of the UTF-8 encoding of the string.
Ordinary string literals and UTF-8 string literals are also referred to as narrow string literals.
A string-literal that begins with u, such as u"asdf", is a UTF-16 string literal.
A UTF-16 string literal has type “array of n const char16_­t”, where n is the size of the string as defined below; each successive element of the array has the value of the corresponding code unit of the UTF-16 encoding of the string.
Note
:
A single c-char may produce more than one char16_­t character in the form of surrogate pairs.
A surrogate pair is a representation for a single code point as a sequence of two 16-bit code units.
— end note
 ]
A string-literal that begins with U, such as U"asdf", is a UTF-32 string literal.
A UTF-32 string literal has type “array of n const char32_­t”, where n is the size of the string as defined below; each successive element of the array has the value of the corresponding code unit of the UTF-32 encoding of the string.
A string-literal that begins with L, such as L"asdf", is a wide string literal.
A wide string literal has type “array of n const wchar_­t”, where n is the size of the string as defined below; it is initialized with the given characters.
In translation phase 6 ([lex.phases]), adjacent string-literals are concatenated.
If both string-literals have the same encoding-prefix, the resulting concatenated string-literal has that encoding-prefix.
If one string-literal has no encoding-prefix, it is treated as a string-literal of the same encoding-prefix as the other operand.
If a UTF-8 string literal token is adjacent to a wide string literal token, the program is ill-formed.
Any other concatenations are conditionally-supported with implementation-defined behavior.
Note
:
This concatenation is an interpretation, not a conversion.
Because the interpretation happens in translation phase 6 (after each character from a string-literal has been translated into a value from the appropriate character set), a string-literal's initial rawness has no effect on the interpretation or well-formedness of the concatenation.
— end note
 ]
Table 11 has some examples of valid concatenations.
Table 11: String literal concatenations   [tab:lex.string.concat]
Source
Means
Source
Means
Source
Means
u"a"
u"b"
u"ab"
U"a"
U"b"
U"ab"
L"a"
L"b"
L"ab"
u"a"
"b"
u"ab"
U"a"
"b"
U"ab"
L"a"
"b"
L"ab"
"a"
u"b"
u"ab"
"a"
U"b"
U"ab"
"a"
L"b"
L"ab"
Characters in concatenated strings are kept distinct.
Example
:
"\xA" "B"
contains the two characters '\xA' and 'B' after concatenation (and not the single hexadecimal character '\xAB').
— end example
 ]
After any necessary concatenation, in translation phase 7 ([lex.phases]), '\0' is appended to every string-literal so that programs that scan a string can find its end.
Escape sequences and universal-character-names in non-raw string literals have the same meaning as in character-literals ([lex.ccon]), except that the single quote ' is representable either by itself or by the escape sequence \', and the double quote " shall be preceded by a \, and except that a universal-character-name in a UTF-16 string literal may yield a surrogate pair.
In a narrow string literal, a universal-character-name may map to more than one char or char8_­t element due to multibyte encoding.
The size of a char32_­t or wide string literal is the total number of escape sequences, universal-character-names, and other characters, plus one for the terminating U'\0' or L'\0'.
The size of a UTF-16 string literal is the total number of escape sequences, universal-character-names, and other characters, plus one for each character requiring a surrogate pair, plus one for the terminating u'\0'.
Note
:
The size of a char16_­t string literal is the number of code units, not the number of characters.
— end note
 ]
Note
:
Any universal-character-names are required to correspond to a code point in the range or (hexadecimal) ([lex.charset]).
— end note
 ]
The size of a narrow string literal is the total number of escape sequences and other characters, plus at least one for the multibyte encoding of each universal-character-name, plus one for the terminating '\0'.
Evaluating a string-literal results in a string literal object with static storage duration, initialized from the given characters as specified above.
Whether all string-literals are distinct (that is, are stored in nonoverlapping objects) and whether successive evaluations of a string-literal yield the same or a different object is unspecified.
Note
:
The effect of attempting to modify a string-literal is undefined.
— end note
 ]

5.13.6 Boolean literals [lex.bool]

boolean-literal:
	false
	true
The Boolean literals are the keywords false and true.
Such literals are prvalues and have type bool.

5.13.7 Pointer literals [lex.nullptr]

pointer-literal:
	nullptr
The pointer literal is the keyword nullptr.
It is a prvalue of type std​::​nullptr_­t.
Note
:
std​::​nullptr_­t is a distinct type that is neither a pointer type nor a pointer-to-member type; rather, a prvalue of this type is a null pointer constant and can be converted to a null pointer value or null member pointer value.
— end note
 ]

5.13.8 User-defined literals [lex.ext]

user-defined-literal:
	user-defined-integer-literal
	user-defined-floating-point-literal
	user-defined-string-literal
	user-defined-character-literal
user-defined-integer-literal:
	decimal-literal ud-suffix
	octal-literal ud-suffix
	hexadecimal-literal ud-suffix
	binary-literal ud-suffix
user-defined-floating-point-literal:
	fractional-constant exponent-part ud-suffix
	digit-sequence exponent-part ud-suffix
	hexadecimal-prefix hexadecimal-fractional-constant binary-exponent-part ud-suffix
	hexadecimal-prefix hexadecimal-digit-sequence binary-exponent-part ud-suffix
user-defined-string-literal:
	string-literal ud-suffix
user-defined-character-literal:
	character-literal ud-suffix
ud-suffix:
	identifier
If a token matches both user-defined-literal and another literal kind, it is treated as the latter.
Example
:
123_­km is a user-defined-literal, but 12LL is an integer-literal.
— end example
 ]
The syntactic non-terminal preceding the ud-suffix in a user-defined-literal is taken to be the longest sequence of characters that could match that non-terminal.
To determine the form of this call for a given user-defined-literal L with ud-suffix X, the literal-operator-id whose literal suffix identifier is X is looked up in the context of L using the rules for unqualified name lookup.
Let S be the set of declarations found by this lookup.
S shall not be empty.
If L is a user-defined-integer-literal, let n be the literal without its ud-suffix.
If S contains a literal operator with parameter type unsigned long long, the literal L is treated as a call of the form
operator "" X(nULL)
Otherwise, S shall contain a raw literal operator or a numeric literal operator template ([over.literal]) but not both.
If S contains a raw literal operator, the literal L is treated as a call of the form
operator "" X("n")
Otherwise (S contains a numeric literal operator template), L is treated as a call of the form
operator "" X<'', '', ... ''>()
where n is the source character sequence .
Note
:
The sequence can only contain characters from the basic source character set.
— end note
 ]
If L is a user-defined-floating-point-literal, let f be the literal without its ud-suffix.
If S contains a literal operator with parameter type long double, the literal L is treated as a call of the form
operator "" X(fL)
Otherwise, S shall contain a raw literal operator or a numeric literal operator template ([over.literal]) but not both.
If S contains a raw literal operator, the literal L is treated as a call of the form
operator "" X("f")
Otherwise (S contains a numeric literal operator template), L is treated as a call of the form
operator "" X<'', '', ... ''>()
where f is the source character sequence .
Note
:
The sequence can only contain characters from the basic source character set.
— end note
 ]
If L is a user-defined-string-literal, let str be the literal without its ud-suffix and let len be the number of code units in str (i.e., its length excluding the terminating null character).
If S contains a literal operator template with a non-type template parameter for which str is a well-formed template-argument, the literal L is treated as a call of the form
operator "" X<str>()
Otherwise, the literal L is treated as a call of the form
operator "" X(str, len)
If L is a user-defined-character-literal, let ch be the literal without its ud-suffix.
S shall contain a literal operator whose only parameter has the type of ch and the literal L is treated as a call of the form
operator "" X(ch)
Example
:
long double operator "" _w(long double);
std::string operator "" _w(const char16_t*, std::size_t);
unsigned operator "" _w(const char*);
int main() {
  1.2_w;            // calls operator "" _­w(1.2L)
  u"one"_w;         // calls operator "" _­w(u"one", 3)
  12_w;             // calls operator "" _­w("12")
  "two"_w;          // error: no applicable literal operator
}
— end example
 ]
In translation phase 6 ([lex.phases]), adjacent string-literals are concatenated and user-defined-string-literals are considered string-literals for that purpose.
During concatenation, ud-suffixes are removed and ignored and the concatenation process occurs as described in [lex.string].
At the end of phase 6, if a string-literal is the result of a concatenation involving at least one user-defined-string-literal, all the participating user-defined-string-literals shall have the same ud-suffix and that suffix is applied to the result of the concatenation.
Example
:
int main() {
  L"A" "B" "C"_x;   // OK: same as L"ABC"_­x
  "P"_x "Q" "R"_y;  // error: two different ud-suffixes
}
— end example
 ]

6 Basics [basic]

6.1 Preamble [basic.pre]

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

6.2 Declarations and definitions [basic.def]

A declaration may introduce one or more names into a translation unit or redeclare names introduced by previous declarations.
If so, the declaration specifies the interpretation and semantic properties of these names.
A declaration may also have effects including:
Each entity declared by a declaration is also defined by that declaration unless:
A declaration is said to be a definition of each entity that it defines.
Example
:
All but one of the following are definitions:
int a;                          // defines a
extern const int c = 1;         // defines c
int f(int x) { return x+a; }    // defines f and defines x
struct S { int a; int b; };     // defines S, S​::​a, and S​::​b
struct X {                      // defines X
  int x;                        // defines non-static data member x
  static int y;                 // declares static data member y
  X(): x(0) { }                 // defines a constructor of X
};
int X::y = 1;                   // defines X​::​y
enum { up, down };              // defines up and down
namespace N { int d; }          // defines N and N​::​d
namespace N1 = N;               // defines N1
X anX;                          // defines anX

whereas these are just declarations:
extern int a;                   // declares a
extern const int c;             // declares c
int f(int);                     // declares f
struct S;                       // declares S
typedef int Int;                // declares Int
extern X anotherX;              // declares anotherX
using N::d;                     // declares d
— end example
 ]
Note
:
In some circumstances, C++ implementations implicitly define the default constructor ([class.default.ctor]), copy constructor, move constructor ([class.copy.ctor]), copy assignment operator, move assignment operator ([class.copy.assign]), or destructor member functions.
— end note
 ]
Example
:
Given
#include <string>

struct C {
  std::string s;    // std​::​string is the standard library class ([string.classes])
};

int main() {
  C a;
  C b = a;
  b = a;
}
the implementation will implicitly define functions to make the definition of C equivalent to
struct C {
  std::string s;
  C() : s() { }
  C(const C& x): s(x.s) { }
  C(C&& x): s(static_cast<std::string&&>(x.s)) { }
      //    : s(std​::​move(x.s)) { }
  C& operator=(const C& x) { s = x.s; return *this; }
  C& operator=(C&& x) { s = static_cast<std::string&&>(x.s); return *this; }
      //                { s = std​::​move(x.s); return *this; }
  ~C() { }
};
— end example
 ]
Note
:
A class name can also be implicitly declared by an elaborated-type-specifier.
— end note
 ]
In the definition of an object, the type of that object shall not be an incomplete type ([basic.types]), an abstract class type, or a (possibly multi-dimensional) array thereof.
Appearing inside the brace-enclosed declaration-seq in a linkage-specification does not affect whether a declaration is a definition.

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

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

6.4 Scope [basic.scope]

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

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

6.4.2 Point of declaration [basic.scope.pdecl]

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

6.4.3 Block scope [basic.scope.block]

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

6.4.4 Function parameter scope [basic.scope.param]

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

6.4.5 Function scope [basic.funscope]

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

6.4.6 Namespace scope [basic.scope.namespace]

The declarative region of a namespace-definition is its namespace-body.
Entities declared in a namespace-body are said to be members of the namespace, and names introduced by these declarations into the declarative region of the namespace are said to be member names of the namespace.
A namespace member name has namespace scope.
Its potential scope includes its namespace from the name's point of declaration onwards; and for each using-directive that nominates the member's namespace, the member's potential scope includes that portion of the potential scope of the using-directive that follows the member's point of declaration.
Example
:
namespace N {
  int i;
  int g(int a) { return a; }
  int j();
  void q();
}
namespace { int l=1; }
// the potential scope of l is from its point of declaration to the end of the translation unit

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

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

  int j() {         // OK: definition of N​::​j()
    return g(i);    // calls N​::​g(int)
  }
  int q();          // error: different return type
}
— end example
 ]
If a translation unit Q is imported into a translation unit R ([module.import]), the potential scope of a name X declared with namespace scope in Q is extended to include the portion of the corresponding namespace scope in R following the first module-import-declaration or module-declaration in R that imports Q (directly or indirectly) if
  • X does not have internal linkage, and
  • X is declared after the module-declaration in Q (if any), and
  • either X is exported or Q and R are part of the same module.
Note
:
A module-import-declaration imports both the named translation unit(s) and any modules named by exported module-import-declarations within them, recursively.
Example
:

Translation unit #1:

export module Q;
export int sq(int i) { return i*i; }

Translation unit #2:

export module R;
export import Q;

Translation unit #3:

import R;
int main() { return sq(9); }    // OK: sq from module Q
— end example
 ]
— end note
 ]
A namespace member can also be referred to after the ​::​ scope resolution operator ([expr.prim.id.qual]) applied to the name of its namespace or the name of a namespace which nominates the member's namespace in a using-directive; see [namespace.qual].
The outermost declarative region of a translation unit is also a namespace, called the global namespace.
A name declared in the global namespace has global namespace scope (also called global scope).
The potential scope of such a name begins at its point of declaration ([basic.scope.pdecl]) and ends at the end of the translation unit that is its declarative region.
A name with global namespace scope is said to be a global name.

6.4.7 Class scope [basic.scope.class]

The potential scope of a name declared in a class consists not only of the declarative region following the name's point of declaration, but also of all complete-class contexts ([class.mem]) of that class.
A name N used in a class S shall refer to the same declaration in its context and when re-evaluated in the completed scope of S.
No diagnostic is required for a violation of this rule.
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.
The potential scope of a declaration in a class that extends to or past the end of a class definition also extends to the regions defined by its member definitions, even if the members are defined lexically outside the class (this includes static data member definitions, nested class definitions, and member function definitions, including the member function body and any portion of the declarator part of such definitions which follows the declarator-id, including a parameter-declaration-clause and any default arguments).
Example
:
typedef int  c;
enum { i = 1 };

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

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

typedef int I;
class D {
  typedef I I;                      // error, even though no reordering involved
};
— end example
 ]
The name of a class member shall only be used as follows:
  • in the scope of its class (as described above) or a class derived from its class,
  • after the . operator applied to an expression of the type of its class ([expr.ref]) or a class derived from its class,
  • after the -> operator applied to a pointer to an object of its class ([expr.ref]) or a class derived from its class,
  • after the ​::​ scope resolution operator ([expr.prim.id.qual]) applied to the name of its class or a class derived from its class.

6.4.8 Enumeration scope [basic.scope.enum]

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

6.4.9 Template parameter scope [basic.scope.temp]

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

6.4.10 Name hiding [basic.scope.hiding]

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

6.5 Name lookup [basic.lookup]

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

6.5.1 Unqualified name lookup [basic.lookup.unqual]

In all the cases listed in [basic.lookup.unqual], the scopes are searched for a declaration in the order listed in each of the respective categories; name lookup ends as soon as a declaration is found for the name.
If no declaration is found, the program is ill-formed.
The declarations from the namespace nominated by a using-directive become visible in a namespace enclosing the using-directive; see [namespace.udir].
For the purpose of the unqualified name lookup rules described in [basic.lookup.unqual], the declarations from the namespace nominated by the using-directive are considered members of that enclosing namespace.
The lookup for an unqualified name used as the postfix-expression of a function call is described in [basic.lookup.argdep].
Note
:
For purposes of determining (during parsing) whether an expression is a postfix-expression for a function call, the usual name lookup rules apply.
In some cases a name followed by < is treated as a template-name even though name lookup did not find a template-name (see [temp.names]).
For example,
int h;
void g();
namespace N {
  struct A {};
  template <class T> int f(T);
  template <class T> int g(T);
  template <class T> int h(T);
}

int x = f<N::A>(N::A());        // OK: lookup of f finds nothing, f treated as template name
int y = g<N::A>(N::A());        // OK: lookup of g finds a function, g treated as template name
int z = h<N::A>(N::A());        // error: h< does not begin a template-id
The rules in [basic.lookup.argdep] have no effect on the syntactic interpretation of an expression.
For example,
typedef int f;
namespace N {
  struct A {
    friend void f(A &);
    operator int();
    void g(A a) {
      int i = f(a);             // f is the typedef, not the friend function: equivalent to int(a)
    }
  };
}
Because the expression is not a function call, the argument-dependent name lookup ([basic.lookup.argdep]) does not apply and the friend function f is not found.
— end note
 ]
A name used in global scope, outside of any function, class or user-declared namespace, shall be declared before its use in global scope.
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.
In the definition of a function that is a member of namespace N, a name used after the function's declarator-id21 shall be declared before its use in the block in which it is used or in one of its enclosing blocks ([stmt.block]) or shall be declared before its use in namespace N or, if N is a nested namespace, shall be declared before its use in one of N's enclosing namespaces.
Example
:
namespace A {
  namespace N {
    void f();
  }
}
void A::N::f() {
  i = 5;
  // The following scopes are searched for a declaration of i:
  // 1) outermost block scope of A​::​N​::​f, before the use of i
  // 2) scope of namespace N
  // 3) scope of namespace A
  // 4) global scope, before the definition of A​::​N​::​f
}
— end example
 ]
A name used in the definition of a class X22 outside of a complete-class context ([class.mem]) of X shall be declared in one of the following ways:
  • before its use in class X or be a member of a base class of X ([class.member.lookup]), or
  • if X is a nested class of class Y, before the definition of X in Y, or shall be a member of a base class of Y (this lookup applies in turn to Y's enclosing classes, starting with the innermost enclosing class),23 or
  • if X is a local class or is a nested class of a local class, before the definition of class X in a block enclosing the definition of class X, or
  • if X is a member of namespace N, or is a nested class of a class that is a member of N, or is a local class or a nested class within a local class of a function that is a member of N, before the definition of class X in namespace N or in one of N's enclosing namespaces.
Example
:
namespace M {
  class B { };
}

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

// The following scopes are searched for a declaration of i:
// 1) scope of class N​::​Y​::​X, before the use of i
// 2) scope of class N​::​Y, before the definition of N​::​Y​::​X
// 3) scope of N​::​Y's base class M​::​B
// 4) scope of namespace N, before the definition of N​::​Y
// 5) global scope, before the definition of N
— end example
 ]
Note
:
When looking for a prior declaration of a class or function introduced by a friend declaration, scopes outside of the innermost enclosing namespace scope are not considered; see [namespace.memdef].
— end note
 ]
Note
:
[basic.scope.class] further describes the restrictions on the use of names in a class definition.
[class.nest] further describes the restrictions on the use of names in nested class definitions.
[class.local] further describes the restrictions on the use of names in local class definitions.
— end note
 ]
For the members of a class X, a name used in a complete-class context ([class.mem]) of X or in the definition of a class member outside of the definition of X, following the member's declarator-id24, shall be declared in one of the following ways:
  • before its use in the block in which it is used or in an enclosing block ([stmt.block]), or
  • shall be a member of class X or be a member of a base class of X ([class.member.lookup]), or
  • if X is a nested class of class Y, shall be a member of Y, or shall be a member of a base class of Y (this lookup applies in turn to Y's enclosing classes, starting with the innermost enclosing class),25 or
  • if X is a local class or is a nested class of a local class, before the definition of class X in a block enclosing the definition of class X, or
  • if X is a member of namespace N, or is a nested class of a class that is a member of N, or is a local class or a nested class within a local class of a function that is a member of N, before the use of the name, in namespace N or in one of N's enclosing namespaces.
Example
:
class B { };
namespace M {
  namespace N {
    class X : public B {
      void f();
    };
  }
}
void M::N::X::f() {
  i = 16;
}

// The following scopes are searched for a declaration of i:
// 1) outermost block scope of M​::​N​::​X​::​f, before the use of i
// 2) scope of class M​::​N​::​X
// 3) scope of M​::​N​::​X's base class B
// 4) scope of namespace M​::​N
// 5) scope of namespace M
// 6) global scope, before the definition of M​::​N​::​X​::​f
— end example
 ]
Note
:
[class.mfct] and [class.static] further describe the restrictions on the use of names in member function definitions.
[class.nest] further describes the restrictions on the use of names in the scope of nested classes.
[class.local] further describes the restrictions on the use of names in local class definitions.
— end note
 ]
Name lookup for a name used in the definition of a friend function defined inline in the class granting friendship shall proceed as described for lookup in member function definitions.
If the friend function is not defined in the class granting friendship, name lookup in the friend function definition shall proceed as described for lookup in namespace member function definitions.
In a friend declaration naming a member function, a name used in the function declarator and not part of a template-argument in the declarator-id is first looked up in the scope of the member function's class ([class.member.lookup]).
If it is not found, or if the name is part of a template-argument in the declarator-id, the look up is as described for unqualified names in the definition of the class granting friendship.
Example
:
struct A {
  typedef int AT;
  void f1(AT);
  void f2(float);
  template <class T> void f3();
};
struct B {
  typedef char AT;
  typedef float BT;
  friend void A::f1(AT);        // parameter type is A​::​AT
  friend void A::f2(BT);        // parameter type is B​::​BT
  friend void A::f3<AT>();      // template argument is B​::​AT
};
— end example
 ]
During the lookup for a name used as a default argument in a function parameter-declaration-clause or used in the expression of a mem-initializer for a constructor ([class.base.init]), the function parameter names are visible and hide the names of entities declared in the block, class or namespace scopes containing the function declaration.
Note
:
[dcl.fct.default] further describes the restrictions on the use of names in default arguments.
[class.base.init] further describes the restrictions on the use of names in a ctor-initializer.
— end note
 ]
During the lookup of a name used in the constant-expression of an enumerator-definition, previously declared enumerators of the enumeration are visible and hide the names of entities declared in the block, class, or namespace scopes containing the enum-specifier.
A name used in the definition of a static data member of class X (after the qualified-id of the static member) is looked up as if the name was used in a member function of X.
Note
:
[class.static.data] further describes the restrictions on the use of names in the definition of a static data member.
— end note
 ]
If a variable member of a namespace is defined outside of the scope of its namespace then any name that appears in the definition of the member (after the declarator-id) is looked up as if the definition of the member occurred in its namespace.
Example
:
namespace N {
  int i = 4;
  extern int j;
}

int i = 2;

int N::j = i;       // N​::​j == 4
— end example
 ]
A name used in the handler for a function-try-block is looked up as if the name was used in the outermost block of the function definition.
In particular, the function parameter names shall not be redeclared in the exception-declaration nor in the outermost block of a handler for the function-try-block.
Names declared in the outermost block of the function definition are not found when looked up in the scope of a handler for the function-try-block.
Note
:
But function parameter names are found.
— end note
 ]
Note
:
The rules for name lookup in template definitions are described in [temp.res].
— end note
 ]
This refers to unqualified names that occur, for instance, in a type or default argument in the parameter-declaration-clause or used in the function body.
This refers to unqualified names following the class name; such a name may be used in a base-specifier or in the member-specification of the class definition.
This lookup applies whether the definition of X is nested within Y's definition or whether X's definition appears in a namespace scope enclosing Y's definition ([class.nest]).
That is, an unqualified name that occurs, for instance, in a type in the parameter-declaration-clause or in the noexcept-specifier.
This lookup applies whether the member function is defined within the definition of class X or whether the member function is defined in a namespace scope enclosing X's definition.

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

When the postfix-expression in a function call is an unqualified-id, other namespaces not considered during the usual unqualified lookup may be searched, and in those namespaces, namespace-scope friend function or function template declarations ([class.friend]) not otherwise visible may be found.
These modifications to the search depend on the types of the arguments (and for template template arguments, the namespace of the template argument).
Example
:
namespace N {
  struct S { };
  void f(S);
}

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

Translation unit #1:

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

Translation unit #2:

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

Translation unit #3:

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

6.5.3 Qualified name lookup [basic.lookup.qual]

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

struct A {
  ~A();
};
typedef A AB;
int main() {
  AB* p;
  p->AB::~AB();     // explicitly calls the destructor for A
}
— end example
 ]
Note
:
[basic.lookup.classref] describes how name lookup proceeds after the . and -> operators.
— end note
 ]

6.5.3.1 Class members [class.qual]

If the nested-name-specifier of a qualified-id nominates a class, the name specified after the nested-name-specifier is looked up in the scope of the class ([class.member.lookup]), except for the cases listed below.
The name shall represent one or more members of that class or of one of its base classes ([class.derived]).
Note
:
A class member can be referred to using a qualified-id at any point in its potential scope ([basic.scope.class]).
— end note
 ]
The exceptions to the name lookup rule above are the following:
In a lookup in which function names are not ignored26 and the nested-name-specifier nominates a class C: the name is instead considered to name the constructor of class C.
Note
:
For example, the constructor is not an acceptable lookup result in an elaborated-type-specifier so the constructor would not be used in place of the injected-class-name.
— end note
 ]
Such a constructor name shall be used only in the declarator-id of a declaration that names a constructor or in a using-declaration.
Example
:
struct A { A(); };
struct B: public A { B(); };

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

B::A ba;            // object of type A
A::A a;             // error: A​::​A is not a type name
struct A::A a2;     // object of type A
— end example
 ]
A class member name hidden by a name in a nested declarative region or by the name of a derived class member can still be found if qualified by the name of its class followed by the ​::​ operator.
Lookups in which function names are ignored include names appearing in a nested-name-specifier, an elaborated-type-specifier, or a base-specifier.

6.5.3.2 Namespace members [namespace.qual]

If the nested-name-specifier of a qualified-id nominates a namespace (including the case where the nested-name-specifier is ​::​, i.e., nominating the global namespace), the name specified after the nested-name-specifier is looked up in the scope of the namespace.
The names in a template-argument of a template-id are looked up in the context in which the entire postfix-expression occurs.
For a namespace X and name m, the namespace-qualified lookup set is defined as follows: Let be the set of all declarations of m in X and the inline namespace set of X ([namespace.def]) whose potential scope ([basic.scope.namespace]) would include the namespace in which m is declared at the location of the nested-name-specifier.
If is not empty, is ; otherwise, is the union of for all namespaces nominated by using-directives in X and its inline namespace set.
Given X​::​m (where X is a user-declared namespace), or given ​::​m (where X is the global namespace), if is the empty set, the program is ill-formed.
Otherwise, if has exactly one member, or if the context of the reference is a using-declaration, is the required set of declarations of m.
Otherwise if the use of m is not one that allows a unique declaration to be chosen from , the program is ill-formed.
Example
:
int x;
namespace Y {
  void f(float);
  void h(int);
}

namespace Z {
  void h(double);
}

namespace A {
  using namespace Y;
  void f(int);
  void g(int);
  int i;
}

namespace B {
  using namespace Z;
  void f(char);
  int i;
}

namespace AB {
  using namespace A;
  using namespace B;
  void g();
}

void h()
{
  AB::g();      // g is declared directly in AB, therefore S is { AB​::​g() } and AB​::​g() is chosen

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

  AB::f('c');   // as above but resolution chooses B​::​f(char)

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

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

  AB::h(16.8);  // h is not declared directly in AB and not declared directly in A or B so the rules
                // are applied recursively to Y and Z, S is  and
                // overload resolution chooses Z​::​h(double)
}
— end example
 ]
Note
:
The same declaration found more than once is not an ambiguity (because it is still a unique declaration).
Example
:
namespace A {
  int a;
}

namespace B {
  using namespace A;
}

namespace C {
  using namespace A;
}

namespace BC {
  using namespace B;
  using namespace C;
}

void f()
{
  BC::a++;          // OK: S is 
}

namespace D {
  using A::a;
}

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

void g()
{
  BD::a++;          // OK: S is 
}
— end example
 ]
— end note
 ]
Example
:
Because each referenced namespace is searched at most once, the following is well-defined:
namespace B {
  int b;
}

namespace A {
  using namespace B;
  int a;
}

namespace B {
  using namespace A;
}

void f()
{
  A::a++;           // OK: a declared directly in A, S is { A​::​a }
  B::a++;           // OK: both A and B searched (once), S is { A​::​a }
  A::b++;           // OK: both A and B searched (once), S is { B​::​b }
  B::b++;           // OK: b declared directly in B, S is { B​::​b }
}
— end example
 ]
During the lookup of a qualified namespace member name, if the lookup finds more than one declaration of the member, and if one declaration introduces a class name or enumeration name and the other declarations introduce either the same variable, the same enumerator, or a set of functions, the non-type name hides the class or enumeration name if and only if the declarations are from the same namespace; otherwise (the declarations are from different namespaces), the program is ill-formed.
Example
:
namespace A {
  struct x { };
  int x;
  int y;
}

namespace B {
  struct y { };
}

namespace C {
  using namespace A;
  using namespace B;
  int i = C::x;     // OK, A​::​x (of type int)
  int j = C::y;     // ambiguous, A​::​y or B​::​y
}
— end example
 ]
In a declaration for a namespace member in which the declarator-id is a qualified-id, given that the qualified-id for the namespace member has the form
nested-name-specifier unqualified-id
the unqualified-id shall name a member of the namespace designated by the nested-name-specifier or of an element of the inline namespace set of that namespace.
Example
:
namespace A {
  namespace B {
    void f1(int);
  }
  using namespace B;
}
void A::f1(int){ }  // error: f1 is not a member of A
— end example
 ]
However, in such namespace member declarations, the nested-name-specifier may rely on using-directives to implicitly provide the initial part of the nested-name-specifier.
Example
:
namespace A {
  namespace B {
    void f1(int);
  }
}

namespace C {
  namespace D {
    void f1(int);
  }
}

using namespace A;
using namespace C::D;
void B::f1(int){ }  // OK, defines A​::​B​::​f1(int)
— end example
 ]

6.5.4 Elaborated type specifiers [basic.lookup.elab]

An elaborated-type-specifier may be used to refer to a previously declared class-name or enum-name even though the name has been hidden by a non-type declaration.
If the elaborated-type-specifier has no nested-name-specifier, and unless the elaborated-type-specifier appears in a declaration with the following form:
class-key attribute-specifier-seq identifier ;
the identifier is looked up according to [basic.lookup.unqual] but ignoring any non-type names that have been declared.
If the elaborated-type-specifier is introduced by the enum keyword and this lookup does not find a previously declared type-name, the elaborated-type-specifier is ill-formed.
If the elaborated-type-specifier is introduced by the class-key and this lookup does not find a previously declared type-name, or if the elaborated-type-specifier appears in a declaration with the form:
class-key attribute-specifier-seq identifier ;
the elaborated-type-specifier is a declaration that introduces the class-name as described in [basic.scope.pdecl].
If the elaborated-type-specifier has a nested-name-specifier, qualified name lookup is performed, as described in [basic.lookup.qual], but ignoring any non-type names that have been declared.
If the name lookup does not find a previously declared type-name, the elaborated-type-specifier is ill-formed.
Example
:
struct Node {
  struct Node* Next;            // OK: Refers to injected-class-name Node
  struct Data* Data;            // OK: Declares type Data at global scope and member Data
};

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

struct Base {
  struct Data;                  // OK: Declares nested Data
  struct ::Data*     thatData;  // OK: Refers to ​::​Data
  struct Base::Data* thisData;  // OK: Refers to nested Data
  friend class ::Data;          // OK: global Data is a friend
  friend class Data;            // OK: nested Data is a friend
  struct Data { /* ... */ };    // Defines nested Data
};

struct Data;                    // OK: Redeclares Data at global scope
struct ::Data;                  // error: cannot introduce a qualified type ([dcl.type.elab])
struct Base::Data;              // error: cannot introduce a qualified type ([dcl.type.elab])
struct Base::Datum;             // error: Datum undefined
struct Base::Data* pBase;       // OK: refers to nested Data
— end example
 ]

6.5.5 Class member access [basic.lookup.classref]

In a class member access expression, if the . or -> token is immediately followed by an identifier followed by a <, the identifier must be looked up to determine whether the < is the beginning of a template argument list ([temp.names]) or a less-than operator.
The identifier is first looked up in the class of the object expression ([class.member.lookup]).
If the identifier is not found, it is then looked up in the context of the entire postfix-expression and shall name a template whose specializations are types.
If the id-expression in a class member access is an unqualified-id, and the type of the object expression is of a class type C, the unqualified-id is looked up in the scope of class C ([class.member.lookup]).
If the unqualified-id is ~type-name, the type-name is looked up in the context of the entire postfix-expression.
If the type T of the object expression is of a class type C, the type-name is also looked up in the scope of class C.
At least one of the lookups shall find a name that refers to cv T.
Example
:
struct A { };

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

void B::f(::A* a) {
  a->~A();                      // OK: lookup in *a finds the injected-class-name
}
— end example
 ]
If the id-expression in a class member access is a qualified-id of the form
class-name-or-namespace-name::...
the class-name-or-namespace-name following the . or -> operator is first looked up in the class of the object expression ([class.member.lookup]) and the name, if found, is used.
Otherwise it is looked up in the context of the entire postfix-expression.
Note
:
See [basic.lookup.qual], which describes the lookup of a name before ​::​, which will only find a type or namespace name.
— end note
 ]
If the qualified-id has the form
::class-name-or-namespace-name::...
the class-name-or-namespace-name is looked up in global scope as a class-name or namespace-name.
If the nested-name-specifier contains a simple-template-id, the names in its template-arguments are looked up in the context in which the entire postfix-expression occurs.
If the id-expression is a conversion-function-id, its conversion-type-id is first looked up in the class of the object expression ([class.member.lookup]) and the name, if found, is used.
Otherwise it is looked up in the context of the entire postfix-expression.
In each of these lookups, only names that denote types or templates whose specializations are types are considered.
Example
:
struct A { };
namespace N {
  struct A {
    void g() { }
    template <class T> operator T();
  };
}

int main() {
  N::A a;
  a.operator A();               // calls N​::​A​::​operator N​::​A
}
— end example
 ]

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

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

6.7 Memory and objects [basic.memobj]

6.7.1 Memory model [intro.memory]

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

6.7.2 Object model [intro.object]

The constructs in a C++ program create, destroy, refer to, access, and manipulate objects.
An object is created by a definition, by a new-expression, by an operation that implicitly creates objects (see below), when implicitly changing the active member of a union, or when a temporary object is created ([conv.rval], [class.temporary]).
An object occupies a region of storage in its period of construction ([class.cdtor]), throughout its lifetime, and in its period of destruction ([class.cdtor]).
Note
:
A function is not an object, regardless of whether or not it occupies storage in the way that objects do.
— end note
 ]
The properties of an object are determined when the object is created.
An object can have a name ([basic.pre]).
An object has a storage duration ([basic.stc]) which influences its lifetime ([basic.life]).
An object has a type ([basic.types]).
Some objects are polymorphic ([class.virtual]); the implementation generates information associated with each such object that makes it possible to determine that object's type during program execution.
For other objects, the interpretation of the values found therein is determined by the type of the expressions ([expr.compound]) used to access them.
Objects can contain other objects, called subobjects.
A subobject can be a member subobject ([class.mem]), a base class subobject ([class.derived]), or an array element.
An object that is not a subobject of any other object is called a complete object.
If an object is created in storage associated with a member subobject or array element e (which may or may not be within its lifetime), the created object is a subobject of e's containing object if:
  • the lifetime of e's containing object has begun and not ended, and
  • the storage for the new object exactly overlays the storage location associated with e, and
  • the new object is of the same type as e (ignoring cv-qualification).
If a complete object is created ([expr.new]) in storage associated with another object e of type “array of N unsigned char” or of type “array of N std​::​byte” ([cstddef.syn]), that array provides storage for the created object if:
  • the lifetime of e has begun and not ended, and
  • the storage for the new object fits entirely within e, and
  • there is no smaller array object that satisfies these constraints.
Note
:
If that portion of the array previously provided storage for another object, the lifetime of that object ends because its storage was reused ([basic.life]).
— end note
 ]
Example
:
template<typename ...T>
struct AlignedUnion {
  alignas(T...) unsigned char data[max(sizeof(T)...)];
};
int f() {
  AlignedUnion<int, char> au;
  int *p = new (au.data) int;           // OK, au.data provides storage
  char *c = new (au.data) char();       // OK, ends lifetime of *p
  char *d = new (au.data + 1) char();
  return *c + *d;                       // OK
}

struct A { unsigned char a[32]; };
struct B { unsigned char b[16]; };
A a;
B *b = new (a.a + 8) B;                 // a.a provides storage for *b
int *p = new (b->b + 4) int;            // b->b provides storage for *p
                                        // a.a does not provide storage for *p (directly),
                                        // but *p is nested within a (see below)
— end example
 ]
An object a is nested within another object b if:
  • a is a subobject of b, or
  • b provides storage for a, or
  • there exists an object c where a is nested within c, and c is nested within b.
For every object x, there is some object called the complete object of x, determined as follows:
  • If x is a complete object, then the complete object of x is itself.
  • Otherwise, the complete object of x is the complete object of the (unique) object that contains x.
If a complete object, a data member, or an array element is of class type, its type is considered the most derived class, to distinguish it from the class type of any base class subobject; an object of a most derived class type or of a non-class type is called a most derived object.
A potentially-overlapping subobject is either:
An object has nonzero size if it
  • is not a potentially-overlapping subobject, or
  • is not of class type, or
  • is of a class type with virtual member functions or virtual base classes, or
  • has subobjects of nonzero size or bit-fields of nonzero length.
Otherwise, if the object is a base class subobject of a standard-layout class type with no non-static data members, it has zero size.
Otherwise, the circumstances under which the object has zero size are implementation-defined.
Unless it is a bit-field, an object with nonzero size shall occupy one or more bytes of storage, including every byte that is occupied in full or in part by any of its subobjects.
An object of trivially copyable or standard-layout type ([basic.types]) shall occupy contiguous bytes of storage.
Unless an object is a bit-field or a subobject of zero size, the address of that object is the address of the first byte it occupies.
Two objects with overlapping lifetimes that are not bit-fields may have the same address if one is nested within the other, or if at least one is a subobject of zero size and they are of different types; otherwise, they have distinct addresses and occupy disjoint bytes of storage.28
Example
:
static const char test1 = 'x';
static const char test2 = 'x';
const bool b = &test1 != &test2;        // always true
— end example
 ]
The address of a non-bit-field subobject of zero size is the address of an unspecified byte of storage occupied by the complete object of that subobject.
Some operations are described as implicitly creating objects within a specified region of storage.
For each operation that is specified as implicitly creating objects, that operation implicitly creates and starts the lifetime of zero or more objects of implicit-lifetime types ([basic.types]) in its specified region of storage if doing so would result in the program having defined behavior.
If no such set of objects would give the program defined behavior, the behavior of the program is undefined.
If multiple such sets of objects would give the program defined behavior, it is unspecified which such set of objects is created.
Note
:
Such operations do not start the lifetimes of subobjects of such objects that are not themselves of implicit-lifetime types.
— end note
 ]
Further, after implicitly creating objects within a specified region of storage, some operations are described as producing a pointer to a suitable created object.
These operations select one of the implicitly-created objects whose address is the address of the start of the region of storage, and produce a pointer value that points to that object, if that value would result in the program having defined behavior.
If no such pointer value would give the program defined behavior, the behavior of the program is undefined.
If multiple such pointer values would give the program defined behavior, it is unspecified which such pointer value is produced.
Example
:
#include <cstdlib>
struct X { int a, b; };
X *make_x() {
  // The call to std​::​malloc implicitly creates an object of type X
  // and its subobjects a and b, and returns a pointer to that X object
  // (or an object that is pointer-interconvertible ([basic.compound]) with it),
  // in order to give the subsequent class member access operations
  // defined behavior.
  X *p = (X*)std::malloc(sizeof(struct X));
  p->a = 1;
  p->b = 2;
  return p;
}
— end example
 ]
An operation that begins the lifetime of an array of char, unsigned char, or std​::​byte implicitly creates objects within the region of storage occupied by the array.
Note
:
The array object provides storage for these objects.
— end note
 ]
Any implicit or explicit invocation of a function named operator new or operator new[] implicitly creates objects in the returned region of storage and returns a pointer to a suitable created object.
Note
:
Some functions in the C++ standard library implicitly create objects ([allocator.traits.members], [c.malloc], [cstring.syn], [bit.cast]).
— end note
 ]
Under the “as-if” rule an implementation is allowed to store two objects at the same machine address or not store an object at all if the program cannot observe the difference ([intro.execution]).

6.7.3 Lifetime [basic.life]

The lifetime of an object or reference is a runtime property of the object or reference.
A variable is said to have vacuous initialization if it is default-initialized and, if it is of class type or a (possibly multi-dimensional) array thereof, that class type has a trivial default constructor.
The lifetime of an object of type T begins when:
  • storage with the proper alignment and size for type T is obtained, and
  • its initialization (if any) is complete (including vacuous initialization) ([dcl.init]),
except that if the object is a union member or subobject thereof, its lifetime only begins if that union member is the initialized member in the union ([dcl.init.aggr], [class.base.init]), or as described in [class.union] and [class.copy.ctor], and except as described in [allocator.members].
The lifetime of an object o of type T ends when:
  • if T is a non-class type, the object is destroyed, or
  • if T is a class type, the destructor call starts, or
  • the storage which the object occupies is released, or is reused by an object that is not nested within o ([intro.object]).
The lifetime of a reference begins when its initialization is complete.
The lifetime of a reference ends as if it were a scalar object requiring storage.
Note
:
[class.base.init] describes the lifetime of base and member subobjects.
— end note
 ]
The properties ascribed to objects and references throughout this document apply for a given object or reference only during its lifetime.
Note
:
In particular, before the lifetime of an object starts and after its lifetime ends there are significant restrictions on the use of the object, as described below, in [class.base.init] and in [class.cdtor].
Also, the behavior of an object under construction and destruction might not be the same as the behavior of an object whose lifetime has started and not ended.
[class.base.init] and [class.cdtor] describe the behavior of an object during its periods of construction and destruction.
— end note
 ]
A program may end the lifetime of any object by reusing the storage which the object occupies or by explicitly calling a destructor or pseudo-destructor ([expr.prim.id.dtor]) for the object.
For an object of a class type, the program is not required to call the destructor explicitly before the storage which the object occupies is reused or released; however, if there is no explicit call to the destructor or if a delete-expression is not used to release the storage, the destructor is not implicitly called and any program that depends on the side effects produced by the destructor has undefined behavior.
Before the lifetime of an object has started but after the storage which the object will occupy has been allocated29 or, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, any pointer that represents the address of the storage location where the object will be or was located may be used but only in limited ways.
For an object under construction or destruction, see [class.cdtor].
Otherwise, such a pointer refers to allocated storage ([basic.stc.dynamic.allocation]), and using the pointer as if the pointer were of type void* is well-defined.
Indirection through such a pointer is permitted but the resulting lvalue may only be used in limited ways, as described below.
The program has undefined behavior if:
  • the object will be or was of a class type with a non-trivial destructor and the pointer is used as the operand of a delete-expression,
  • the pointer is used to access a non-static data member or call a non-static member function of the object, or
  • the pointer is implicitly converted ([conv.ptr]) to a pointer to a virtual base class, or
  • the pointer is used as the operand of a static_­cast ([expr.static.cast]), except when the conversion is to pointer to cv void, or to pointer to cv void and subsequently to pointer to cv char, cv unsigned char, or cv std​::​byte ([cstddef.syn]), or
  • the pointer is used as the operand of a dynamic_­cast ([expr.dynamic.cast]).
Example
:
#include <cstdlib>

struct B {
  virtual void f();
  void mutate();
  virtual ~B();
};

struct D1 : B { void f(); };
struct D2 : B { void f(); };

void B::mutate() {
  new (this) D2;    // reuses storage --- ends the lifetime of *this
  f();              // undefined behavior
  ... = this;       // OK, this points to valid memory
}

void g() {
  void* p = std::malloc(sizeof(D1) + sizeof(D2));
  B* pb = new (p) D1;
  pb->mutate();
  *pb;              // OK: pb points to valid memory
  void* q = pb;     // OK: pb points to valid memory
  pb->f();          // undefined behavior: lifetime of *pb has ended
}
— end example
 ]
Similarly, before the lifetime of an object has started but after the storage which the object will occupy has been allocated or, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, any glvalue that refers to the original object may be used but only in limited ways.
For an object under construction or destruction, see [class.cdtor].
Otherwise, such a glvalue refers to allocated storage ([basic.stc.dynamic.allocation]), and using the properties of the glvalue that do not depend on its value is well-defined.
The program has undefined behavior if:
  • the glvalue is used to access the object, or
  • the glvalue is used to call a non-static member function of the object, or
  • the glvalue is bound to a reference to a virtual base class ([dcl.init.ref]), or
  • the glvalue is used as the operand of a dynamic_­cast ([expr.dynamic.cast]) or as the operand of typeid.
If, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, a new object is created at the storage location which the original object occupied, a pointer that pointed to the original object, a reference that referred to the original object, or the name of the original object will automatically refer to the new object and, once the lifetime of the new object has started, can be used to manipulate the new object, if the original object is transparently replaceable (see below) by the new object.
An object is transparently replaceable by an object if:
  • the storage that occupies exactly overlays the storage that occupied, and
  • and are of the same type (ignoring the top-level cv-qualifiers), and
  • is not a complete const object, and
  • neither nor is a potentially-overlapping subobject ([intro.object]), and
  • either and are both complete objects, or and are direct subobjects of objects and , respectively, and is transparently replaceable by .
Example
:
struct C {
  int i;
  void f();
  const C& operator=( const C& );
};

const C& C::operator=( const C& other) {
  if ( this != &other ) {
    this->~C();                 // lifetime of *this ends
    new (this) C(other);        // new object of type C created
    f();                        // well-defined
  }
  return *this;
}

C c1;
C c2;
c1 = c2;                        // well-defined
c1.f();                         // well-defined; c1 refers to a new object of type C
— end example
 ]
Note
:
If these conditions are not met, a pointer to the new object can be obtained from a pointer that represents the address of its storage by calling std​::​launder ([ptr.launder]).
— end note
 ]
If a program ends the lifetime of an object of type T with static, thread, or automatic storage duration and if T has a non-trivial destructor,30 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.
Example
:
class T { };
struct B {
   ~B();
};

void h() {
   B b;
   new (&b) T;
}                               // undefined behavior at block exit
— end example
 ]
Creating a new object within the storage that a const complete object with static, thread, or automatic storage duration occupies, or within the storage that such a const object used to occupy before its lifetime ended, results in undefined behavior.
Example
:
struct B {
  B();
  ~B();
};

const B b;

void h() {
  b.~B();
  new (const_cast<B*>(&b)) const B;     // undefined behavior
}
— end example
 ]
In this subclause, “before” and “after” refer to the “happens before” relation ([intro.multithread]).
Note
:
Therefore, undefined behavior results if an object that is being constructed in one thread is referenced from another thread without adequate synchronization.
— end note
 ]
For example, before the construction of a global object that is initialized via a user-provided constructor ([class.cdtor]).
That is, an object for which a destructor will be called implicitly—upon exit from the block for an object with automatic storage duration, upon exit from the thread for an object with thread storage duration, or upon exit from the program for an object with static storage duration.

6.7.4 Indeterminate values [basic.indet]

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

6.7.5 Storage duration [basic.stc]

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

6.7.5.1 Static storage duration [basic.stc.static]

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

6.7.5.2 Thread storage duration [basic.stc.thread]

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

6.7.5.3 Automatic storage duration [basic.stc.auto]

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

6.7.5.4 Dynamic storage duration [basic.stc.dynamic]

Objects can be created dynamically during program execution, using new-expressions, and destroyed using delete-expressions.
A C++ implementation provides access to, and management of, dynamic storage via the global allocation functions operator new and operator new[] and the global deallocation functions operator delete and operator delete[].
Note
:
The non-allocating forms described in [new.delete.placement] do not perform allocation or deallocation.
— end note
 ]
The library provides default definitions for the global allocation and deallocation functions.
Some global allocation and deallocation functions are replaceable ([new.delete]).
A C++ program shall provide at most one definition of a replaceable allocation or deallocation function.
Any such function definition replaces the default version provided in the library ([replacement.functions]).
The following allocation and deallocation functions ([support.dynamic]) are implicitly declared in global scope in each translation unit of a program.
[[nodiscard]] void* operator new(std::size_t);
[[nodiscard]] void* operator new(std::size_t, std::align_val_t);

void operator delete(void*) noexcept;
void operator delete(void*, std::size_t) noexcept;
void operator delete(void*, std::align_val_t) noexcept;
void operator delete(void*, std::size_t, std::align_val_t) noexcept;

[[nodiscard]] void* operator new[](std::size_t);
[[nodiscard]] void* operator new[](std::size_t, std::align_val_t);

void operator delete[](void*) noexcept;
void operator delete[](void*, std::size_t) noexcept;
void operator delete[](void*, std::align_val_t) noexcept;
void operator delete[](void*, std::size_t, std::align_val_t) noexcept;
These implicit declarations introduce only the function names operator new, operator new[], operator delete, and operator delete[].
Note
:
The implicit declarations do not introduce the names std, std​::​size_­t, std​::​align_­val_­t, or any other names that the library uses to declare these names.
Thus, a new-expression, delete-expression, or function call that refers to one of these functions without importing or including the header <new> ([new.syn]) is well-formed.
However, referring to std or std​::​size_­t or std​::​align_­val_­t is ill-formed unless the name has been declared by importing or including the appropriate header.
— end note
 ]
Allocation and/or deallocation functions may also be declared and defined for any class ([class.free]).
If the behavior of an allocation or deallocation function does not satisfy the semantic constraints specified in [basic.stc.dynamic.allocation] and [basic.stc.dynamic.deallocation], the behavior is undefined.

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

6.7.5.4.2 Deallocation functions [basic.stc.dynamic.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.
A deallocation function is a destroying operator delete if it has at least two parameters and its second parameter is of type std​::​destroying_­delete_­t.
A destroying operator delete shall be a class member function named operator delete.
Note
:
Array deletion cannot use a destroying operator delete.
— end note
 ]
Each deallocation function shall return void.
If the function is a destroying operator delete declared in class type C, the type of its first parameter shall be C*; otherwise, the type of its first parameter shall be void*.
A deallocation function may have more than one parameter.
A usual deallocation function is a deallocation function whose parameters after the first are
  • optionally, a parameter of type std​::​destroying_­delete_­t, then
  • optionally, a parameter of type std​::​size_­t33, then
  • optionally, a parameter of type std​::​align_­val_­t.
A destroying operator delete shall be a usual deallocation function.
A deallocation function may be an instance of a function template.
Neither the first parameter nor the return type shall depend on a template parameter.
A deallocation function template shall have two or more function parameters.
A template instance is never a usual deallocation function, regardless of its signature.
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.
If the argument given to a deallocation function in the standard library is a pointer that is not the null pointer value ([basic.compound]), the deallocation function shall deallocate the storage referenced by the pointer, ending the duration of the region of storage.
The global operator delete(void*, std​::​size_­t) precludes use of an allocation function void operator new(std​::​size_­t, std​::​size_­t) as a placement allocation function ([diff.cpp11.basic]).

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

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

6.7.5.5 Duration of subobjects [basic.stc.inherit]

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

6.7.6 Alignment [basic.align]

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

6.7.7 Temporary objects [class.temporary]

Temporary objects are created
  • when a prvalue is converted to an xvalue ([conv.rval]),
  • when needed by the implementation to pass or return an object of trivially-copyable type (see below), and
  • when throwing an exception ([except.throw]).
    Note
    : The lifetime of exception objects is described in [except.throw]. — end note
     ]
Even when the creation of the temporary object is unevaluated ([expr.prop]), all the semantic restrictions shall be respected as if the temporary object had been created and later destroyed.
Note
:
This includes accessibility ([class.access]) and whether it is deleted, for the constructor selected and for the destructor.
However, in the special case of the operand of a decltype-specifier ([expr.call]), no temporary is introduced, so the foregoing does not apply to such a prvalue.
— end note
 ]
The materialization of a temporary object is generally delayed as long as possible in order to avoid creating unnecessary temporary objects.
Note
:
Temporary objects are materialized:
— end note
 ]
Example
:
Consider the following code:
class X {
public:
  X(int);
  X(const X&);
  X& operator=(const X&);
  ~X();
};

class Y {
public:
  Y(int);
  Y(Y&&);
  ~Y();
};

X f(X);
Y g(Y);

void h() {
  X a(1);
  X b = f(X(2));
  Y c = g(Y(3));
  a = f(a);
}
X(2) is constructed in the space used to hold f()'s argument and Y(3) is constructed in the space used to hold g()'s argument.
Likewise, f()'s result is constructed directly in b and g()'s result is constructed directly in c.
On the other hand, the expression a = f(a) requires a temporary for the result of f(a), which is materialized so that the reference parameter of X​::​operator=(const X&) can bind to it.
— end example
 ]
When an object of class type X is passed to or returned from a function, if X has at least one eligible copy or move constructor ([special]), each such constructor is trivial, and the destructor of X is either trivial or deleted, implementations are permitted to create a temporary object to hold the function parameter or result object.
The temporary object is constructed from the function argument or return value, respectively, and the function's parameter or return object is initialized as if by using the eligible trivial constructor to copy the temporary (even if that constructor is inaccessible or would not be selected by overload resolution to perform a copy or move of the object).
Note
:
This latitude is granted to allow objects of class type to be passed to or returned from functions in registers.
— end note
 ]
When an implementation introduces a temporary object of a class that has a non-trivial constructor ([class.default.ctor], [class.copy.ctor]), it shall ensure that a constructor is called for the temporary object.
Similarly, the destructor shall be called for a temporary with a non-trivial destructor ([class.dtor]).
Temporary objects are destroyed as the last step in evaluating the full-expression ([intro.execution]) that (lexically) contains the point where they were created.
This is true even if that evaluation ends in throwing an exception.
The value computations and side effects of destroying a temporary object are associated only with the full-expression, not with any specific subexpression.
There are three contexts in which temporaries are destroyed at a different point than the end of the full-expression.
The first context is when a default constructor is called to initialize an element of an array with no corresponding initializer ([dcl.init]).
The second context is when a copy constructor is called to copy an element of an array while the entire array is copied ([expr.prim.lambda.capture], [class.copy.ctor]).
In either case, if the constructor has one or more default arguments, the destruction of every temporary created in a default argument is sequenced before the construction of the next array element, if any.
The third context is when a reference is bound to a temporary object.35
The temporary object to which the reference is bound or the temporary object that is the complete object of a subobject to which the reference is bound persists for the lifetime of the reference if the glvalue to which the reference is bound was obtained through one of the following:
  • a temporary materialization conversion ([conv.rval]),
  • ( expression ), where expression is one of these expressions,
  • subscripting ([expr.sub]) of an array operand, where that operand is one of these expressions,
  • a class member access ([expr.ref]) using the . operator where the left operand is one of these expressions and the right operand designates a non-static data member of non-reference type,
  • a pointer-to-member operation ([expr.mptr.oper]) using the .* operator where the left operand is one of these expressions and the right operand is a pointer to data member of non-reference type,
  • a converting, without a user-defined conversion, a glvalue operand that is one of these expressions to a glvalue that refers to the object designated by the operand, or to its complete object or a subobject thereof,
  • a conditional expression ([expr.cond]) that is a glvalue where the second or third operand is one of these expressions, or
  • a comma expression ([expr.comma]) that is a glvalue where the right operand is one of these expressions.
Example
:
template<typename T> using id = T;

int i = 1;
int&& a = id<int[3]>{1, 2, 3}[i];           // temporary array has same lifetime as a
const int& b = static_cast<const int&>(0);  // temporary int has same lifetime as b
int&& c = cond ? id<int[3]>{1, 2, 3}[i] : static_cast<int&&>(0);
                                            // exactly one of the two temporaries is lifetime-extended
— end example
 ]
Note
:
An explicit type conversion ([expr.type.conv], [expr.cast]) is interpreted as a sequence of elementary casts, covered above.
Example
:
const int& x = (const int&)1;   // temporary for value 1 has same lifetime as x
— end example
 ]
— end note
 ]
Note
:
If a temporary object has a reference member initialized by another temporary object, lifetime extension applies recursively to such a member's initializer.
Example
:
struct S {
  const int& m;
};
const S& s = S{1};              // both S and int temporaries have lifetime of s
— end example
 ]
— end note
 ]
The exceptions to this lifetime rule are:
  • A temporary object bound to a reference parameter in a function call ([expr.call]) persists until the completion of the full-expression containing the call.
  • A temporary object bound to a reference element of an aggregate of class type initialized from a parenthesized expression-list ([dcl.init]) persists until the completion of the full-expression containing the expression-list.
  • The lifetime of a temporary bound to the returned value in a function return statement ([stmt.return]) is not extended; the temporary is destroyed at the end of the full-expression in the return statement.
  • A temporary bound to a reference in a new-initializer persists until the completion of the full-expression containing the new-initializer.
    Note
    : This may introduce a dangling reference. — end note
     ]
    Example
    :
    struct S { int mi; const std::pair<int,int>& mp; };
    S a { 1, {2,3} };
    S* p = new S{ 1, {2,3} };       // creates dangling reference
    
    — end example
     ]
The destruction of a temporary whose lifetime is not extended by being bound to a reference is sequenced before the destruction of every temporary which is constructed earlier in the same full-expression.
If the lifetime of two or more temporaries to which references are bound ends at the same point, these temporaries are destroyed at that point in the reverse order of the completion of their construction.
In addition, the destruction of temporaries bound to references shall take into account the ordering of destruction of objects with static, thread, or automatic storage duration ([basic.stc.static], [basic.stc.thread], [basic.stc.auto]); that is, if obj1 is an object with the same storage duration as the temporary and created before the temporary is created the temporary shall be destroyed before obj1 is destroyed; if obj2 is an object with the same storage duration as the temporary and created after the temporary is created the temporary shall be destroyed after obj2 is destroyed.
Example
:
struct S {
  S();
  S(int);
  friend S operator+(const S&, const S&);
  ~S();
};
S obj1;
const S& cr = S(16)+S(23);
S obj2;
The expression S(16) + S(23) creates three temporaries: a first temporary T1 to hold the result of the expression S(16), a second temporary T2 to hold the result of the expression S(23), and a third temporary T3 to hold the result of the addition of these two expressions.
The temporary T3 is then bound to the reference cr.
It is unspecified whether T1 or T2 is created first.
On an implementation where T1 is created before T2, T2 shall be destroyed before T1.
The temporaries T1 and T2 are bound to the reference parameters of operator+; these temporaries are destroyed at the end of the full-expression containing the call to operator+.
The temporary T3 bound to the reference cr is destroyed at the end of cr's lifetime, that is, at the end of the program.
In addition, the order in which T3 is destroyed takes into account the destruction order of other objects with static storage duration.
That is, because obj1 is constructed before T3, and T3 is constructed before obj2, obj2 shall be destroyed before T3, and T3 shall be destroyed before obj1.
— end example
 ]
The same rules apply to initialization of an initializer_­list object ([dcl.init.list]) with its underlying temporary array.

6.8 Types [basic.types]

Note
:
[basic.types] and the subclauses thereof impose requirements on implementations regarding the representation of types.
There are two kinds of types: fundamental types and compound types.
Types describe objects, references, or functions.
— end note
 ]
For any object (other than a potentially-overlapping subobject) of trivially copyable type T, whether or not the object holds a valid value of type T, the underlying bytes ([intro.memory]) making up the object can be copied into an array of char, unsigned char, or std​::​byte ([cstddef.syn]).36
If the content of that array is copied back into the object, the object shall subsequently hold its original value.
Example
:
constexpr std::size_t N = sizeof(T);
char buf[N];
T obj;                          // obj initialized to its original value
std::memcpy(buf, &obj, N);      // between these two calls to std​::​memcpy, obj might be modified
std::memcpy(&obj, buf, N);      // at this point, each subobject of obj of scalar type holds its original value
— end example
 ]
For any trivially copyable type T, if two pointers to T point to distinct T objects obj1 and obj2, where neither obj1 nor obj2 is a potentially-overlapping subobject, if the underlying bytes ([intro.memory]) making up obj1 are copied into obj2,37 obj2 shall subsequently hold the same value as obj1.
Example
:
T* t1p;
T* t2p;
    // provided that t2p points to an initialized object ...
std::memcpy(t1p, t2p, sizeof(T));
    // at this point, every subobject of trivially copyable type in *t1p contains
    // the same value as the corresponding subobject in *t2p
— end example
 ]
The object representation of an object of type T is the sequence of N unsigned char objects taken up by the object of type T, where N equals sizeof(T).
The value representation of an object of type T is the set of bits that participate in representing a value of type T.
Bits in the object representation that are not part of the value representation are padding bits.
For trivially copyable types, the value representation is a set of bits in the object representation that determines a value, which is one discrete element of an implementation-defined set of values.38
A class that has been declared but not defined, an enumeration type in certain contexts ([dcl.enum]), or an array of unknown bound or of incomplete element type, is an incompletely-defined object type.39
Incompletely-defined object types and cv void are incomplete types ([basic.fundamental]).
Objects shall not be defined to have an incomplete type.
A class type (such as “class X”) might be incomplete at one point in a translation unit and complete later on; the type “class X” is the same type at both points.
The declared type of an array object 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 T” and “array of N T”) are different types.
The type of a pointer to array of unknown bound, or of a type defined by a typedef declaration to be an array of unknown bound, cannot be completed.
Example
:
class X;                        // X is an incomplete type
extern X* xp;                   // xp is a pointer to an incomplete type
extern int arr[];               // the type of arr is incomplete
typedef int UNKA[];             // UNKA is an incomplete type
UNKA* arrp;                     // arrp is a pointer to an incomplete type
UNKA** arrpp;

void foo() {
  xp++;                         // error: X is incomplete
  arrp++;                       // error: incomplete type
  arrpp++;                      // OK: sizeof UNKA* is known
}

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

X x;
void bar() {
  xp = &x;                      // OK; type is “pointer to X
  arrp = &arr;                  // error: different types
  xp++;                         // OK:  X is complete
  arrp++;                       // error: UNKA can't be completed
}
— end example
 ]
Note
:
The rules for declarations and expressions describe in which contexts incomplete types are prohibited.
— end note
 ]
An object type is a (possibly cv-qualified) type that is not a function type, not a reference type, and not cv void.
Arithmetic types ([basic.fundamental]), enumeration types, pointer types, pointer-to-member types ([basic.compound]), std​::​nullptr_­t, and cv-qualified versions of these types are collectively called scalar types.
Scalar types, trivially copyable class types ([class.prop]), arrays of such types, and cv-qualified versions of these types are collectively called trivially copyable types.
Scalar types, trivial class types ([class.prop]), arrays of such types and cv-qualified versions of these types are collectively called trivial types.
Scalar types, standard-layout class types ([class.prop]), arrays of such types and cv-qualified versions of these types are collectively called standard-layout types.
Scalar types, implicit-lifetime class types ([class.prop]), array types, and cv-qualified versions of these types are collectively called implicit-lifetime types.
A type is a literal type if it is:
  • cv void; or
  • a scalar type; or
  • a reference type; or
  • an array of literal type; or
  • a possibly cv-qualified class type that has all of the following properties:
    • it has a constexpr destructor ([dcl.constexpr]),
    • it is either a closure type ([expr.prim.lambda.closure]), an aggregate type ([dcl.init.aggr]), or has at least one constexpr constructor or constructor template (possibly inherited from a base class) that is not a copy or move constructor,
    • if it is a union, at least one of its non-static data members is of non-volatile literal type, and
    • if it is not a union, all of its non-static data members and base classes are of non-volatile literal types.
Note
:
A literal type is one for which it might be possible to create an object within a constant expression.
It is not a guarantee that it is possible to create such an object, nor is it a guarantee that any object of that type will be usable in a constant expression.
— end note
 ]
Two types cv1 T1 and cv2 T2 are layout-compatible types if T1 and T2 are the same type, layout-compatible enumerations, or layout-compatible standard-layout class types.
By using, for example, the library functions ([headers]) std​::​memcpy or std​::​memmove.
By using, for example, the library functions ([headers]) std​::​memcpy or std​::​memmove.
The intent is that the memory model of C++ is compatible with that of ISO/IEC 9899 Programming Language C.
The size and layout of an instance of an incompletely-defined object type is unknown.

6.8.1 Fundamental types [basic.fundamental]

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

6.8.2 Compound types [basic.compound]

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

6.8.3 CV-qualifiers [basic.type.qualifier]

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