1 Scope [intro.scope]

1
#
This document specifies requirements for implementations of the C++ programming language.
The first such requirement is that an implementation implements the language, so this document also defines C++.
Other requirements and relaxations of the first requirement appear at various places within this document.
2
#
C++ is a general purpose programming language based on the C programming language as described in ISO/IEC 9899:2018.
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]

1
#
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.
  • (1.1)
    ISO/IEC 2382, Information technology — Vocabulary
  • (1.2)
    ISO 8601-1:2019, Date and time — Representations for information interchange — Part 1: Basic rules
  • (1.3)
    ISO/IEC 9899:2018, Information technology — Programming languages — C
  • (1.4)
    ISO/IEC/IEEE 9945:2009, Information Technology — Portable Operating System Interface (POSIX®)1 Base Specifications, Issue 7
  • (1.5)
    ISO/IEC/IEEE 9945:2009/Cor 1:2013, Information Technology — Portable Operating System Interface (POSIX®) Base Specifications, Issue 7 — Technical Corrigendum 1
  • (1.6)
    ISO/IEC/IEEE 9945:2009/Cor 2:2017, Information Technology — Portable Operating System Interface (POSIX®) Base Specifications, Issue 7 — Technical Corrigendum 2
  • (1.7)
    ISO/IEC 60559:2020, Information technology — Microprocessor Systems — Floating-Point arithmetic
  • (1.8)
    ISO 80000-2:2019, Quantities and units — Part 2: Mathematics
  • (1.9)
    Ecma International, ECMAScript2 Language Specification, Standard Ecma-262, third edition, 1999.
  • (1.10)
    The Unicode Consortium.
    The Unicode Standard.
1)1)
POSIX® is a registered trademark of the Institute of Electrical and Electronic Engineers, Inc.
This information is given for the convenience of users of this document and does not constitute an endorsement by ISO or IEC of this product.
2)2)
ECMAScript® is a registered trademark of Ecma International.
This information is given for the convenience of users of this document and does not constitute an endorsement by ISO or IEC of this product.

3 Terms and definitions [intro.defs]

1
#
For the purposes of this document, the terms and definitions given in ISO/IEC 2382, ISO 80000-2:2019, and the following apply.
2
#
ISO and IEC maintain terminology databases for use in standardization at the following addresses:

3.1[defns.access]access

⟨execution-time action⟩ read or modify the value of an object
[Note 1: 
Only glvalues of scalar type can be used to access objects.
Reads of scalar objects are described in [conv.lval] and modifications of scalar objects are described in [expr.ass], [expr.post.incr], and [expr.pre.incr].
Attempts to read or modify an object of class type typically invoke a constructor or assignment operator; 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

3.3[defns.argument.macro]argument

⟨function-like macro⟩ sequence of preprocessing tokens in the comma-separated list bounded by the parentheses

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

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

3.8[defns.c.lib]C standard library

library described in ISO/IEC 9899:2018, Clause 7
[Note 1: 
With the qualifications noted in [support] through [exec] and in [diff.library], the C standard library is a subset of the C++ standard library.
— end note]

3.9[defns.character]character

⟨library⟩ object which, when treated sequentially, can represent text
[Note 1: 
The term does not mean only char, char8_t, char16_t, char32_t, and wchar_t objects ([basic.fundamental]), but any value that can be represented by a type that provides the definitions specified in [strings], [localization], [input.output], or [re].
— end note]

3.10[defns.character.container]character container type

⟨library⟩ class or a type used to represent a character ([defns.character])
[Note 1: 
It is used for one of the template parameters of char_traits and the class templates which use that, such as the string, iostream, and regular expression class templates.
— end note]

3.11[defns.regex.collating.element]collating element

sequence of one or more characters ([defns.character]) within the current locale that collate as if they were a single character

3.12[defns.component]component

⟨library⟩ group of library entities directly related as members, parameters ([defns.parameter]), or return types
[Note 1: 
For example, the class template basic_string and the non-member function templates that operate on strings are referred to as the string component.
— end note]

3.13[defns.cond.supp]conditionally-supported

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

3.14[defns.const.subexpr]constant subexpression

expression whose evaluation as subexpression of a conditional-expression CE would not prevent CE from being a core constant expression

3.15[defns.deadlock]deadlock

⟨library⟩ situation wherein one or more threads are unable to continue execution because each is blocked ([defns.block]) waiting for one or more of the others to satisfy some condition

3.16[defns.default.behavior.impl]default behavior

⟨library implementation⟩ specific behavior provided by the implementation, within the scope of the required behavior ([defns.required.behavior])

3.17[defns.diagnostic]diagnostic message

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

3.18[defns.dynamic.type]dynamic type

⟨glvalue⟩ type of the most derived object to which the glvalue refers
[Example 1: 
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.19[defns.dynamic.type.prvalue]dynamic type

⟨prvalue⟩ static type ([defns.static.type]) of the prvalue expression

3.20[defns.erroneous]erroneous behavior

well-defined behavior that the implementation is recommended to diagnose
[Note 1: 
Erroneous behavior is always the consequence of incorrect program code.
Implementations are allowed, but not required, to diagnose it ([intro.compliance.general]).
Evaluation of a constant expression ([expr.const]) never exhibits behavior specified as erroneous in [intro] through [cpp].
— end note]

3.21[defns.expression.equivalent]expression-equivalent

⟨library⟩ expressions that all have the same effects, either are all potentially-throwing or are all not potentially-throwing, and either are all constant subexpressions ([defns.const.subexpr]) or are all not constant subexpressions
[Example 1: 
For a value x of type int and a function f that accepts integer arguments, the expressions f(x + 2), f(2 + x), and f(1 + x + 1) are expression-equivalent.
— end example]

3.22[defns.regex.finite.state.machine]finite state machine

⟨regular expression⟩ unspecified data structure that is used to represent a regular expression ([defns.regex.regular.expression]), and which permits efficient matches against the regular expression to be obtained

3.23[defns.regex.format.specifier]format specifier

⟨regular expression⟩ sequence of one or more characters ([defns.character]) that is expected to be replaced with some part of a regular expression ([defns.regex.regular.expression]) match

3.24[defns.handler]handler function

⟨library⟩ non-reserved function whose definition may be provided by a C++ program
[Note 1: 
A C++ program may designate a handler function at various points in its execution by supplying a pointer to the function when calling any of the library functions that install handler functions (see [support]).
— end note]

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

program that is not well-formed

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

behavior, for a well-formed program ([defns.well.formed]) construct and correct data, that depends on the implementation and that each implementation documents

3.27[defns.order.ptr]implementation-defined strict total order over pointers

⟨library⟩ implementation-defined strict total ordering over all pointer values such that the ordering is consistent with the partial order imposed by the built-in operators <, >, <=, >=, and <=>

3.28[defns.impl.limits]implementation limit

restriction imposed upon programs by the implementation

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

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

3.30[defns.regex.matched]matched

⟨regular expression⟩ condition when a sequence of zero or more characters ([defns.character]) correspond to a sequence of characters defined by the pattern

3.31[defns.modifier]modifier function

⟨library⟩ class member function other than a constructor, assignment operator, or destructor that alters the state of an object of the class

3.32[defns.move.assign]move assignment

⟨library⟩ assignment of an rvalue of some object type to a modifiable lvalue of the same type

3.33[defns.move.constr]move construction

⟨library⟩ direct-initialization of an object of some type with an rvalue of the same type

3.34[defns.nonconst.libcall]non-constant library call

invocation of a library function that, as part of evaluating any expression E, prevents E from being a core constant expression

3.35[defns.ntcts]NTCTS

⟨library⟩ sequence of values that have character ([defns.character]) type that precede the terminating null character type value charT()

3.36[defns.observer]observer function

⟨library⟩ class member function that accesses the state of an object of the class but does not alter that state
[Note 1: 
Observer functions are specified as const member functions.
— end note]

3.37[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.38[defns.parameter.macro]parameter

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

3.39[defns.parameter.templ]parameter

⟨template⟩ member of a template-parameter-list

3.40[defns.regex.primary.equivalence.class]primary equivalence class

⟨regular expression⟩ set of one or more characters ([defns.character]) which share the same primary sort key: that is the sort key weighting that depends only upon character shape, and not accents, case, or locale specific tailorings

3.41[defns.prog.def.spec]program-defined specialization

⟨library⟩ explicit template specialization or partial specialization that is not part of the C++ standard library and not defined by the implementation

3.42[defns.prog.def.type]program-defined type

⟨library⟩ non-closure class type or enumeration type that is not part of the C++ standard library and not defined by the implementation, or a closure type of a non-implementation-provided lambda expression, or an instantiation of a program-defined specialization ([defns.prog.def.spec])
[Note 1: 
Types defined by the implementation include extensions ([intro.compliance]) and internal types used by the library.
— end note]

3.43[defns.projection]projection

⟨library⟩ transformation that an algorithm applies before inspecting the values of elements
[Example 1: 
std::pair<int, std::string_view> pairs[] = {{2, "foo"}, {1, "bar"}, {0, "baz"}}; std::ranges::sort(pairs, std::ranges::less{}, [](auto const& p) { return p.first; }); sorts the pairs in increasing order of their first members: {{0, "baz"}, {1, "bar"}, {2, "foo"}}
— end example]

3.44[defns.referenceable]referenceable type

type that is either an object type, a function type that does not have cv-qualifiers or a ref-qualifier, or a reference type
[Note 1: 
The term describes a type to which a reference can be created, including reference types.
— end note]

3.45[defns.regex.regular.expression]regular expression

pattern that selects specific strings from a set of character ([defns.character]) strings

3.46[defns.replacement]replacement function

⟨library⟩ non-reserved function whose definition is provided by a C++ program
[Note 1: 
Only one definition for such a function is in effect for the duration of the program's execution, as the result of creating the program ([lex.phases]) and resolving the definitions of all translation units ([basic.link]).
— end note]

3.47[defns.required.behavior]required behavior

⟨library⟩ description of replacement function ([defns.replacement]) and handler function ([defns.handler]) semantics applicable to both the behavior provided by the implementation and the behavior of any such function definition in the program
[Note 1: 
If such a function defined in a C++ program fails to meet the required behavior when it executes, the behavior is undefined.
— end note]

3.48[defns.reserved.function]reserved function

⟨library⟩ function, specified as part of the C++ standard library, that is defined by the implementation
[Note 1: 
If a C++ program provides a definition for any reserved function, the results are undefined.
— end note]

3.49[defns.signature]signature

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

3.50[defns.signature.friend]signature

⟨non-template friend function with trailing requires-clause⟩ name, parameter-type-list, enclosing class, and trailing requires-clause

3.51[defns.signature.templ]signature

⟨function template⟩ name, parameter-type-list, enclosing namespace, return type, signature ([defns.signature.template.head]) of the template-head, and trailing requires-clause (if any)

3.52[defns.signature.templ.friend]signature

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

3.53[defns.signature.spec]signature

⟨function template specialization⟩ signature ([defns.signature.templ]) of the template of which it is a specialization and its template arguments ([defns.argument.templ]) (whether explicitly specified or deduced)

3.54[defns.signature.member]signature

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

3.55[defns.signature.member.templ]signature

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

3.56[defns.signature.member.spec]signature

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

3.57[defns.signature.template.head]signature

⟨template-head⟩ template parameter ([defns.parameter.templ]) list, excluding template parameter names and default arguments ([defns.argument.templ]), and requires-clause (if any)

3.58[defns.stable]stable algorithm

⟨library⟩ algorithm that preserves, as appropriate to the particular algorithm, the order of elements
[Note 1: 
Requirements for stable algorithms are given in [algorithm.stable].
— end note]

3.59[defns.static.type]static type

type of an expression resulting from analysis of the program without considering execution semantics
[Note 1: 
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.60[defns.regex.subexpression]sub-expression

⟨regular expression⟩ subset of a regular expression ([defns.regex.regular.expression]) that has been marked by parentheses

3.61[defns.traits]traits class

⟨library⟩ class that encapsulates a set of types and functions necessary for class templates and function templates to manipulate objects of types for which they are instantiated

3.62[defns.unblock]unblock

satisfy a condition that one or more blocked ([defns.block]) threads of execution are waiting for

3.63[defns.undefined]undefined behavior

behavior for which this document imposes no requirements
[Note 1: 
Undefined behavior may be expected when this document omits any explicit definition of behavior or when a program uses an incorrect construct or invalid 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 ([defns.diagnostic])), to terminating a translation or execution (with the issuance of a diagnostic message).
Many incorrect program constructs do not engender undefined behavior; they are required to be diagnosed.
Evaluation of a constant expression ([expr.const]) never exhibits behavior explicitly specified as undefined in [intro] through [cpp].
— end note]

3.64[defns.unspecified]unspecified behavior

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

3.65[defns.valid]valid but unspecified state

⟨library⟩ value of an object that is not specified except that the object's invariants are met and operations on the object behave as specified for its type
[Example 1: 
If an object x of type std​::​vector<int> is in a valid but unspecified state, x.empty() can be called unconditionally, and x.front() can be called only if x.empty() returns false.
— end example]

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

C++ program constructed according to the syntax and semantic rules

4 General principles [intro]

4.1 Implementation compliance [intro.compliance]

4.1.1 General [intro.compliance.general]

1
#
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”.
2
#
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:
  • (2.1)
    If a program contains no violations of the rules in [lex] through [exec] as well as those specified in [depr], a conforming implementation shall accept and correctly execute3 that program, except when the implementation's limitations (see below) are exceeded.
  • (2.2)
    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.
  • (2.3)
    Otherwise, if a program contains
    • (2.3.1)
      a violation of any diagnosable rule,
    • (2.3.2)
      a preprocessing translation unit with a #warning preprocessing directive ([cpp.error]), or
    • (2.3.3)
      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.
[Note 1: 
During template argument deduction and substitution, certain constructs that in other contexts require a diagnostic are treated differently; see [temp.deduct].
— end note]
Furthermore, a conforming implementation shall not accept
3
#
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.
4
#
For functions, function templates, objects, and values, the library Clauses specify declarations.
Implementations shall supply definitions consistent with the descriptions in the library Clauses.
5
#
A C++ translation unit ([lex.phases]) obtains access to the names defined in the library by including the appropriate standard library header or importing the appropriate standard library named header unit ([using.headers]).
6
#
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]).
7
#
Two kinds of implementations are defined: a hosted implementation and a freestanding implementation.
A freestanding implementation is one in which execution may take place without the benefit of an operating system.
A hosted implementation supports all the facilities described in this document, while a freestanding implementation supports the entire C++ language described in [lex] through [cpp] and the subset of the library facilities described in [compliance].
8
#
An implementation is encouraged to document its limitations in the size or complexity of the programs it can successfully process, if possible and where known.
[implimits] lists some quantities that can be subject to limitations and a potential minimum supported value for each quantity.
9
#
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.
10
#
Each implementation shall include documentation that identifies all conditionally-supported constructs that it does not support and defines all locale-specific characteristics.4
3)3)
“Correct execution” can include undefined behavior and erroneous behavior, depending on the data being processed; see [intro.defs] and [intro.execution].
4)4)
This documentation also defines implementation-defined behavior; see [intro.abstract].

4.1.2 Abstract machine [intro.abstract]

1
#
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.5
2
#
Certain aspects and operations of the abstract machine are described in this document as implementation-defined behavior (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.6
Such documentation shall define the instance of the abstract machine that corresponds to that implementation (referred to as the “corresponding instance” below).
3
#
Certain other aspects and operations of the abstract machine are described in this document as unspecified behavior (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.
4
#
Certain other operations are described in this document as undefined behavior (for example, the effect of attempting to modify a const object).
[Note 1: 
This document imposes no requirements on the behavior of programs that contain undefined behavior.
— end note]
5
#
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).
If the execution contains an operation specified as having erroneous behavior, the implementation is permitted to issue a diagnostic and is permitted to terminate the execution at an unspecified time after that operation.
6
#
Recommended practice: An implementation should issue a diagnostic when such an operation is executed.
[Note 2: 
An implementation can issue a diagnostic if it can determine that erroneous behavior is reachable under an implementation-specific set of assumptions about the program behavior, which can result in false positives.
— end note]
7
#
The least requirements on a conforming implementation are:
  • (7.1)
    Accesses through volatile glvalues are evaluated strictly according to the rules of the abstract machine.
  • (7.2)
    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.
  • (7.3)
    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 3: 
More stringent correspondences between abstract and actual semantics can be defined by each implementation.
— end note]
5)5)
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.
6)6)
This documentation also includes conditionally-supported constructs and locale-specific behavior.

4.2 Structure of this document [intro.structure]

1
#
[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.
2
#
[support] through [exec] 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].
3
#
[implimits] recommends lower bounds on the capacity of conforming implementations.
4
#
[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.

4.3 Syntax notation [syntax]

1
#
In the syntax notation used in this document, syntactic categories are indicated by italic, sans-serif 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.
2
#
Names for syntactic categories have generally been chosen according to the following rules:
  • (2.1)
    X-name is a use of an identifier in a context that determines its meaning (e.g., class-name, typedef-name).
  • (2.2)
    X-id is an identifier with no context-dependent meaning (e.g., qualified-id).
  • (2.3)
    X-seq is one or more X's without intervening delimiters (e.g., declaration-seq is a sequence of declarations).
  • (2.4)
    X-list is one or more X's separated by intervening commas (e.g., identifier-list is a sequence of identifiers separated by commas).

5 Lexical conventions [lex]

5.1 Separate translation [lex.separate]

1
#
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 ([cpp.cond]) preprocessing directives, as modified by the implementation-defined behavior of any conditionally-supported-directives ([cpp.pre]) and pragmas ([cpp.pragma]), if any, is called a preprocessing translation unit.
[Note 1: 
A C++ program need not all be translated at the same time.
— end note]
2
#
[Note 2: 
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]

1
#
The precedence among the syntax rules of translation is specified by the following phases.7
1.
An implementation shall support input files that are a sequence of UTF-8 code units (UTF-8 files).
It may also support an implementation-defined set of other kinds of input files, and, if so, the kind of an input file is determined in an implementation-defined manner that includes a means of designating input files as UTF-8 files, independent of their content.
[Note 1: 
In other words, recognizing the U+feff byte order mark is not sufficient.
— end note]
If an input file is determined to be a UTF-8 file, then it shall be a well-formed UTF-8 code unit sequence and it is decoded to produce a sequence of Unicode8 scalar values.
A sequence of translation character set elements is then formed by mapping each Unicode scalar value to the corresponding translation character set element.
In the resulting sequence, each pair of characters in the input sequence consisting of U+000d carriage return followed by U+000a line feed, as well as each U+000d carriage return not immediately followed by a U+000a line feed, is replaced by a single new-line character.
For any other kind of input file supported by the implementation, characters are mapped, in an implementation-defined manner, to a sequence of translation character set elements ([lex.charset]), representing end-of-line indicators as new-line characters.
2.
If the first translation character is U+feff byte order mark, it is deleted.
Each sequence of a backslash character (\) immediately followed by zero or more whitespace characters other than new-line 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.
[Note 2: 
Line splicing can form a universal-character-name ([lex.charset]).
— end note]
A source file that is not empty and that (after splicing) does not end in a new-line character shall be processed as if an additional new-line character were appended to the file.
3.
The source file is decomposed into preprocessing tokens ([lex.pptoken]) and sequences of whitespace characters (including comments).
A source file shall not end in a partial preprocessing token or in a partial comment.9
Each comment ([lex.comment]) is replaced by one space character.
New-line characters are retained.
Whether each nonempty sequence of whitespace characters other than new-line is retained or replaced by one space character is unspecified.
As characters from the source file are consumed to form the next preprocessing token (i.e., not being consumed as part of a comment or other forms of whitespace), except when matching a c-char-sequence, s-char-sequence, r-char-sequence, h-char-sequence, or q-char-sequence, universal-character-names are recognized ([lex.universal.char]) and replaced by the designated element of the translation character set ([lex.charset]).
The process of dividing a source file's characters into preprocessing tokens is context-dependent.
[Example 1: 
See the handling of < within a #include preprocessing directive ([cpp.include]).
— end example]
4.
Preprocessing directives ([cpp]) are executed, macro invocations are expanded ([cpp.replace]), and _Pragma unary operator expressions are executed ([cpp.pragma.op]).
A #include preprocessing directive ([cpp.include]) causes the named header or source file to be processed from phase 1 through phase 4, recursively.
All preprocessing directives are then deleted.
5.
For a sequence of two or more adjacent string-literal tokens, a common encoding-prefix is determined as specified in [lex.string].
Each such string-literal token is then considered to have that common encoding-prefix.
6.
Adjacent string-literal tokens are concatenated ([lex.string]).
7.
Whitespace characters separating tokens are no longer significant.
Each preprocessing token is converted into a token ([lex.token]).
The resulting tokens constitute a translation unit and are syntactically and semantically analyzed and translated.
[Note 3: 
The process of analyzing and translating the tokens can 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 4: 
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.
Translated translation units and instantiation units are combined as follows:
[Note 5: 
Some or all of these can be supplied from a library.
— end note]
Each translated translation unit is examined to produce a list of required instantiations.
[Note 6: 
This can 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 7: 
An implementation can choose to 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 8: 
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.
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.
7)7)
Implementations behave as if these separate phases occur, although in practice different phases can be folded together.
8)8)
Unicode® is a registered trademark of Unicode, Inc.
This information is given for the convenience of users of this document and does not constitute an endorsement by ISO or IEC of this product.
9)9)
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.

5.3 Characters [lex.char]

5.3.1 Character sets [lex.charset]

1
#
The translation character set consists of the following elements:
  • (1.1)
    each abstract character assigned a code point in the Unicode codespace as specified in the Unicode Standard, and
  • (1.2)
    a distinct character for each Unicode scalar value not assigned to an abstract character.
[Note 1: 
Unicode code points are integers in the range [0, 10FFFF] (hexadecimal).
A surrogate code point is a value in the range [D800, DFFF] (hexadecimal).
A Unicode scalar value is any code point that is not a surrogate code point.
— end note]
2
#
The basic character set is a subset of the translation character set, consisting of 99 characters as specified in Table 1.
[Note 2: 
Unicode short names are given only as a means to identifying the character; the numerical value has no other meaning in this context.
— end note]
Table 1: Basic character set [tab:lex.charset.basic]
character
glyph
U+0009
character tabulation
U+000b
line tabulation
U+000c
form feed
U+0020
space
U+000a
line feed
new-line
U+0021
exclamation mark
!
U+0022
quotation mark
"
U+0023
number sign
#
U+0024
dollar sign
$
U+0025
percent sign
%
U+0026
ampersand
&
U+0027
apostrophe
'
U+0028
left parenthesis
(
U+0029
right parenthesis
)
U+002a
asterisk
*
U+002b
plus sign
+
U+002c
comma
,
U+002d
hyphen-minus
-
U+002e
full stop
.
U+002f
solidus
/
U+0030 ..
U+0039
digit zero .. nine
0 1 2 3 4 5 6 7 8 9
U+003a
colon
:
U+003b
semicolon
;
U+003c
less-than sign
<
U+003d
equals sign
=
U+003e
greater-than sign
>
U+003f
question mark
?
U+0040
commercial at
@
U+0041 ..
U+005a
latin capital letter a .. 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
U+005b
left square bracket
[
U+005c
reverse solidus
\
U+005d
right square bracket
]
U+005e
circumflex accent
^
U+005f
low line
_
U+0060
grave accent
`
U+0061 ..
U+007a
latin small letter a .. 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
U+007b
left curly bracket
{
U+007c
vertical line
|
U+007d
right curly bracket
}
U+007e
tilde
~
3
#
The basic literal character set consists of all characters of the basic character set, plus the control characters specified in Table 2.
Table 2: Additional control characters in the basic literal character set [tab:lex.charset.literal]
character
U+0000
null
U+0007
alert
U+0008
backspace
U+000d
carriage return
4
#
A code unit is an integer value of character type ([basic.fundamental]).
Characters in a character-literal other than a multicharacter or non-encodable character literal or in a string-literal are encoded as a sequence of one or more code units, as determined by the encoding-prefix ([lex.ccon], [lex.string]); this is termed the respective literal encoding.
The ordinary literal encoding is the encoding applied to an ordinary character or string literal.
The wide literal encoding is the encoding applied to a wide character or string literal.
5
#
A literal encoding or a locale-specific encoding of one of the execution character sets ([character.seq]) encodes each element of the basic literal character set as a single code unit with non-negative value, distinct from the code unit for any other such element.
[Note 3: 
A character not in the basic literal character set can be encoded with more than one code unit; the value of such a code unit can be the same as that of a code unit for an element of the basic literal character set.
— end note]
The U+0000 null character is encoded as the value 0.
No other element of the translation character set is encoded with a code unit of value 0.
The code unit value of each decimal digit character after the digit 0 (U+0030) shall be one greater than the value of the previous.
The ordinary and wide literal encodings are otherwise implementation-defined.
For a UTF-8, UTF-16, or UTF-32 literal, the implementation shall encode the Unicode scalar value corresponding to each character of the translation character set as specified in the Unicode Standard for the respective Unicode encoding form.

5.3.2 Universal character names [lex.universal.char]

n-char:
any member of the translation character set except the U+007d right curly bracket or new-line character
1
#
The universal-character-name construct provides a way to name any element in the translation character set using just the basic character set.
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 character set, the program is ill-formed.
[Note 1: 
A sequence of characters resembling a universal-character-name in an r-char-sequence ([lex.string]) does not form a universal-character-name.
— end note]
2
#
A universal-character-name of the form \u hex-quad, \U hex-quad hex-quad, or \u{simple-hexadecimal-digit-sequence} designates the character in the translation character set whose Unicode scalar value 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 Unicode scalar value.
3
#
A universal-character-name that is a named-universal-character designates the corresponding character in the Unicode Standard (chapter 4.8 Name) if the n-char-sequence is equal to its character name or to one of its character name aliases of type “control”, “correction”, or “alternate”; otherwise, the program is ill-formed.
[Note 2: 
These aliases are listed in the Unicode Character Database's NameAliases.txt.
None of these names or aliases have leading or trailing spaces.
— end note]

5.4 Comments [lex.comment]

1
#
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 whitespace characters shall appear between it and the new-line that terminates the comment; no diagnostic is required.
[Note 1: 
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.5 Preprocessing tokens [lex.pptoken]

1
#
A preprocessing token is the minimal lexical element of the language in translation phases 3 through 6.
In this document, glyphs are used to identify elements of the basic character set ([lex.charset]).
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-whitespace characters that do not lexically match the other preprocessing token categories.
If a U+0027 apostrophe or a U+0022 quotation mark character matches the last category, the program is ill-formed.
If any character not in the basic character set matches the last category, the program is ill-formed.
Preprocessing tokens can be separated by whitespace; this consists of comments ([lex.comment]), or whitespace characters (U+0020 space, U+0009 character tabulation, new-line, U+000b line tabulation, and U+000c form feed), or both.
As described in [cpp], in certain circumstances during translation phase 4, whitespace (or the absence thereof) serves as more than preprocessing token separation.
Whitespace 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.
2
#
Each preprocessing token that is converted to a token ([lex.token]) shall have the lexical form of a keyword, an identifier, a literal, or an operator or punctuator.
3
#
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 1: 
None has any observable spelling.
— end note]
4
#
If the input stream has been parsed into preprocessing tokens up to a given character:
  • (4.1)
    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 phase 2 (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
  • (4.2)
    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 <:.
  • (4.3)
    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 ([lex.header]) is only formed
5
#
[Example 1: #define R "x" const char* s = R"y"; // ill-formed raw string, not "x" "y" — end example]
6
#
[Example 2: 
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 can produce a valid expression (for example, if foo is 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]
7
#
[Example 3: 
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 can yield a correct expression.
— end example]

5.6 Header names [lex.header]

h-char:
any member of the translation character set except new-line and U+003e greater-than sign
q-char:
any member of the translation character set except new-line and U+0022 quotation mark
1
#
[Note 1: 
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].
2
#
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.10
10)10)
Thus, a sequence of characters that resembles an escape sequence can 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.7 Preprocessing numbers [lex.ppnumber]

1
#
Preprocessing number tokens lexically include all integer-literal tokens ([lex.icon]) and all floating-point-literal tokens ([lex.fcon]).
2
#
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.8 Operators and punctuators [lex.operators]

1
#
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-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 ([lex.phases]).

5.9 Alternative tokens [lex.digraph]

1
#
Alternative token representations are provided for some operators and punctuators.11
2
#
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 3.
Table 3: 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
&
11)11)
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”.
12)12)
Thus the “stringized” values ([cpp.stringize]) of [ and <: will be different, maintaining the source spelling, but the tokens can otherwise be freely interchanged.

5.10 Tokens [lex.token]

1
#
There are five kinds of tokens: identifiers, keywords, literals,13 operators, and other separators.
Blanks, horizontal and vertical tabs, newlines, formfeeds, and comments (collectively, “whitespace”), as described below, are ignored except as they serve to separate tokens.
[Note 1: 
Whitespace can separate otherwise adjacent identifiers, keywords, numeric literals, and alternative tokens containing alphabetic characters.
— end note]
13)13)
Literals include strings and character and numeric literals.

5.11 Identifiers [lex.name]

identifier-start:
nondigit
an element of the translation character set with the Unicode property XID_Start
identifier-continue:
digit
nondigit
an element of the translation character set with the Unicode property XID_Continue
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
1
#
[Note 1: 
The character properties XID_Start and XID_Continue are described by UAX #44 of the Unicode Standard.14
— end note]
The program is ill-formed if an identifier does not conform to Normalization Form C as specified in the Unicode Standard.
[Note 2: 
Identifiers are case-sensitive.
— end note]
[Note 3: 
[uaxid] compares the requirements of UAX #31 of the Unicode Standard with the C++ rules for identifiers.
— end note]
[Note 4: 
In translation phase 4, identifier also includes those preprocessing-tokens ([lex.pptoken]) differentiated as keywords ([lex.key]) in the later translation phase 7 ([lex.token]).
— end note]
2
#
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
3
#
In addition, some identifiers appearing as a token or preprocessing-token are reserved for use by C++ implementations and shall not be used otherwise; no diagnostic is required.
  • (3.1)
    Each identifier that contains a double underscore __ or begins with an underscore followed by an uppercase letter, other than those specified in this document (for example, __cplusplus ([cpp.predefined])), is reserved to the implementation for any use.
  • (3.2)
    Each identifier that begins with an underscore is reserved to the implementation for use as a name in the global namespace.
14)14)
On systems in which linkers cannot accept extended characters, an encoding of the universal-character-name can be used in forming valid external identifiers.
For example, some otherwise unused character or sequence of characters can be used to encode the \u in a universal-character-name.
Extended characters can produce a long external identifier, but C++ does not place a translation limit on significant characters for external identifiers.

5.12 Keywords [lex.key]

keyword:
any identifier listed in Table 5
import-keyword
module-keyword
export-keyword
1
#
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 ([dcl.attr.grammar]).
[Note 1: 
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
2
#
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.13 Literals [lex.literal]

5.13.1 Kinds of literals [lex.literal.kinds]

1
#
There are several kinds of literals.15
[Note 1: 
When appearing as an expression, a literal has a type and a value category ([expr.prim.literal]).
— end note]
15)15)
The term “literal” generally designates, in this document, those tokens that are called “constants” in C.

5.13.2 Integer literals [lex.icon]

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: one of
0 1 2 3 4 5 6 7 8 9
a b c d e f
A B C D E F
unsigned-suffix: one of
u U
long-suffix: one of
l L
long-long-suffix: one of
ll LL
size-suffix: one of
z Z
1
#
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 1: 
The prefix and any optional separating single quotes are ignored when determining the value.
— end note]
2
#
The hexadecimal-digits a through f and A through F have decimal values ten through fifteen.
[Example 1: 
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]
3
#
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.
Table 8: Types of integer-literals [tab:lex.icon.type]
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
z or Z
the signed integer type corresponding
the signed integer type
  to std​::​size_t ([support.types.layout])
  corresponding to std​::​size_t
std​::​size_t
Both u or U
std​::​size_t
std​::​size_t
and z or Z
4
#
Except for integer-literals containing a size-suffix, if the value of 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 is signed.
If all of the types in the list for the integer-literal are unsigned, the extended integer type is unsigned.
If the list contains both signed and unsigned types, the extended integer type may be signed or unsigned.
If an integer-literal cannot be represented by any of the allowed types, the program is ill-formed.
[Note 2: 
An integer-literal with a z or Z suffix is ill-formed if it cannot be represented by std​::​size_t.
— end note]

5.13.3 Character literals [lex.ccon]

encoding-prefix: one of
u8  u  U  L
basic-c-char:
any member of the translation character set except the U+0027 apostrophe,
   U+005c reverse solidus, or new-line character
simple-escape-sequence-char: one of
' " ? \ a b f n r t v
conditional-escape-sequence-char:
any member of the basic character set that is not an octal-digit, a simple-escape-sequence-char, or the characters N, o, u, U, or x
1
#
A multicharacter literal is a character-literal whose c-char-sequence consists of more than one c-char.
A multicharacter literal shall not have an encoding-prefix.
If a multicharacter literal contains a c-char that is not encodable as a single code unit in the ordinary literal encoding, the program is ill-formed.
Multicharacter literals are conditionally-supported.
2
#
The kind of a character-literal, its type, and its associated character encoding ([lex.charset]) are determined by its encoding-prefix and its c-char-sequence as defined by Table 9.
Table 9: Character literals [tab:lex.ccon.literal]
Encoding
Kind
Type
Associated char-
Example
prefix
acter encoding
none
char
ordinary literal
'v'
multicharacter literal
int
encoding
'abcd'
L
wchar_t
wide literal
L'w'
encoding
u8
char8_t
UTF-8
u8'x'
u
char16_t
UTF-16
u'y'
U
char32_t
UTF-32
U'z'
3
#
In translation phase 4, the value of a character-literal is determined using the range of representable values of the character-literal's type in translation phase 7.
A multicharacter literal has an implementation-defined value.
The value of any other kind of character-literal is determined as follows:
4
#
The character specified by a simple-escape-sequence is specified in Table 10.
[Note 1: 
Using an escape sequence for a question mark is supported for compatibility with C++ 2014 and C.
— end note]
Table 10: Simple escape sequences [tab:lex.ccon.esc]
character
U+000a
line feed
\n
U+0009
character tabulation
\t
U+000b
line tabulation
\v
U+0008
backspace
\b
U+000d
carriage return
\r
U+000c
form feed
\f
U+0007
alert
\a
U+005c
reverse solidus
\\
U+003f
question mark
\?
U+0027
apostrophe
\'
U+0022
quotation mark
\"

5.13.4 Floating-point literals [lex.fcon]

sign: one of
+ -
floating-point-suffix: one of
f l f16 f32 f64 f128 bf16 F L F16 F32 F64 F128 BF16
1
#
The type of a floating-point-literal ([basic.fundamental], [basic.extended.fp]) is determined by its floating-point-suffix as specified in Table 11.
[Note 1: 
The floating-point suffixes f16, f32, f64, f128, bf16, F16, F32, F64, F128, and BF16 are conditionally-supported.
— end note]
Table 11: Types of floating-point-literals [tab:lex.fcon.type]
type
none
double
f or F
float
l or L
long double
f16 or F16
std::float16_t
f32 or F32
std::float32_t
f64 or F64
std::float64_t
f128 or F128
std::float128_t
bf16 or BF16
std::bfloat16_t
2
#
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 2: 
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 1: 
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]
3
#
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]

basic-s-char:
any member of the translation character set except the U+0022 quotation mark,
   U+005c reverse solidus, or new-line character
r-char:
any member of the translation character set, except a U+0029 right parenthesis followed by
   the initial d-char-sequence (which may be empty) followed by a U+0022 quotation mark
d-char:
any member of the basic character set except:
   U+0020 space, U+0028 left parenthesis, U+0029 right parenthesis, U+005c reverse solidus,
   U+0009 character tabulation, U+000b line tabulation, U+000c form feed, and new-line
1
#
The kind of a string-literal, its type, and its associated character encoding ([lex.charset]) are determined by its encoding prefix and sequence of s-chars or r-chars as defined by Table 12 where n is the number of encoded code units as described below.
Table 12: String literals [tab:lex.string.literal]
Enco-
Kind
Type
Associated
Examples
ding
character
prefix
encoding
none
array of n
const char
ordinary literal encoding
"ordinary string"
R"(ordinary raw string)"
L
array of n
const wchar_t
wide literal
encoding
L"wide string"
LR"w(wide raw string)w"
u8
array of n
const char8_t
UTF-8
u8"UTF-8 string"
u8R"x(UTF-8 raw string)x"
u
array of n
const char16_t
UTF-16
u"UTF-16 string"
uR"y(UTF-16 raw string)y"
U
array of n
const char32_t
UTF-32
U"UTF-32 string"
UR"z(UTF-32 raw string)z"
2
#
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.
3
#
[Note 1: 
The characters '(' and ')' can appear in a raw-string.
Thus, R"delimiter((a|b))delimiter" is equivalent to "(a|b)".
— end note]
4
#
[Note 2: 
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]
5
#
[Example 1: 
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]
6
#
Ordinary string literals and UTF-8 string literals are also referred to as narrow string literals.
7
#
The string-literals in any sequence of adjacent string-literals shall have at most one unique encoding-prefix among them.
The common encoding-prefix of the sequence is that encoding-prefix, if any.
[Note 3: 
A string-literal's rawness has no effect on the determination of the common encoding-prefix.
— end note]
8
#
In translation phase 6 ([lex.phases]), adjacent string-literals are concatenated.
The lexical structure and grouping of the contents of the individual string-literals is retained.
[Example 2: 
"\xA" "B" represents the code unit '\xA' and the character 'B' after concatenation (and not the single code unit '\xAB').
Similarly, R"(\u00)" "41" represents six characters, starting with a backslash and ending with the digit 1 (and not the single character 'A' specified by a universal-character-name).
Table 13 has some examples of valid concatenations.
— end example]
Table 13: 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"
9
#
Evaluating a string-literal results in a string literal object with static storage duration ([basic.stc]).
[Note 4: 
String literal objects are potentially non-unique ([intro.object]).
Whether successive evaluations of a string-literal yield the same or a different object is unspecified.
— end note]
[Note 5: 
The effect of attempting to modify a string literal object is undefined.
— end note]
10
#
String literal objects are initialized with the sequence of code unit values corresponding to the string-literal's sequence of s-chars (originally from non-raw string literals) and r-chars (originally from raw string literals), plus a terminating U+0000 null character, in order as follows:
  • (10.1)
    The sequence of characters denoted by each contiguous sequence of basic-s-chars, r-chars, simple-escape-sequences ([lex.ccon]), and universal-character-names ([lex.charset]) is encoded to a code unit sequence using the string-literal's associated character encoding.
    If a character lacks representation in the associated character encoding, then the program is ill-formed.
    [Note 6: 
    No character lacks representation in any Unicode encoding form.
    — end note]
    When encoding a stateful character encoding, implementations should encode the first such sequence beginning with the initial encoding state and encode subsequent sequences beginning with the final encoding state of the prior sequence.
    [Note 7: 
    The encoded code unit sequence can differ from the sequence of code units that would be obtained by encoding each character independently.
    — end note]
  • (10.2)
    Each numeric-escape-sequence ([lex.ccon]) contributes a single code unit with a value as follows:
    When encoding a stateful character encoding, these sequences should have no effect on encoding state.
  • (10.3)
    Each conditional-escape-sequence ([lex.ccon]) contributes an implementation-defined code unit sequence.
    When encoding a stateful character encoding, it is implementation-defined what effect these sequences have on encoding state.

5.13.6 Unevaluated strings [lex.string.uneval]

1
#
2
#
Each universal-character-name and each simple-escape-sequence in an unevaluated-string is replaced by the member of the translation character set it denotes.
3
#
An unevaluated-string is never evaluated and its interpretation depends on the context in which it appears.

5.13.7 Boolean literals [lex.bool]

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

5.13.8 Pointer literals [lex.nullptr]

1
#
The pointer literal is the keyword nullptr.
It has type std​::​nullptr_t.
[Note 1: 
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.9 User-defined literals [lex.ext]

1
#
If a token matches both user-defined-literal and another literal kind, it is treated as the latter.
[Example 1: 
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.
2
#
A user-defined-literal is treated as a call to a literal operator or literal operator template ([over.literal]).
To determine the form of this call for a given user-defined-literal L with ud-suffix X, first let S be the set of declarations found by unqualified lookup for the literal-operator-id whose literal suffix identifier is X ([basic.lookup.unqual]).
S shall not be empty.
3
#
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 1: 
The sequence can only contain characters from the basic character set.
— end note]
4
#
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 2: 
The sequence can only contain characters from the basic character set.
— end note]
5
#
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)
6
#
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)
7
#
[Example 2: 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]
8
#
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.
9
#
[Example 3: 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]

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

6.2 Declarations and definitions [basic.def]

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

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

1
#
Each of the following is termed a definable item:
2
#
No translation unit shall contain more than one definition of any definable item.
3
#
An expression or conversion is potentially evaluated unless it is an unevaluated operand ([expr.context]), 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:
  • (3.1)
    If E is an id-expression ([expr.prim.id]), the set contains only E.
  • (3.2)
    If E is a subscripting operation with an array operand, the set contains the potential results of that operand.
  • (3.3)
    If E is a class member access expression ([expr.ref]) of the form . template naming a non-static data member, the set contains the potential results of .
  • (3.4)
    If E is a class member access expression naming a static data member, the set contains the id-expression designating the data member.
  • (3.5)
    If E is a pointer-to-member expression of the form .* , the set contains the potential results of .
  • (3.6)
    If E has the form (), the set contains the potential results of .
  • (3.7)
    If E is a glvalue conditional expression, the set is the union of the sets of potential results of the second and third operands.
  • (3.8)
    If E is a comma expression, the set contains the potential results of the right operand.
  • (3.9)
    Otherwise, the set is empty.
[Note 1: 
This set is a (possibly-empty) set of id-expressions, each of which is either E or a subexpression of E.
[Example 1: 
In the following example, the set of potential results of the initializer of n contains the first S​::​x subexpression, but not the second S​::​x subexpression.
struct S { static const int x = 0; }; const int &f(const int &r); int n = b ? (1, S::x) // S​::​x is not odr-used here : f(S::x); // S​::​x is odr-used here, so a definition is required — end example]
— end note]
4
#
A function is named by an expression or conversion as follows:
  • (4.1)
    A function is named by an expression or conversion if it is the selected member of an overload set ([basic.lookup], [over.match], [over.over]) in an overload resolution performed as part of forming that expression or conversion, unless it is a pure virtual function and either the expression is not an id-expression naming the function with an explicitly qualified name or the expression forms a pointer to member ([expr.unary.op]).
    [Note 2: 
    This covers taking the address of functions ([conv.func], [expr.unary.op]), calls to named functions ([expr.call]), operator overloading ([over]), user-defined conversions ([class.conv.fct]), allocation functions for new-expressions ([expr.new]), as well as non-default initialization ([dcl.init]).
    A constructor selected to copy or move an object of class type is considered to be named by an expression or conversion even if the call is actually elided by the implementation ([class.copy.elision]).
    — end note]
  • (4.2)
    A deallocation function for a class is named by a new-expression if it is the single matching deallocation function for the allocation function selected by overload resolution, as specified in [expr.new].
  • (4.3)
    A deallocation function for a class is named by a delete-expression if it is the selected usual deallocation function as specified in [expr.delete] and [class.free].
5
#
A variable is named by an expression if the expression is an id-expression that denotes it.
A variable x that is named by a potentially-evaluated expression E is odr-used by E unless
  • (5.1)
    x is a reference that is usable in constant expressions ([expr.const]), or
  • (5.2)
    x is a variable of non-reference type that is usable in constant expressions and has no mutable subobjects, and E is an element of the set of potential results of an expression of non-volatile-qualified non-class type to which the lvalue-to-rvalue conversion ([conv.lval]) is applied, or
  • (5.3)
    x is a variable of non-reference type, and E is an element of the set of potential results of a discarded-value expression ([expr.context]) to which the lvalue-to-rvalue conversion is not applied.
6
#
A structured binding is odr-used if it appears as a potentially-evaluated expression.
7
#
*this is odr-used if this appears as a potentially-evaluated expression (including as the result of any implicit transformation to a class member access expression ([expr.prim.id.general])).
8
#
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]).17
9
#
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.
10
#
A local entity ([basic.pre]) is odr-usable in a scope ([basic.scope.scope]) if
  • (10.1)
    either the local entity is not *this, or an enclosing class or non-lambda function parameter scope exists and, if the innermost such scope is a function parameter scope, it corresponds to a non-static member function, and
  • (10.2)
    for each intervening scope ([basic.scope.scope]) between the point at which the entity is introduced and the scope (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 scope in which it is not odr-usable, the program is ill-formed.
[Example 2: void f(int n) { [] { n = 1; }; // error: n is not odr-usable due to intervening lambda-expression struct A { void f() { n = 2; } // error: n is not odr-usable due to intervening function definition scope }; void g(int = n); // error: n is not odr-usable due to intervening function parameter scope [=](int k = n) {}; // error: n is not odr-usable due to being // outside the block scope of the lambda-expression [&] { [n]{ return n; }; }; // OK } — end example]
11
#
[Example 3: void g() { constexpr int x = 1; auto lambda = [] <typename T, int = ((T)x, 0)> {}; // OK lambda.operator()<int, 1>(); // OK, does not consider x at all lambda.operator()<int>(); // OK, does not odr-use x lambda.operator()<const int&>(); // error: odr-uses x from a context where x is not odr-usable } void h() { constexpr int x = 1; auto lambda = [] <typename T> { (T)x; }; // OK lambda.operator()<int>(); // OK, does not odr-use x lambda.operator()<void>(); // OK, does not odr-use x lambda.operator()<const int&>(); // error: odr-uses x from a context where x is not odr-usable } — end example]
12
#
Every program shall contain at least one definition of every 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 4: 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]
13
#
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.
14
#
A definition of a class shall be reachable in every context in which the class is used in a way that requires the class type to be complete.
[Example 5: 
The following complete translation unit is well-formed, even though it never defines X: struct X; // declare X as a struct type struct X* x1; // use X in pointer formation X* x2; // use X in pointer formation
— end example]
[Note 3: 
The rules for declarations and expressions describe in which contexts complete class types are required.
A class type T must be complete if
— end note]
15
#
For any definable item D with definitions in multiple translation units,
  • (15.1)
    if D is a non-inline non-templated function or variable, or
  • (15.2)
    if the definitions in different translation units do not satisfy the following requirements,
the program is ill-formed; a diagnostic is required only if the definable item is attached to a named module and a prior definition is reachable at the point where a later definition occurs.
Given such an item, 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.
  • (15.3)
    Each such definition shall not be attached to a named module ([module.unit]).
  • (15.4)
    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.
  • (15.5)
    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
    • (15.5.1)
      a non-volatile const object with internal or no linkage if the object or
    • (15.5.2)
      a reference with internal or no linkage initialized with a constant expression such that the reference refers to the same entity in all definitions of D.
  • (15.6)
    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).
  • (15.7)
    In each such definition, corresponding entities shall have the same language linkage.
  • (15.8)
    In each such definition, const objects with static or thread storage duration shall be constant-initialized if the object is constant-initialized in any such definition.
  • (15.9)
    In each such definition, corresponding manifestly constant-evaluated expressions that are not value-dependent shall have the same value ([expr.const], [temp.dep.constexpr]).
  • (15.10)
    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.
  • (15.11)
    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).
16
#
For the purposes of the preceding requirements:
  • (16.1)
    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 6: // 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]
  • (16.2)
    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.
  • (16.3)
    If D is a template and is defined in more than one translation unit, the requirements apply both to names from the template's enclosing scope used in the template definition, and also to dependent names at the point of instantiation ([temp.dep]).
17
#
These requirements also apply to corresponding entities defined within each definition of D (including the closure types of lambda-expressions, but excluding entities defined within default arguments or default template arguments of either D or an entity not defined within D).
For each such entity and for D itself, the behavior is as if there is a single entity with a single definition, including in the application of these requirements to other entities.
[Note 4: 
The entity is still declared in multiple translation units, and [basic.link] still applies to these declarations.
In particular, lambda-expressions ([expr.prim.lambda]) appearing in the type of D can result in the different declarations having distinct types, and lambda-expressions appearing in a default argument of D might still denote different types in different translation units.
— end note]
18
#
[Example 7: 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]
19
#
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.
17)17)
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 General [basic.scope.scope]

1
#
The declarations in a program appear in a number of scopes that are in general discontiguous.
The global scope contains the entire program; every other scope S is introduced by a declaration, parameter-declaration-clause, statement, or handler (as described in the following subclauses of [basic.scope]) appearing in another scope which thereby contains S.
An enclosing scope at a program point is any scope that contains it; the smallest such scope is said to be the immediate scope at that point.
A scope intervenes between a program point P and a scope S (that does not contain P) if it is or contains S but does not contain P.
2
#
Unless otherwise specified:
An entity belongs to a scope S if S is the target scope of a declaration of the entity.
[Note 1: 
Special cases include that:
— end note]
3
#
Two non-static member functions have corresponding object parameters if
  • (3.1)
    exactly one is an implicit object member function with no ref-qualifier and the types of their object parameters ([dcl.fct]), after removing references, are the same, or
  • (3.2)
    their object parameters have the same type.
Two non-static member function templates have corresponding object parameters if
  • (3.3)
    exactly one is an implicit object member function with no ref-qualifier and the types of their object parameters, after removing any references, are equivalent, or
  • (3.4)
    the types of their object parameters are equivalent.
Two function templates have corresponding signatures if their template-parameter-lists have the same length, their corresponding template-parameters are equivalent, they have equivalent non-object-parameter-type-lists and return types (if any), and, if both are non-static members, they have corresponding object parameters.
4
#
Two declarations correspond if they (re)introduce the same name, both declare constructors, or both declare destructors, unless
  • (4.1)
    either is a using-declarator, or
  • (4.2)
    one declares a type (not a typedef-name) and the other declares a variable, non-static data member other than of an anonymous union ([class.union.anon]), enumerator, function, or function template, or
  • (4.3)
    each declares a function or function template and they do not declare corresponding overloads.
Two function or function template declarations declare corresponding overloads if
[Note 2: 
Declarations can correspond even if neither binds a name.
[Example 1: struct A { friend void f(); // #1 }; struct B { friend void f() {} // corresponds to, and defines, #1 }; — end example]
— end note]
[Example 2: typedef int Int; enum E : int { a }; void f(int); // #1 void f(Int) {} // defines #1 void f(E) {} // OK, another overload struct X { static void f(); void f() const; // error: redeclaration void g(); void g() const; // OK void g() &; // error: redeclaration void h(this X&, int); void h(int) &&; // OK, another overload void j(this const X&); void j() const &; // error: redeclaration void k(); void k(this X&); // error: redeclaration }; — end example]
5
#
A declaration is name-independent if its name is _ (U+005f low line) and it declares
Recommended practice: Implementations should not emit a warning that a name-independent declaration is used or unused.
6
#
Two declarations potentially conflict if they correspond and cause their shared name to denote different entities ([basic.link]).
The program is ill-formed if, in any scope, a name is bound to two declarations A and B that potentially conflict and A precedes B ([basic.lookup]), unless B is name-independent.
[Note 3: 
An id-expression that names a unique name-independent declaration is usable until an additional declaration of the same name is introduced in the same scope ([basic.lookup.general]).
— end note]
[Note 4: 
Overload resolution can consider potentially conflicting declarations found in multiple scopes (e.g., via using-directives or for operator functions), in which case it is often ambiguous.
— end note]
[Example 3: void f() { int x,y; void x(); // error: different entity for x int y; // error: redefinition } enum { f }; // error: different entity for ​::​f namespace A {} namespace B = A; namespace B = A; // OK, no effect namespace B = B; // OK, no effect namespace A = B; // OK, no effect namespace B {} // error: different entity for B void g() { int _; _ = 0; // OK int _; // OK, name-independent declaration _ = 0; // error: two non-function declarations in the lookup set } void h () { int _; // #1 _ ++; // OK static int _; // error: conflicts with #1 because static variables are not name-independent } — end example]
7
#
A declaration is nominable in a class, class template, or namespace E at a point P if it precedes P, it does not inhabit a block scope, and its target scope is the scope associated with E or, if E is a namespace, any element of the inline namespace set of E ([namespace.def]).
[Example 4: namespace A { void f() {void g();} inline namespace B { struct S { friend void h(); static int i; }; } }
At the end of this example, the declarations of f, B, S, and h are nominable in A, but those of g and i are not.
— end example]
8
#
When instantiating a templated entity ([temp.pre]), any scope S introduced by any part of the template definition is considered to be introduced by the instantiated entity and to contain the instantiations of any declarations that inhabit S.
18)18)
An implicit object parameter ([over.match.funcs]) is not part of the parameter-type-list.

6.4.2 Point of declaration [basic.scope.pdecl]

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

6.4.3 Block scope [basic.scope.block]

1
#
Each introduces a block scope that includes that statement or handler.
[Note 1: 
A substatement that is also a block has only one scope.
— end note]
A variable that belongs to a block scope is a block variable.
[Example 1: int i = 42; int a[10]; for (int i = 0; i < 10; i++) a[i] = i; int j = i; // j = 42 — end example]
2
#
If a declaration that is not a name-independent declaration and that binds a name in the block scope S of a potentially conflicts with a declaration whose target scope is the parent scope of S, the program is ill-formed.
[Example 2: if (int x = f()) { int x; // error: redeclaration of x } else { int x; // error: redeclaration of x } — end example]

6.4.4 Function parameter scope [basic.scope.param]

1
#
[Note 1: 
A function parameter cannot be used for its value within the parameter-declaration-clause ([dcl.fct.default]).
— end note]

6.4.5 Lambda scope [basic.scope.lambda]

A lambda-expression E introduces a lambda scope that starts immediately after the lambda-introducer of E and extends to the end of the compound-statement of E.

6.4.6 Namespace scope [basic.scope.namespace]

1
#
Any namespace-definition for a namespace N introduces a namespace scope that includes the namespace-body for every namespace-definition for N.
For each non-friend redeclaration or specialization whose target scope is or is contained by the scope, the portion after the declarator-id, class-head-name, or enum-head-name is also included in the scope.
The global scope is the namespace scope of the global namespace ([basic.namespace]).
[Example 1: namespace Q { namespace V { void f(); } void V::f() { // in the scope of V void h(); // declares Q​::​V​::​h } } — end example]

6.4.7 Class scope [basic.scope.class]

1
#
Any declaration of a class or class template C introduces a class scope that includes the member-specification of the class-specifier for C (if any).
For each non-friend redeclaration or specialization whose target scope is or is contained by the scope, the portion after the declarator-id, class-head-name, or enum-head-name is also included in the scope.
[Note 1: 
Lookup from a program point before the class-specifier of a class will find no bindings in the class scope.
[Example 1: template<class D> struct B { D::type x; // #1 }; struct A { using type = int; }; struct C : A, B<C> {}; // error at #1: C​::​type not found — end example]
— end note]

6.4.8 Enumeration scope [basic.scope.enum]

1
#
Any declaration of an enumeration E introduces an enumeration scope that includes the enumerator-list of the enum-specifier for E (if any).

6.4.9 Template parameter scope [basic.scope.temp]

1
#
Each template template-parameter introduces a template parameter scope that includes the template-head of the template-parameter.
2
#
Each template-declaration D introduces a template parameter scope that extends from the beginning of its template-parameter-list to the end of the template-declaration.
Any declaration outside the template-parameter-list that would inhabit that scope instead inhabits the same scope as D.
The parent scope of any scope S that is not a template parameter scope is the smallest scope that contains S and is not a template parameter scope.
[Note 1: 
Therefore, only template parameters belong to a template parameter scope, and only template parameter scopes have a template parameter scope as a parent scope.
— end note]

6.5 Name lookup [basic.lookup]

6.5.1 General [basic.lookup.general]

1
#
The name lookup rules apply uniformly to all names (including typedef-names ([dcl.typedef]), namespace-names ([basic.namespace]), and class-names ([class.name])) wherever the grammar allows such names in the context discussed by a particular rule.
Name lookup associates the use of a name with a set of declarations ([basic.def]) of that name.
Unless otherwise specified, the program is ill-formed if no declarations are found.
If the declarations found by name lookup all denote functions or function templates, the declarations are said to form an overload set.
Otherwise, if the declarations found by name lookup do not all denote the same entity, they are ambiguous and the program is ill-formed.
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 declarations used in further processing.
2
#
A program point P is said to follow any declaration in the same translation unit whose locus ([basic.scope.pdecl]) is before P.
[Note 1: 
The declaration might appear in a scope that does not contain P.
— end note]
A declaration X precedes a program point P in a translation unit L if P follows X, X inhabits a class scope and is reachable from P, or else X appears in a translation unit D and
[Note 3: 
A module-import-declaration imports both the named translation unit(s) and any modules named by exported module-import-declarations within them, recursively.
[Example 1: 

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

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

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

— end note]
3
#
A single search in a scope S for a name N from a program point P finds all declarations that precede P to which any name that is the same as N ([basic.pre]) is bound in S.
If any such declaration is a using-declarator whose terminal name ([expr.prim.id.unqual]) is not dependent ([temp.dep.type]), it is replaced by the declarations named by the using-declarator ([namespace.udecl]).
4
#
In certain contexts, only certain kinds of declarations are included.
After any such restriction, any declarations of classes or enumerations are discarded if any other declarations are found.
[Note 4: 
A type (but not a typedef-name or template) is therefore hidden by any other entity in its scope.
— end note]
However, if a lookup is type-only, only declarations of types and templates whose specializations are types are considered; furthermore, if declarations of a typedef-name and of the type to which it refers are found, the declaration of the typedef-name is discarded instead of the type declaration.

6.5.2 Member name lookup [class.member.lookup]

1
#
A search in a scope X for a name M from a program point P is a single search in X for M from P unless X is the scope of a class or class template T, in which case the following steps define the result of the search.
[Note 1: 
The result differs only if M is a conversion-function-id or if the single search would find nothing.
— end note]
2
#
The lookup set for a name N in a class or class template C, called S(N,C), consists of two component sets: the declaration set, a set of members named N; and the subobject set, a set of subobjects where declarations of these members were found (possibly via using-declarations).
In the declaration set, type declarations (including injected-class-names) are replaced by the types they designate.
S(N,C) is calculated as follows:
3
#
The declaration set is the result of a single search in the scope of C for N from immediately after the class-specifier of C if P is in a complete-class context of C or from P otherwise.
If the resulting declaration set is not empty, the subobject set contains C itself, and calculation is complete.
4
#
Otherwise (i.e., C does not contain a declaration of N or the resulting declaration set is empty), S(N,C) is initially empty.
Calculate the lookup set for N in each direct non-dependent ([temp.dep.type]) base class subobject , and merge each such lookup set in turn into S(N,C).
[Note 2: 
If C is incomplete, only base classes whose base-specifier appears before P are considered.
If C is an instantiated class, its base classes are not dependent.
— end note]
5
#
The following steps define the result of merging lookup set into the intermediate S(N,C):
  • (5.1)
    If each of the subobject members of is a base class subobject of at least one of the subobject members of S(N,C), or if is empty, S(N,C) is unchanged and the merge is complete.
    Conversely, if each of the subobject members of S(N,C) is a base class subobject of at least one of the subobject members of , or if S(N,C) is empty, the new S(N,C) is a copy of .
  • (5.2)
    Otherwise, if the declaration sets of and S(N,C) differ, the merge is ambiguous: the new S(N,C) is a lookup set with an invalid declaration set and the union of the subobject sets.
    In subsequent merges, an invalid declaration set is considered different from any other.
  • (5.3)
    Otherwise, the new S(N,C) is a lookup set with the shared set of declarations and the union of the subobject sets.
6
#
The result of the search is the declaration set of S(M,T).
If it is an invalid set, the program is ill-formed.
If it differs from the result of a search in T for M in a complete-class context ([class.mem]) of T, the program is ill-formed, no diagnostic required.
[Example 1: struct A { int x; }; // S(x,A) = { { A​::​x }, { A } } struct B { float x; }; // S(x,B) = { { B​::​x }, { B } } struct C: public A, public B { }; // S(x,C) = { invalid, { A in C, B in C } } struct D: public virtual C { }; // S(x,D) = S(x,C) struct E: public virtual C { char x; }; // S(x,E) = { { E​::​x }, { E } } struct F: public D, public E { }; // S(x,F) = S(x,E) int main() { F f; f.x = 0; // OK, lookup finds E​::​x }
S(x,F) is unambiguous because the A and B base class subobjects of D are also base class subobjects of E, so S(x,D) is discarded in the first merge step.
— end example]
7
#
If M is a non-dependent conversion-function-id, conversion function templates that are members of T are considered.
For each such template F, the lookup set S(t,T) is constructed, considering a function template declaration to have the name t only if it corresponds to a declaration of F ([basic.scope.scope]).
The members of the declaration set of each such lookup set, which shall not be an invalid set, are included in the result.
[Note 3: 
Overload resolution will discard those that cannot convert to the type specified by M ([temp.over]).
— end note]
8
#
[Note 4: 
A static member, a nested type or an enumerator defined in a base class T can unambiguously be found even if an object has more than one base class subobject of type T.
Two base class subobjects share the non-static member subobjects of their common virtual base classes.
— end note]
[Example 2: struct V { int v; }; struct A { int a; static int s; enum { e }; }; struct B : A, virtual V { }; struct C : A, virtual V { }; struct D : B, C { }; void f(D* pd) { pd->v++; // OK, only one v (virtual) pd->s++; // OK, only one s (static) int i = pd->e; // OK, only one e (enumerator) pd->a++; // error: ambiguous: two as in D } — end example]
9
#
[Note 5: 
When virtual base classes are used, a hidden declaration can be reached along a path through the subobject lattice that does not pass through the hiding declaration.
This is not an ambiguity.
The identical use with non-virtual base classes is an ambiguity; in that case there is no unique instance of the name that hides all the others.
— end note]
[Example 3: struct V { int f(); int x; }; struct W { int g(); int y; }; struct B : virtual V, W { int f(); int x; int g(); int y; }; struct C : virtual V, W { }; struct D : B, C { void glorp(); };
virt W1 W V V W2 W B B B->W1 B->V C C C->V C->W2 D D D->B D->C
Figure 1: Name lookup  [fig:class.lookup]
As illustrated in Figure 1, the names declared in V and the left-hand instance of W are hidden by those in B, but the names declared in the right-hand instance of W are not hidden at all.
void D::glorp() { x++; // OK, B​::​x hides V​::​x f(); // OK, B​::​f() hides V​::​f() y++; // error: B​::​y and C's W​::​y g(); // error: B​::​g() and C's W​::​g() } — end example]
10
#
An explicit or implicit conversion from a pointer to or an expression designating an object of a derived class to a pointer or reference to one of its base classes shall unambiguously refer to a unique object representing the base class.
[Example 4: struct V { }; struct A { }; struct B : A, virtual V { }; struct C : A, virtual V { }; struct D : B, C { }; void g() { D d; B* pb = &d; A* pa = &d; // error: ambiguous: C's A or B's A? V* pv = &d; // OK, only one V subobject } — end example]
11
#
[Note 6: 
Even if the result of name lookup is unambiguous, use of a name found in multiple subobjects might still be ambiguous ([conv.mem], [expr.ref], [class.access.base]).
— end note]
[Example 5: struct B1 { void f(); static void f(int); int i; }; struct B2 { void f(double); }; struct I1: B1 { }; struct I2: B1 { }; struct D: I1, I2, B2 { using B1::f; using B2::f; void g() { f(); // Ambiguous conversion of this f(0); // Unambiguous (static) f(0.0); // Unambiguous (only one B2) int B1::* mpB1 = &D::i; // Unambiguous int D::* mpD = &D::i; // Ambiguous conversion } }; — end example]

6.5.3 Unqualified name lookup [basic.lookup.unqual]

1
#
A using-directive is active in a scope S at a program point P if it precedes P and inhabits either S or the scope of a namespace nominated by a using-directive that is active in S at P.
2
#
An unqualified search in a scope S from a program point P includes the results of searches from P in
  • (2.1)
    S, and
  • (2.2)
    for any scope U that contains P and is or is contained by S, each namespace contained by S that is nominated by a using-directive that is active in U at P.
If no declarations are found, the results of the unqualified search are the results of an unqualified search in the parent scope of S, if any, from P.
[Note 1: 
When a class scope is searched, the scopes of its base classes are also searched ([class.member.lookup]).
If it inherits from a single base, it is as if the scope of the base immediately contains the scope of the derived class.
Template parameter scopes that are associated with one scope in the chain of parents are also considered ([temp.local]).
— end note]
3
#
Unqualified name lookup from a program point performs an unqualified search in its immediate scope.
4
#
An unqualified name is a name that does not immediately follow a nested-name-specifier or the . or -> in a class member access expression ([expr.ref]), possibly after a template keyword or ~.
Unless otherwise specified, such a name undergoes unqualified name lookup from the point where it appears.
5
#
An unqualified name that is a component name ([expr.prim.id.unqual]) of a type-specifier or ptr-operator of a conversion-type-id is looked up in the same fashion as the conversion-function-id in which it appears.
If that lookup finds nothing, it undergoes unqualified name lookup; in each case, only names that denote types or templates whose specializations are types are considered.
[Example 1: struct T1 { struct U { int i; }; }; struct T2 { }; struct U1 {}; struct U2 {}; struct B { using T = T1; using U = U1; operator U1 T1::*(); operator U1 T2::*(); operator U2 T1::*(); operator U2 T2::*(); }; template<class X, class T> int g() { using U = U2; X().operator U T::*(); // #1, searches for T in the scope of X first X().operator U decltype(T())::*(); // #2 return 0; } int x = g<B, T2>(); // #1 calls B​::​operator U1 T1​::​* // #2 calls B​::​operator U1 T2​::​* — end example]
6
#
In a friend declaration declarator whose declarator-id is a qualified-id whose lookup context ([basic.lookup.qual]) is a class or namespace S, lookup for an unqualified name that appears after the declarator-id performs a search in the scope associated with S.
If that lookup finds nothing, it undergoes unqualified name lookup.
[Example 2: using I = int; using D = double; namespace A { inline namespace N {using C = char; } using F = float; void f(I); void f(D); void f(C); void f(F); } struct X0 {using F = float; }; struct W { using D = void; struct X : X0 { void g(I); void g(::D); void g(F); }; }; namespace B { typedef short I, F; class Y { friend void A::f(I); // error: no void A​::​f(short) friend void A::f(D); // OK friend void A::f(C); // error: A​::​N​::​C not found friend void A::f(F); // OK friend void W::X::g(I); // error: no void X​::​g(short) friend void W::X::g(D); // OK friend void W::X::g(F); // OK }; } — end example]

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

1
#
When the postfix-expression in a function call ([expr.call]) is an unqualified-id, and unqualified lookup ([basic.lookup.unqual]) for the name in the unqualified-id does not find any
  • (1.1)
    declaration of a class member, or
  • (1.2)
    function declaration inhabiting a block scope, or
  • (1.3)
    declaration not of a function or function template
then lookup for the name also includes the result of argument-dependent lookup in a set of associated namespaces that depends on the types of the arguments (and for template template arguments, the namespace of the template argument), as specified below.
[Example 1: namespace N { struct S { }; void f(S); } void g() { N::S s; f(s); // OK, calls N​::​f (f)(s); // error: N​::​f not considered; parentheses prevent argument-dependent lookup } — end example]
2
#
[Note 1: 
For purposes of determining (during parsing) whether an expression is a postfix-expression for a function call, the usual name lookup rules apply.
In some cases a name followed by < is treated as a template-name even though name lookup did not find a template-name (see [temp.names]).
For example, int h; void g(); namespace N { struct A {}; template <class T> int f(T); template <class T> int g(T); template <class T> int h(T); } int x = f<N::A>(N::A()); // OK, lookup of f finds nothing, f treated as template name int y = g<N::A>(N::A()); // OK, lookup of g finds a function, g treated as template name int z = h<N::A>(N::A()); // error: h< does not begin a template-id
The rules 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, argument-dependent name lookup does not apply and the friend function f is not found.
— end note]
3
#
For each argument type T in the function call, there is a set of zero or more associated entities to be considered.
The set of entities is determined entirely by the types of the function arguments (and any template template arguments).
Any typedef-names and using-declarations used to specify the types do not contribute to this set.
The set of entities is determined in the following way:
  • (3.1)
    If T is a fundamental type, its associated set of entities is empty.
  • (3.2)
    If T is a class type (including unions), its associated entities are: the class itself; the class of which it is a member, if any; and, if it is a complete type, its direct and indirect base classes.
    Furthermore, if T is a class template specialization, its associated entities also include: the entities associated with the types of the template arguments provided for template type parameters; the templates used as template template arguments; and the classes of which any member templates used as template template arguments are members.
    [Note 2: 
    Non-type template arguments do not contribute to the set of associated entities.
    — end note]
  • (3.3)
    If T is an enumeration type, its associated entities are T and, if it is a class member, the member's class.
  • (3.4)
    If T is a pointer to U or an array of U, its associated entities are those associated with U.
  • (3.5)
    If T is a function type, its associated entities are those associated with the function parameter types and those associated with the return type.
  • (3.6)
    If T is a pointer to a member function of a class X, its associated entities are those associated with the function parameter types and return type, together with those associated with X.
  • (3.7)
    If T is a pointer to a data member of class X, its associated entities are those associated with the member type together with those associated with X.
In addition, if the argument is an overload set or the address of such a set, its associated entities are the union of those associated with each of the members of the set, i.e., the entities associated with its parameter types and return type.
Additionally, if the aforementioned overload set is named with a template-id, its associated entities also include its template template-arguments and those associated with its type template-arguments.
4
#
The associated namespaces for a call are the innermost enclosing non-inline namespaces for its associated entities as well as every element of the inline namespace set ([namespace.def]) of those namespaces.
Argument-dependent lookup finds all declarations of functions and function templates that
  • (4.1)
    are found by a search of any associated namespace, or
  • (4.2)
    are declared as a friend ([class.friend]) of any class with a reachable definition in the set of associated entities, or
  • (4.3)
    are exported, are attached to a named module M ([module.interface]), do not appear in the translation unit containing the point of the lookup, and have the same innermost enclosing non-inline namespace scope as a declaration of an associated entity attached to M ([basic.link]).
If the lookup is for a dependent name ([temp.dep], [temp.dep.candidate]), the above lookup is also performed from each point in the instantiation context ([module.context]) of the lookup, additionally ignoring any declaration that appears in another translation unit, is attached to the global module, and is either discarded ([module.global.frag]) or has internal linkage.
5
#
[Example 2: 

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
#
[Note 3: 
The associated namespace can include namespaces already considered by ordinary unqualified lookup.
— end note]
[Example 3: 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]

6.5.5 Qualified name lookup [basic.lookup.qual]

6.5.5.1 General [basic.lookup.qual.general]

1
#
Lookup of an identifier followed by a ​::​ scope resolution operator considers only namespaces, types, and templates whose specializations are types.
If a name, template-id, or computed-type-specifier is followed by a ​::​, it shall designate a namespace, class, enumeration, or dependent type, and the ​::​ is never interpreted as a complete nested-name-specifier.
[Example 1: class A { public: static int n; }; int main() { int A; A::n = 42; // OK A b; // error: A does not name a type } template<int> struct B : A {}; namespace N { template<int> void B(); int f() { return B<0>::n; // error: N​::​B<0> is not a type } } — end example]
2
#
A member-qualified name is the (unique) component name ([expr.prim.id.unqual]), if any, of in the id-expression of a class member access expression ([expr.ref]).
The lookup context of a member-qualified name is the type of its associated object expression (considered dependent if the object expression is type-dependent).
The lookup context of any other qualified name is the type, template, or namespace nominated by the preceding nested-name-specifier.
[Note 1: 
When parsing a class member access, the name following the -> or . is a qualified name even though it is not yet known of which kind.
— end note]
[Example 2: 
In N::C::m.Base::f() Base is a member-qualified name; the other qualified names are C, m, and f.
— end example]
3
#
Qualified name lookup in a class, namespace, or enumeration performs a search of the scope associated with it ([class.member.lookup]) except as specified below.
Unless otherwise specified, a qualified name undergoes qualified name lookup in its lookup context from the point where it appears unless the lookup context either is dependent and is not the current instantiation ([temp.dep.type]) or is not a class or class template.
If nothing is found by qualified lookup for a member-qualified name that is the terminal name ([expr.prim.id.unqual]) of a nested-name-specifier and is not dependent, it undergoes unqualified lookup.
[Note 2: 
During lookup for a template specialization, no names are dependent.
— end note]
[Example 3: int f(); struct A { int B, C; template<int> using D = void; using T = void; void f(); }; using B = A; template<int> using C = A; template<int> using D = A; template<int> using X = A; template<class T> void g(T *p) { // as instantiated for g<A>: p->X<0>::f(); // error: A​::​X not found in ((p->X) < 0) > ​::​f() p->template X<0>::f(); // OK, ​::​X found in definition context p->B::f(); // OK, non-type A​::​B ignored p->template C<0>::f(); // error: A​::​C is not a template p->template D<0>::f(); // error: A​::​D<0> is not a class type p->T::f(); // error: A​::​T is not a class type } template void g(A*); — end example]
4
#
If a qualified name Q follows a ~:
  • (4.1)
    If Q is a member-qualified name, it undergoes unqualified lookup as well as qualified lookup.
  • (4.2)
    Otherwise, its nested-name-specifier N shall nominate a type.
    If N has another nested-name-specifier S, Q is looked up as if its lookup context were that nominated by S.
  • (4.3)
    Otherwise, if the terminal name of N is a member-qualified name M, Q is looked up as if ~Q appeared in place of M (as above).
  • (4.4)
    Otherwise, Q undergoes unqualified lookup.
  • (4.5)
    Each lookup for Q considers only types (if Q is not followed by a <) and templates whose specializations are types.
    If it finds nothing or is ambiguous, it is discarded.
  • (4.6)
    The type-name that is or contains Q shall refer to its (original) lookup context (ignoring cv-qualification) under the interpretation established by at least one (successful) lookup performed.
[Example 4: struct C { typedef int I; }; typedef int I1, I2; extern int* p; extern int* q; void f() { p->C::I::~I(); // I is looked up in the scope of C q->I1::~I2(); // I2 is found by unqualified lookup } struct A { ~A(); }; typedef A AB; int main() { AB* p; p->AB::~AB(); // explicitly calls the destructor for A } — end example]

6.5.5.2 Class members [class.qual]

1
#
In a lookup for a qualified name N whose lookup context is a class C in which function names are not ignored,19 N is instead considered to name the constructor of class C.
Such a constructor name shall be used only in the declarator-id of a (friend) declaration of a constructor or in a using-declaration.
[Example 1: struct A { A(); }; struct B: public A { B(); }; A::A() { } B::B() { } B::A ba; // object of type A A::A a; // error: A​::​A is not a type name struct A::A a2; // object of type A — end example]
19)19)
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.5.3 Namespace members [namespace.qual]

1
#
Qualified name lookup in a namespace N additionally searches every element of the inline namespace set of N ([namespace.def]).
If nothing is found, the results of the lookup are the results of qualified name lookup in each namespace nominated by a using-directive that precedes the point of the lookup and inhabits N or an element of N's inline namespace set.
[Note 1: 
If a using-directive refers to a namespace that has already been considered, it does not affect the result.
— end note]
[Example 1: int x; namespace Y { void f(float); void h(int); } namespace Z { void h(double); } namespace A { using namespace Y; void f(int); void g(int); int i; } namespace B { using namespace Z; void f(char); int i; } namespace AB { using namespace A; using namespace B; void g(); } void h() { AB::g(); // g is declared directly in AB, therefore S is { AB​::​g() } and AB​::​g() is chosen AB::f(1); // f is not declared directly in AB so the rules are applied recursively to A and B; // namespace Y is not searched and Y​::​f(float) is not considered; // S is { A​::​f(int), B​::​f(char) } 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 { A​::​i, B​::​i } 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 { Y​::​h(int), Z​::​h(double) } and // overload resolution chooses Z​::​h(double) } — end example]
2
#
[Note 2: 
The same declaration found more than once is not an ambiguity (because it is still a unique declaration).
[Example 2: namespace A { int a; } namespace B { using namespace A; } namespace C { using namespace A; } namespace BC { using namespace B; using namespace C; } void f() { BC::a++; // OK, S is { A​::​a, A​::​a } } namespace D { using A::a; } namespace BD { using namespace B; using namespace D; } void g() { BD::a++; // OK, S is { A​::​a, A​::​a } } — end example]
— end note]
3
#
[Example 3: 
Because each referenced namespace is searched at most once, the following is well-defined: namespace B { int b; } namespace A { using namespace B; int a; } namespace B { using namespace A; } void f() { A::a++; // OK, a declared directly in A, S is { A​::​a } B::a++; // OK, both A and B searched (once), S is { A​::​a } A::b++; // OK, both A and B searched (once), S is { B​::​b } B::b++; // OK, b declared directly in B, S is { B​::​b } }
— end example]
4
#
[Note 3: 
Class and enumeration declarations are not discarded because of other declarations found in other searches.
— end note]
[Example 4: namespace A { struct x { }; int x; int y; } namespace B { struct y { }; } namespace C { using namespace A; using namespace B; int i = C::x; // OK, A​::​x (of type int) int j = C::y; // ambiguous, A​::​y or B​::​y } — end example]

6.5.6 Elaborated type specifiers [basic.lookup.elab]

1
#
If the class-key or enum keyword in an elaborated-type-specifier is followed by an identifier that is not followed by ​::​, lookup for the identifier is type-only ([basic.lookup.general]).
[Note 1: 
In general, the recognition of an elaborated-type-specifier depends on the following tokens.
If the identifier is followed by ​::​, see [basic.lookup.qual].
— end note]
2
#
If the terminal name of the elaborated-type-specifier is a qualified name, lookup for it is type-only.
If the name lookup does not find a previously declared type-name, the elaborated-type-specifier is ill-formed.
3
#
[Example 1: struct Node { struct Node* Next; // OK, refers to injected-class-name Node struct Data* Data; // OK, declares type Data at global scope and member Data }; struct Data { struct Node* Node; // OK, refers to Node at global scope friend struct ::Glob; // error: Glob is not declared, cannot introduce a qualified type ([dcl.type.elab]) friend struct Glob; // OK, refers to (as yet) undeclared Glob at global scope. /* ... */ }; struct Base { struct Data; // OK, declares nested Data struct ::Data* thatData; // OK, refers to ​::​Data struct Base::Data* thisData; // OK, refers to nested Data friend class ::Data; // OK, global Data is a friend friend class Data; // OK, nested Data is a friend struct Data { /* ... */ }; // Defines nested Data }; struct Data; // OK, redeclares Data at global scope struct ::Data; // error: cannot introduce a qualified type ([dcl.type.elab]) struct Base::Data; // error: cannot introduce a qualified type ([dcl.type.elab]) struct Base::Datum; // error: Datum undefined struct Base::Data* pBase; // OK, refers to nested Data — end example]

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

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

6.7 Memory and objects [basic.memobj]

6.7.1 Memory model [intro.memory]

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

6.7.2 Object model [intro.object]

1
#
The constructs in a C++ program create, destroy, refer to, access, and manipulate objects.
An object is created by a definition, by a new-expression ([expr.new]), by an operation that implicitly creates objects (see below), when implicitly changing the active member of a union, or when a temporary object is created ([conv.rval], [class.temporary]).
An object occupies a region of storage in its period of construction ([class.cdtor]), throughout its lifetime, and in its period of destruction ([class.cdtor]).
[Note 1: 
A function is not an object, regardless of whether or not it occupies storage in the way that objects do.
— end note]
The properties of an object are determined when the object is created.
An object can have a name ([basic.pre]).
An object has a storage duration ([basic.stc]) which influences its lifetime ([basic.life]).
An object has a type ([basic.types]).
[Note 2: 
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.
— end note]
2
#
Objects can contain other objects, called subobjects.
A subobject can be a member subobject ([class.mem]), a base class subobject ([class.derived]), or an array element.
An object that is not a subobject of any other object is called a complete object.
If an object is created in storage associated with a member subobject or array element e (which may or may not be within its lifetime), the created object is a subobject of e's containing object if
  • (2.1)
    the lifetime of e's containing object has begun and not ended, and
  • (2.2)
    the storage for the new object exactly overlays the storage location associated with e, and
  • (2.3)
    the new object is of the same type as e (ignoring cv-qualification).
3
#
If a complete object is created ([expr.new]) in storage associated with another object e of type “array of N unsigned char” or of type “array of N std​::​byte” ([cstddef.syn]), that array provides storage for the created object if
  • (3.1)
    the lifetime of e has begun and not ended, and
  • (3.2)
    the storage for the new object fits entirely within e, and
  • (3.3)
    there is no array object that satisfies these constraints nested within e.
[Note 3: 
If that portion of the array previously provided storage for another object, the lifetime of that object ends because its storage was reused ([basic.life]).
— end note]
[Example 1: // assumes that sizeof(int) is equal to 4 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]; }; alignas(int) A a; B *b = new (a.a + 8) B; // a.a provides storage for *b int *p = new (b->b + 4) int; // b->b provides storage for *p // a.a does not provide storage for *p (directly), // but *p is nested within a (see below) — end example]
4
#
An object a is nested within another object b if
  • (4.1)
    a is a subobject of b, or
  • (4.2)
    b provides storage for a, or
  • (4.3)
    there exists an object c where a is nested within c, and c is nested within b.
5
#
For every object x, there is some object called the complete object of x, determined as follows:
  • (5.1)
    If x is a complete object, then the complete object of x is itself.
  • (5.2)
    Otherwise, the complete object of x is the complete object of the (unique) object that contains x.
6
#
If a complete object, a member subobject, or an array element is of class type, its type is considered the most derived class, to distinguish it from the class type of any base class subobject; an object of a most derived class type or of a non-class type is called a most derived object.
7
#
A potentially-overlapping subobject is either:
8
#
An object has nonzero size if it
  • (8.1)
    is not a potentially-overlapping subobject, or
  • (8.2)
    is not of class type, or
  • (8.3)
    is of a class type with virtual member functions or virtual base classes, or
  • (8.4)
    has subobjects of nonzero size or unnamed bit-fields of nonzero length.
Otherwise, if the object is a base class subobject of a standard-layout class type with no non-static data members, it has zero size.
Otherwise, the circumstances under which the object has zero size are implementation-defined.
Unless it is a bit-field, an object with nonzero size shall occupy one or more bytes of storage, including every byte that is occupied in full or in part by any of its subobjects.
An object of trivially copyable or standard-layout type ([basic.types.general]) shall occupy contiguous bytes of storage.
9
#
An object is a potentially non-unique object if it is a string literal object ([lex.string]), the backing array of an initializer list ([dcl.init.ref]), or a subobject thereof.
10
#
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
  • (10.1)
    one is nested within the other,
  • (10.2)
    at least one is a subobject of zero size and they are not of similar types ([conv.qual]), or
  • (10.3)
    they are both potentially non-unique objects;
otherwise, they have distinct addresses and occupy disjoint bytes of storage.21
[Example 2: static const char test1 = 'x'; static const char test2 = 'x'; const bool b = &test1 != &test2; // always true static const char (&r) [] = "x"; static const char *s = "x"; static std::initializer_list<char> il = { 'x' }; const bool b2 = r != il.begin(); // unspecified result const bool b3 = r != s; // unspecified result const bool b4 = il.begin() != &test1; // always true const bool b5 = r != &test1; // 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.
11
#
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.general]) 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 4: 
Such operations do not start the lifetimes of subobjects of such objects that are not themselves of implicit-lifetime types.
— end note]
12
#
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.
13
#
[Example 3: #include <cstdlib> struct X { int a, b; }; X *make_x() { // The call to std​::​malloc implicitly creates an object of type X // and its subobjects a and b, and returns a pointer to that X object // (or an object that is pointer-interconvertible ([basic.compound]) with it), // in order to give the subsequent class member access operations // defined behavior. X *p = (X*)std::malloc(sizeof(struct X)); p->a = 1; p->b = 2; return p; } — end example]
14
#
Except during constant evaluation, an operation that begins the lifetime of an array of unsigned char or std​::​byte implicitly creates objects within the region of storage occupied by the array.
[Note 5: 
The array object provides storage for these objects.
— end note]
Except during constant evaluation, 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 6: 
Some functions in the C++ standard library implicitly create objects ([obj.lifetime], [c.malloc], [mem.res.public], [bit.cast], [cstring.syn]).
— end note]
21)21)
Under the “as-if” rule an implementation is allowed to store two objects at the same machine address or not store an object at all if the program cannot observe the difference ([intro.execution]).

6.7.3 Lifetime [basic.life]

1
#
The lifetime of an object or reference is a runtime property of the object or reference.
A variable is said to have vacuous initialization if it is default-initialized, no other initialization is performed, and, if it is of class type or a (possibly multidimensional) array thereof, a trivial constructor of that class type is selected for the default-initialization.
The lifetime of an object of type T begins when:
  • (1.1)
    storage with the proper alignment and size for type T is obtained, and
  • (1.2)
    its initialization (if any) is complete (including vacuous initialization) ([dcl.init]),
except that if the object is a union member or subobject thereof, its lifetime only begins if that union member is the initialized member in the union ([dcl.init.aggr], [class.base.init]), or as described in [class.union], [class.copy.ctor], and [class.copy.assign], and except as described in [allocator.members].
The lifetime of an object o of type T ends when:
  • (1.3)
    if T is a non-class type, the object is destroyed, or
  • (1.4)
    if T is a class type, the destructor call starts, or
  • (1.5)
    the storage which the object occupies is released, or is reused by an object that is not nested within o ([intro.object]).
When evaluating a new-expression, storage is considered reused after it is returned from the allocation function, but before the evaluation of the new-initializer ([expr.new]).
[Example 1: struct S { int m; }; void f() { S x{1}; new(&x) S(x.m); // undefined behavior } — end example]
2
#
The lifetime of a reference begins when its initialization is complete.
The lifetime of a reference ends as if it were a scalar object requiring storage.
3
#
[Note 1: 
[class.base.init] describes the lifetime of base and member subobjects.
— end note]
4
#
The properties ascribed to objects and references throughout this document apply for a given object or reference only during its lifetime.
[Note 2: 
In particular, before the lifetime of an object starts and after its lifetime ends there are significant restrictions on the use of the object, as described below, in [class.base.init], and in [class.cdtor].
Also, the behavior of an object under construction and destruction can differ from the behavior of an object whose lifetime has started and not ended.
[class.base.init] and [class.cdtor] describe the behavior of an object during its periods of construction and destruction.
— end note]
5
#
A program may end the lifetime of an object of class type without invoking the destructor, by reusing or releasing the storage as described above.
[Note 3: 
A