Standard conversions

Lvalue-to-rvalue conversion

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Array-to-pointer conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Function-to-pointer conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Qualification conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Integral promotions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Floating point promotion

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Integral conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Floating point conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Floating-integral conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Pointer conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Pointer to member conversions

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Boolean conversions

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Integer conversion rank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Expressions

Primary expressions

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Postfix expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Unary expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Explicit type conversion (cast notation)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Pointer-to-member operators

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Multiplicative operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Additive operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Shift operators

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Relational operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Equality operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Bitwise AND operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Bitwise exclusive OR operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Bitwise inclusive OR operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Logical AND operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Logical OR operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Conditional operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Assignment and compound assignment operators . . . . . . . . . . . . . . . . . . . . . . . .

Comma operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Constant expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Statements

Labeled statement

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Expression statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Compound statement or block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Selection statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Iteration statements

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Jump statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Declaration statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Ambiguity resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Declarations

Specifiers

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Enumeration declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

iii

The

asm

declaration

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Linkage specifications

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Declarators

Type names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Ambiguity resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Meaning of declarators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Function definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Initializers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Classes

Class names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Class members

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Member functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Static members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Unions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Bit-fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Nested class declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Local class declarations

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Nested type names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Multiple base classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Member name lookup

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Virtual functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Abstract classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Access specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Accessibility of base classes and base class members . . . . . . . . . . . . . . . . . . . . . . .

Access declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Friends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Protected member access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Access to virtual functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Multiple access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Nested classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Constructors

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Temporary objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Destructors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Free store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Construction and destruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Copying and moving class objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Inheriting Constructors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

iv

Declaration matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Overload resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Address of overloaded function

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Overloaded operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Built-in operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Template parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Names of template specializations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Template arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Type equivalence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Template declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Name resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Template instantiation and specialization

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

Function template specializations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Throwing an exception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Constructors and destructors

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Handling an exception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exception specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Special functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Conditional inclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Source file inclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Macro replacement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Line control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Error directive

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Pragma directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Null directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Predefined macro names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Pragma operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

General

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

The C standard library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Additional definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Method of description (Informative)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Library-wide requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

General

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Types

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Implementation properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Integer types

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Start and termination

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Dynamic memory management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Type identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

v

Initializer lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

General

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exception classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Error numbers

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

System error support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

General

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Utility components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Tuples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Class template

bitset

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Compile-time rational arithmetic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Metaprogramming and type traits

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Function objects

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

scoped_allocator

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

type_index

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

General

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Character traits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

String classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Class template

basic_string

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Numeric Conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Hash support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Null-terminated sequence utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

General

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Header

<locale>

synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Locales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Standard

locale

categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Standard code conversion facets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C Library Locales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

General

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Container requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Sequence containers

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Container adaptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Container adaptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Associative containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Unordered associative containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

vi

General

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Iterator requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Header

<iterator>

synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Iterator primitives

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Iterator adaptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Stream iterators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

General

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Non-modifying sequence operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Mutating sequence operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Sorting and related operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C library algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

General

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Numeric type requirements

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

The floating-point environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Complex numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Random number generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Numeric arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Generalized numeric operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

General

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Iostreams requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Forward declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Standard iostream objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Iostreams base classes

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Stream buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Formatting and manipulators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

String-based streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

File-based streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

General

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Header

<regex>

synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Namespace

std::regex_constants

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Class

regex_error

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Class template

regex_traits

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Class template

basic_regex

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Class template

sub_match

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

match_results

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

vii

General

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Header

<atomic>

synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Order and Consistency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Lock-free Property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Atomic Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Operations on Atomic Types

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Flag Type and Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Fences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

General

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Mutual exclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Condition variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Futures

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Lexical conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Basic concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Statements

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Declarators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Derived classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Special member functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Overloading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exception handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Preprocessing directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C

++

and ISO C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Standard C library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Increment operator with

bool

operand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

static

keyword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Access declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

register

keyword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Dynamic exception specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C standard library headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Old iostreams members

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

char*

streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Binders

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

auto_ptr

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

viii

ix

Alternative tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Alternative representations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Types of integer constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Escape sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

String literal concatenations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Relations on

const

and

volatile

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

simple-type-specifier

s and the types they specify

. . . . . . . . . . . . . . . . . . . . . . . . . . .

Relationship between operator and function call notation

. . . . . . . . . . . . . . . . . . . . . .

Conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Library categories

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C

++

library headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C

++

headers for C library facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C

++

headers for freestanding implementations

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

Language support library summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Header

<cstddef>

synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Header

<climits>

synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Header

<cfloat>

synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Header

<cstdlib>

synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Header

<cstdarg>

synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Header

<csetjmp>

synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Header

<ctime>

synopsis

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Header

<csignal>

synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Header

<cstdlib>

synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Header

<cstdbool>

synopsis

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Diagnostics library summary

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Header

<cassert>

synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Header

<cerrno>

synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

General utilities library summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

EqualityComparable

requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

LessThanComparable

requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

DefaultConstructible

requirements

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

MoveConstructible

requirements

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

CopyConstructible

requirements (in addition to MoveConstructible) . . . . . . . . . . . . . . .

MoveAssignable

requirements

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

CopyAssignable

requirements(in addition to MoveAssignable) . . . . . . . . . . . . . . . . . . .

Destructible

requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

NullablePointer

requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

List of Tables

x

Descriptive variable definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Allocator requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Primary type category predicates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Composite type category predicates

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Type property predicates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Type property queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Type relationship predicates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Const-volatile modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Reference modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Sign modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Array modifications

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Pointer modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Other transformations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Header

<cstdlib>

synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Header

<cstring>

synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Clock requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Header

<ctime>

synopsis

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Strings library summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Character traits requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

basic_string(const Allocator&)

effects

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

basic_string(const basic_string&)

effects

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

basic_string(const basic_string&, size_type, size_type, const Allocator&)

effects

.

basic_string(const charT*, size_type, const Allocator&)

effects . . . . . . . . . . . . . .

basic_string(const charT*, const Allocator&)

effects . . . . . . . . . . . . . . . . . . . . .

basic_string(size_t, charT, const Allocator&)

effects . . . . . . . . . . . . . . . . . . . .

basic_string(const basic_string&, const Allocator&)

and

basic_string(basic_string&&,

const Allocator&)

effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

operator=(const basic_string<charT, traits, Allocator>&)

effects . . . . . . . . . . . . .

operator=(const basic_string<charT, traits, Allocator>&&)

effects . . . . . . . . . . . .

compare()

results

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Potential

mbstate_t

data races . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Header

<cctype>

synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Header

<cwctype>

synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Header

<cstring>

synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Header

<cwchar>

synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Header

<cstdlib>

synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Header

<cuchar>

synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Localization library summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Locale category facets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Required specializations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

do_in/do_out

result values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

do_unshift

result values

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Integer conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Length modifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Integer conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Floating-point conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Length modifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Numeric conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

List of Tables

xi

do_get_date

effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Header

<clocale>

synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Potential

setlocale

data races . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Containers library summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Container requirements

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Reversible container requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Optional container operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Allocator-aware container requirements

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Sequence container requirements (in addition to container)

. . . . . . . . . . . . . . . . . . . . .

Optional sequence container operations

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Associative container requirements (in addition to container) . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

<cstdlib>

synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

<cmath>

synopsis

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

<cstdlib>

synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

fmtflags

effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

fmtflags

constants

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

iostate

effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

openmode

effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

seekdir

effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

basic_ios::init()

effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

basic_ios::copyfmt()

effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

seekoff

positioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

newoff

values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

seekoff

effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

<cstdio>

synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

<cinttypes>

synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

List of Tables

xii

syntax_option_type

effects

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

regex_constants::match_flag_type

effects when obtaining a match against a character con-

tainer sequence

[first,last)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

error_type

values in the C locale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

match_results

assignment operator effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

regex_match

algorithm

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

regex_search

algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

strstreambuf(streamsize)

effects

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

strstreambuf(void* (*)(size_t), void (*)(void*))

effects . . . . . . . . . . . . . . . . . .

strstreambuf(charT*, streamsize, charT*)

effects . . . . . . . . . . . . . . . . . . . . . . . .

seekoff

positioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

newoff

values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

List of Tables

xiii

Directed acyclic graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Non-virtual base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Virtual base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Virtual and non-virtual base

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Name lookup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Stream position, offset, and size types [non-normative] . . . . . . . . . . . . . . . . . . . . . . . .

List of Figures

xiv

[GB 3]

Terms that are used only in a small portion of this International Standard are defined where they are used
and italicized where they are defined.

1.3.1

[defns.argument]

argument

actual argument
actual parameter
<function call expression> expression in the comma-separated list bounded by the parentheses

1.3.2

[defns.argument.macro]

argument

actual argument
actual parameter
<function-like macro> sequence of preprocessing tokens in the comma-separated list bounded by the paren-
theses

1.3.3

[defns.argument.throw]

argument

actual argument
actual parameter
<throw expression> the operand of

throw

1.3.4

[defns.argument.templ]

argument

actual argument
actual parameter
<template instantiation> expression,

type-id

or

template-name

in the comma-separated list bounded by the

angle brackets

1.3.5

[defns.cond.supp]

conditionally-supported

[ITTF 5] a

program construct that an implementation is not required to support

1)

With the qualifications noted in Clauses

standard

library.

§ 1.3

2

Example:

whose static type is “pointer to class

B

” is pointing to an object of class

D

, derived from

B

(Clause

is “

D

— end example

]

1.3.8

[defns.dynamic.type.prvalue]

dynamic type

<prvalue> static type of the prvalue expression

1.3.9

[defns.ill.formed]

ill-formed program

[ITTF 5] a

program that is not well formed

1.3.10

[defns.impl.defined]

implementation-defined behavior

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

1.3.11

[defns.impl.limits]

implementation limits

restrictions imposed upon programs by the implementation

1.3.12

[defns.locale.specific]

locale-specific behavior

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

1.3.13

[defns.multibyte]

multibyte character

[ITTF 5] a

sequence of one or more bytes representing a member of the extended character set of either the

source or the execution environment
[

Note:

]

1.3.14

[defns.parameter]

parameter

formal argument

§ 1.3

3

Note:

Signatures are used as a basis for name mangling and linking.

— end note

]

1.3.18

[defns.signature.templ]

signature

1.3.19

[defns.signature.spec]

signature

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

1.3.20

[defns.signature.member]

signature

-

qualifiers (if any), and

ref-qualifier

(if any)

1.3.21

[defns.signature.member.templ]

signature

-qualifiers (if any),

ref-qualifier

(if any), return type, and template parameter list

1.3.22

[defns.signature.member.spec]

signature

§ 1.3

4

Note:

The static type of an expression depends only on the form of the program in which the expression

appears, and does not change while the program is executing.

— end note

]

1.3.24

[defns.undefined]

undefined behavior

behavior for which this International Standard imposes no requirements
[

Note:

Undefined behavior may be expected when this International Standard omits any explicit definition of

behavior or when a program uses an erroneous construct or erroneous data. Permissible undefined behavior
ranges from ignoring the situation completely with unpredictable results, to behaving during translation or
program execution in a documented manner characteristic of the environment (with or without the issuance of
a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).
Many erroneous program constructs do not engender undefined behavior; they are required to be diagnosed.

— end note

]

1.3.25

[defns.unspecified]

unspecified behavior

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

Note:

The implementation is not required to document which behavior occurs. The range of possible

behaviors is usually delineated by this International Standard.

— end note

]

1.3.26

[defns.well.formed]

well-formed program

[ITTF 5] a

C

++

program constructed according to the syntax rules, diagnosable semantic rules, and the One

Implementation compliance

[intro.compliance]

1

The set of

diagnosable rules

consists of all syntactic and semantic rules in this International Standard 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 International Standard states only requirements on C

++

implementations, those requirements

are often easier to understand if they are phrased as requirements on programs, parts of programs, or
execution of programs. Such requirements have the following meaning:

— If a program contains no violations of the rules in this International Standard, a conforming imple-

mentation shall, within its resource limits, accept and correctly execute

2

that program.

— If a program contains a violation of any diagnosable rule or an occurrence of a construct described in

this Standard as “conditionally-supported” when the implementation does not support that construct,
a conforming implementation shall issue at least one diagnostic message.

2)

“Correct execution” can include undefined behavior, depending on the data being processed; see

5

4

For functions, function templates, objects, and values, the library Clauses specify declarations. Implemen-
tations shall supply definitions consistent with the descriptions in the library Clauses.

5

++

Two kinds of implementations are defined:

hosted

and

freestanding

. For a hosted implementation, this

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 International Standard. Having done so, however,
they can compile and execute such programs.

9

Each implementation shall include documentation that identifies all conditionally-supported constructs that
it does not support and defines all locale-specific characteristics.

3

1.5

Structure of this International Standard

[intro.structure]

1

Clauses

++

programming language. That description includes detailed syntactic

specifications in a form described in

2

Clauses

library clauses

) describe the Standard C

++

library. That description

includes detailed descriptions of the templates, classes, functions, constants, and macros that constitute the
library, in a form described in Clause

Annex

4

Annex

++

since its first published description, and explains in detail the

differences between C

++

and C. Certain features of C

++

exist solely for compatibility purposes; Annex

5

Throughout this International Standard, each example is introduced by “[

Example:

” and terminated by

“

— end example

]”. Each note is introduced by “[

Note:

” and terminated by “

— end note

]”. Examples and

notes may be nested.

1.6

Syntax notation

[syntax]

1

In the syntax notation used in this International Standard, syntactic categories are indicated by

italic

type,

and literal words and characters in

constant width

type. Alternatives are listed on separate lines except in

a few cases where a long set of alternatives is marked by the phrase “one of.” If the text of an alternative is

3)

This documentation also defines implementation-defined behavior; see

6

low-order bit

; the most significant bit is called the

high-order

bit

. The memory available to a C

++

program consists of one or more sequences of contiguous bytes. Every

byte has a unique address.

2

[

Note:

the representation of types is described in

]

3

A

memory location

is either an object of scalar type or a maximal sequence of adjacent bit-fields all having

non-zero width. [

Note:

Various features of the language, such as references and virtual functions, might

involve additional memory locations that are not accessible to programs but are managed by the imple-
mentation.

— end note

4

[

Note:

Thus a bit-field and an adjacent non-bit-field are in separate memory locations, and therefore can be

concurrently updated by two threads of execution without interference. The same applies to two bit-fields,
if one is declared inside a nested struct declaration and the other is not, or if the two are separated by
a zero-length bit-field declaration, or if they are separated by a non-bit-field declaration. It is not safe to
concurrently update two bit-fields in the same struct if all fields between them are also bit-fields of non-zero
width.

— end note

]

5

[

Example:

A structure declared as

struct {

char a;
int b:5,
c:11,
:0,
d:8;
struct {int ee:8;} e;

}

contains four separate memory locations: The field

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

§ 1.7

7

name

(Clause

lifetime

refers to the type with which the object

is created. Some objects are

polymorphic

expression

s (Clause

2

Objects can contain other objects, called

subobjects

. A subobject can be a

member subobject

class subobject

(Clause

complete object

.

3

For every object

x

, there is some object called

the complete object of

x

, determined as follows:

— If

x

is a complete object, then

x

is the complete object of

x

.

— Otherwise, the complete object of

x

is the complete object of the (unique) object that contains

x

.

4

, 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

.

5

Unless an object is a bit-field or a base class subobject of zero size, the address of that object is the address
of the first byte it occupies. Two distinct objects that are neither bit-fields nor base class subobjects of zero
size shall have distinct addresses.

4

[

Example:

static const char test1 = ’x’;
static const char test2 = ’x’;
const bool b = &test1 != &test2;

// always true

— end example

]

7

[

Note:

C

++

provides a variety of built-in types and several ways of composing new types from existing

]

1.9

Program execution

[intro.execution]

1

The semantic descriptions in this International Standard define a parameterized nondeterministic abstract
machine. This International Standard 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

4)

Under the “as-if” rule an implementation is allowed to store two objects at the same machine address or not store an

8

7

8

The least requirements on a conforming implementation are:

— Access to volatile objects are evaluated strictly according to the rules of the abstract machine.

— At program termination, all data written into files shall be identical to one of the possible results that

execution of the program according to the abstract semantics would have produced.

— The input and output dynamics of interactive devices shall take place in such a fashion that prompting

output is actually delivered before a program waits for input. What constitutes an interactive device
is implementation-defined.

These collectively are referred to as the

observable behavior

of the program. [

Note:

more stringent corre-

spondences between abstract and actual semantics may be defined by each implementation.

— end note

]

5)

This provision is sometimes called the “as-if” rule, because an implementation is free to disregard any requirement of this

International Standard 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)

This documentation also includes conditonally-supported constructs and locale-specific behavior. See

9

— end note

]

12

Accessing an object designated by a

volatile

side effects

, which are changes in the

state of the execution environment.

Evaluation

of an expression (or a sub-expression) in general includes

both value computations (including determining the identity of an object for glvalue evaluation and fetching
a value previously assigned to an object for prvalue evaluation) and initiation of side effects. When a call
to a library I/O function returns or an access to a

volatile

object is evaluated the side effect is considered

complete, even though some external actions implied by the call (such as the I/O itself) or by the

volatile

access may not have completed yet.

13

Sequenced before

is an asymmetric, transitive, pair-wise relation between evaluations executed by a single

and

B

, if

A

is sequenced before

B

, then the execution of

A

shall precede the execution of

B

. If

A

is not sequenced before

B

and

B

is not sequenced before

A

, then

A

and

B

are

unsequenced

. [

Note:

The execution of unsequenced

evaluations can overlap.

— end note

] Evaluations

A

and

B

are

indeterminately sequenced

when either

A

is sequenced before

B

or

B

is sequenced before

A

, but it is unspecified which. [

Note:

Indeterminately

sequenced evaluations cannot overlap, but either could be executed first.

— end note

]

14

Every value computation and side effect associated with a full-expression is sequenced before every value
computation and side effect associated with the next full-expression to be evaluated.

8

.

15

Except where noted, evaluations of operands of individual operators and of subexpressions of individual
expressions are unsequenced. [

Note:

In an expression that is evaluated more than once during the execution

of a program, unsequenced and indeterminately sequenced evaluations of its subexpressions need not be
performed consistently in different evaluations.

— end note

] The value computations of the operands of an

operator are sequenced before the value computation of the result of the operator. If a side effect on a scalar
object is unsequenced relative to either another side effect on the same scalar object or a value computation
using the value of the same scalar object, the behavior is undefined.

[

Example:

void f(int, int);
void g(int i, int* v) {

i = v[i++];

// the behavior is undefined

i = 7, i++, i++;

//

i

becomes

9

i = i++ + 1;

// the behavior is undefined

i = i + 1;

// the value of

i

is incremented

f(i = -1, i = -1);

// the behavior is undefined

}

— end example

]

8)

As specified in

§ 1.9

11

] The sequencing constraints on the execution of the called function (as described above)

are features of the function calls as evaluated, whatever the syntax of the expression that calls the function
might be.

1.10

Multi-threaded executions and data races

[intro.multithread]

1

A

thread of execution

(also known as a

thread

) is a single flow of control within a program, including the initial

invocation of a specific top-level function, and recursively including every function invocation subsequently
executed by the thread. [

Note:

when one thread creates another, the initial call to the top-level function of

the new thread is executed by the new thread, not by the creating thread.

— end note

] Every thread in a

program can potentially access every object and function in a program.

10

Under a hosted implementation, a

C

++

program can have more than one thread running concurrently. The execution of each thread proceeds

as defined by the remainder of this standard. The execution of the entire program consists of an execution of
all of its threads. [

Note:

Usually the execution can be viewed as an interleaving of all its threads. However,

some kinds of atomic operations, for example, allow executions inconsistent with a simple interleaving, as
described below.

— end note

] Under a freestanding implementation, it is implementation-defined whether

a program can have more than one thread of execution.

2

The value of an object visible to a thread

T

at a particular point is the initial value of the object, a value

assigned to the object by

T

, or a value assigned to the object by another thread, according to the rules

below. [

Note:

In some cases, there may instead be undefined behavior. Much of this section is motivated

by the desire to support atomic operations with explicit and detailed visibility constraints. However, it also
implicitly supports a simpler view for more restricted programs.

— end note

]

3

Two expression evaluations

conflict

if one of them modifies a memory location and the other one accesses or

modifies the same memory location.

4

The library defines a number of atomic operations (Clause

Note:

For example, a call that acquires a lock will perform an acquire operation

on the locations comprising the lock. Correspondingly, a call that releases the same lock will perform a
release operation on those same locations. Informally, performing a release operation on

A

forces prior side

effects on other memory locations to become visible to other threads that later perform a consume or an

9)

In other words, function executions do not interleave with each other.

10)

12

A

is the left operand of a built-in logical AND (

&&

, see

, see

—

A

is the left operand of a conditional (

?:

, see

A

is the left operand of the built-in comma (

,

—

A

writes a scalar object or bit-field

M

,

B

reads the value written by

A

from

M

, and

A

is sequenced

before

B

, or

— for some evaluation

X

,

A

carries a dependency to

X

, and

X

carries a dependency to

B

.

[

Note:

“Carries a dependency to” is a subset of “is sequenced before”, and is similarly strictly intra-thread.

— end note

]

9

An evaluation

A

is

dependency-ordered before

an evaluation

B

if

—

A

performs a release operation on an atomic object

M

, and

B

performs a consume operation on

M

and reads a value written by any side effect in the release sequence headed by

A

, or

— for some evaluation

X

,

A

is dependency-ordered before

X

and

X

carries a dependency to

B

.

[

Note:

The relation “is dependency-ordered before” is analogous to “synchronizes with”, but uses release/-

consume in place of release/acquire.

— end note

]

§ 1.10

13

translation unit

. [

Note:

a C

++

program need not all be translated at the same time.

— end note

]

2

[

Note:

previously translated translation units and instantiation units can be preserved individually or in

]

2.2

Phases of translation

[lex.phases]

1

The precedence among the syntax rules of translation is specified by the following phases.

11

1. Physical source file characters are mapped, in an implementation-defined manner, to the basic source

\uXXXX

notation), are handled equivalently.)

2. Each instance of a backslash character (\) immediately followed by a new-line character is deleted,

splicing physical source lines to form logical source lines. Only the last backslash on any physical
source line shall be eligible for being part of such a splice. If, as a result, a character sequence that
matches the syntax of a universal-character-name is produced, the behavior is undefined. A source file
that is not empty and that does not end in a new-line character, or that ends in a new-line character
immediately preceded by a backslash character before any such splicing takes place, shall be processed
as if an additional new-line character were appended to the file.

12

Each comment is replaced by one space character. New-line characters are retained. Whether

each nonempty sequence of white-space characters other than new-line is retained or replaced by one
space character is unspecified. The process of dividing a source file’s characters into preprocessing to-
kens is context-dependent. [

Example:

see the handling of

<

within a

#include

preprocessing directive.

— end example

] Within the

r-char-sequence

of a raw string literal, any transformations performed in

phases 1 and 2 (trigraphs, universal-character-names, and line splicing) are reverted.

11)

Implementations must behave as if these separate phases occur, although in practice different phases might be folded

together.

12)

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.

§ 2.2

16

preprocessing di-

rective causes the named header or source file to be processed from phase 1 through phase 4, recursively.
All preprocessing directives are then deleted.

5. Each source character set member and universal-character-name in a character literal or a string literal,

13

6. Adjacent string literal tokens are concatenated.

7. White-space characters separating tokens are no longer significant. Each preprocessing token is con-

Note:

The process of analyzing and translating the tokens may occasionally

] [

Note:

Source

files, translation units and translated translation units need not necessarily be stored as files, nor need
there be any one-to-one correspondence between these entities and any external representation. The
description is conceptual only, and does not specify any particular implementation.

— end note

]

8. Translated translation units and instantiation units are combined as follows: [

Note:

some or all of

these may be supplied from a library.

— end note

] Each translated translation unit is examined to

produce a list of required instantiations. [

Note:

this may include instantiations which have been

] The definitions of the required templates are located.

It is implementation-defined whether the source of the translation units containing these definitions
is required to be available. [

Note:

an implementation could encode sufficient information into the

translated translation unit so as to ensure the source is not required here.

— end note

] All the

required instantiations are performed to produce

instantiation units

.

[

Note:

these are similar to

translated translation units, but contain no references to uninstantiated templates and no template
definitions.

— end note

] The program is ill-formed if any instantiation fails.

9. 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.

2.3

Character sets

[lex.charset]

1

The

basic source character set

consists of 96 characters: the space character, the control characters repre-

senting horizontal tab, vertical tab, form feed, and new-line, plus the following 91 graphical characters:

14

a b c d e f g h i j k l m n o p q r s t u v w x y z

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

0 1 2 3 4 5 6 7 8 9

_ { } [ ] # ( ) < > % : ; . ? * + - / ^ & |

∼

! = , \ " ’

13)

An implementation need not convert all non-corresponding source characters to the same execution character.

14)

The glyphs for the members of the basic source character set are intended to identify characters from the subset of

ISO/IEC 10646 which corresponds to the ASCII character set. However, because the mapping from source file characters to the
source character set (described in translation phase 1) is specified as implementation-defined, an implementation is required to
document how the basic source characters are represented in source files.

§ 2.3

17

Trigraph

Replacement

Trigraph

Replacement

Trigraph

Replacement

??=

#

??(

[

??<

{

??/

\

??)

]

??>

}

??’

ˆ

??!

|

??-

∼

2

[

Example:

??=define arraycheck(a,b) a??(b??) ??!??! b??(a??)

becomes

#define arraycheck(a,b) a[b] || b[a]

— end example

]

3

No other trigraph sequence exists. Each

?

that does not begin one of the trigraphs listed above is not

changed.

§ 2.4

18

2

A preprocessing token is the minimal lexical element of the language in translation phases 3 through 6. The
categories of preprocessing token are: header names, identifiers, preprocessing numbers, character literals
(including user-defined character literals), string literals (including user-defined string literals), preprocessing
operators and punctuators, and single non-white-space characters that do not lexically match the other
preprocessing token categories. If a

’

or a

"

character matches the last category, the behavior is undefined.

3

If the input stream has been parsed into preprocessing tokens up to a given character:

— if the next character begins a sequence of characters that could be the prefix and initial double quote

of a raw string literal, such as

R"

, the next preprocessing token shall be a raw string literal;

— 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.

[

Example:

#define R "x"
const char* s = R"y";

// ill-formed raw string, not

"x" "y"

— end example

]

4

[

Example:

The program fragment

1Ex

is parsed as a preprocessing number token (one that is not a valid

floating or integer literal token), even though a parse as the pair of preprocessing tokens

1

and

Ex

might

produce a valid expression (for example, if

Ex

were a macro defined as

+1

). Similarly, the program fragment

1E1

is parsed as a preprocessing number (one that is a valid floating literal token), whether or not

E

is a

macro name.

— end example

]

5

[

Example:

The program fragment

x+++++y

is parsed as

x ++ ++ + y

, which, if

x

and

y

are of built-in types,

violates a constraint on increment operators, even though the parse

x ++ + ++ y

might yield a correct

expression.

— end example

]

2.6

Alternative tokens

[lex.digraph]

1

Alternative token representations are provided for some operators and punctuators.

15

15)

These include “digraphs” and additional reserved words. The term “digraph” (token consisting of two characters) is not

§ 2.6

19

Alternative

Primary

Alternative

Primary

Alternative

Primary

<%

{

and

&&

and_eq

&=

%>

}

bitor

|

or_eq

|=

<:

[

or

||

xor_eq

ˆ=

:>

]

xor

ˆ

not

!

%:

#

compl

∼

not_eq

!=

%:%:

##

bitand

&

2.7

Tokens

[lex.token]

token:

identifier
keyword
literal
operator
punctuator

1

There are five kinds of tokens: identifiers, keywords, literals,

17

operators, and other separators. Blanks,

horizontal and vertical tabs, newlines, formfeeds, and comments (collectively, “white space”), as described
below, are ignored except as they serve to separate tokens. [

Note:

Some white space is required to sepa-

rate otherwise adjacent identifiers, keywords, numeric literals, and alternative tokens containing alphabetic
characters.

— end note

]

2.8

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 with the next new-line character. If there is a

form-feed or a vertical-tab character in such a comment, only white-space characters shall appear between it
and the new-line that terminates the comment; no diagnostic is required. [

Note:

The comment characters

//

,

/*

, and

*/

have no special meaning within a

//

comment and are treated just like other characters.

Similarly, the comment characters

//

and

/*

have no special meaning within a

/*

comment.

— end note

]

2.9

Header names

[lex.header]

header-name:

<

h-char-sequence

>

"

q-char-sequence

"

h-char-sequence:

h-char
h-char-sequence h-char

h-char:

any member of the source character set except new-line and

>

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”.

16)

and

<:

will be different, maintaining the source spelling, but the tokens can

otherwise be freely interchanged.

17)

Literals include strings and character and numeric literals.

§ 2.9

20

header-name

s are mapped in an implementation-defined manner to headers or

to external source file names as specified in

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

.

18

2.10

Preprocessing numbers

[lex.ppnumber]

pp-number:

digit

.

digit

pp-number digit
pp-number identifier-nondigit
pp-number

e

sign

pp-number

E

sign

pp-number

.

1

A preprocessing number does not have a type or a value; it acquires both after a successful conversion to an
integral literal token or a floating literal token.

2.11

Identifiers

[lex.name]

identifier:

identifier-nondigit
identifier identifier-nondigit
identifier digit

identifier-nondigit:

nondigit
universal-character-name

other implementation-defined characters

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

An identifier is an arbitrarily long sequence of letters and digits. Each universal-character-name in an
identifier shall designate a character whose encoding in ISO 10646 falls into one of the ranges specified in
Annex A of TR 10176:2003. Upper- and lower-case letters are different. All characters are significant.

19

18)

Thus, a sequence of characters that resembles an escape sequence might result in an error, be interpreted as the character

corresponding to the escape sequence, or have a completely different meaning, depending on the implementation.

19)

On systems in which linkers cannot accept extended characters, an encoding of the universal-character-name may be used

in forming valid external identifiers. For example, some otherwise unused character or sequence of characters may be used to

§ 2.11

21

2.12

Keywords

[lex.key]

1

The identifiers shown in Table

as keywords in phase 7) except in an

attribute-token

The

export

keyword is unused but is

reserved for future use.

— end note

]:

Table 3 — Keywords

alignof

decltype

goto

reinterpret_cast

try

asm

default

if

return

typedef

auto

delete

inline

short

typeid

bool

do

int

signed

typename

break

double

long

sizeof

union

case

dynamic_cast

mutable

static

unsigned

catch

else

namespace

static_assert

using

char

enum

new

static_cast

virtual

char16_t

explicit

noexcept

struct

void

char32_t

export

nullptr

switch

volatile

class

extern

operator

template

wchar_t

const

false

private

this

while

constexpr

float

protected

thread_local

const_cast

for

public

throw

continue

friend

register

true

2

Furthermore, the alternative representations shown in Table

Table 4 — Alternative representations

and

and_eq

bitand

bitor

compl

not

not_eq

or

or_eq

xor

xor_eq

2.13

Operators and punctuators

[lex.operators]

1

The lexical representation of C

++

programs includes a number of preprocessing tokens which are used in

the syntax of the preprocessor or are converted into tokens for operators and punctuators:

preprocessing-op-or-punc

:

one of

{

}

[

]

#

##

(

)

<:

:>

<%

%>

%:

%:%:

;

:

...

new

delete

?

::

.

.*

+

-

*

/

%

ˆ

&

|

~

!

=

<

>

+=

-=

*=

/=

%=

ˆ=

&=

|=

<<

>>

>>=

<<=

==

!=

<=

>=

&&

||

++

--

,

->*

->

and

and_eq

bitand

bitor

compl

not

not_eq

or

or_eq

xor

xor_eq

encode the

\u

in a universal-character-name. Extended characters may produce a long external identifier, but C

++

does not

place a translation limit on significant characters for external identifiers. In C

++

, upper- and lower-case letters are considered

different for all identifiers, including external identifiers.

§ 2.13

22

Literals

[lex.literal]

2.14.1

Kinds of literals

[lex.literal.kinds]

1

There are several kinds of literals.

20

literal:

integer-literal
character-literal
floating-literal
string-literal
boolean-literal
pointer-literal
user-defined-literal

2.14.2

Integer literals

[lex.icon]

integer-literal:

decimal-literal integer-suffix

opt

octal-literal integer-suffix

opt

hexadecimal-literal integer-suffix

opt

decimal-literal:

nonzero-digit
decimal-literal digit

octal-literal:

0

octal-literal octal-digit

hexadecimal-literal:

0x

hexadecimal-digit

0X

hexadecimal-digit

hexadecimal-literal hexadecimal-digit

nonzero-digit:

one of

1 2 3 4 5 6 7 8 9

octal-digit:

one of

0 1 2 3 4 5 6 7

hexadecimal-digit:

one of

0 1 2 3 4 5 6 7 8 9
a b c d e f
A B C D E F

integer-suffix:

unsigned-suffix long-suffix

opt

unsigned-suffix long-long-suffix

opt

long-suffix unsigned-suffix

opt

long-long-suffix unsigned-suffix

opt

unsigned-suffix:

one of

u U

long-suffix:

one of

l L

long-long-suffix:

one of

ll LL

20)

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

§ 2.14.2

23

represented.

Table 5 — Types of integer constants

Suffix

Decimal constant

Octal or hexadecimal constant

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

3

2.14.3

Character literals

[lex.ccon]

character-literal:

’

c-char-sequence

’

u

’

c-char-sequence

’

U

’

c-char-sequence

’

L

’

c-char-sequence

’

21)

The digits

8

and

9

are not octal digits.

§ 2.14.3

24

]. The value of a wide-character literal containing multiple

c-char

s is implementation-defined.

3

Certain nongraphic characters, the single quote

’

, the double quote

"

, the question mark

?

,

23

and the

backslash

\

, can be represented according to Table

and the question mark

?

, can

be represented as themselves or by the escape sequences

\"

and

\?

respectively, but the single quote

’

and the backslash

\

shall be represented by the escape sequences

\’

and

\\

respectively. Escape sequences

22)

They are intended for character sets where a character does not fit into a single byte.

23)

Using an escape sequence for a question mark can avoid accidentally creating a trigraph.

§ 2.14.3

25

implementation-defined semantics. An escape sequence specifies a single character.

Table 6 — Escape sequences

new-line

NL(LF)

\n

horizontal tab

HT

\t

vertical tab

VT

\v

backspace

BS

\b

carriage return

CR

\r

form feed

FF

\f

alert

BEL

\a

backslash

\

\\

question mark

?

\?

single quote

’

\

’

double quote

"

\

"

octal number

ooo

\

ooo

hex number

hhh

\x

hhh

4

The escape

\ooo

consists of the backslash followed by one, two, or three octal digits that are taken to specify

the value of the desired character. The escape

\xhhh

consists of the backslash followed by

x

followed by one

or more hexadecimal digits that are taken to specify the value of the desired character. There is no limit to
the number of digits in a hexadecimal sequence. A sequence of octal or hexadecimal digits is terminated by
the first character that is not an octal digit or a hexadecimal digit, respectively. The value of a character
literal is implementation-defined if it falls outside of the implementation-defined range defined for

char

(for

literals with no prefix),

char16_t

(for literals prefixed by

’u’

),

char32_t

(for literals prefixed by

’U’

), or

wchar_t

(for literals prefixed by

’L’

).

5

A universal-character-name is translated to the encoding, in the appropriate execution character set, of the
character named. If there is no such encoding, the universal-character-name is translated to an implementation-
defined encoding. [

Note:

in translation phase 1, a universal-character-name is introduced whenever an actual

extended character is encountered in the source text. Therefore, all extended characters are described in
terms of universal-character-names. However, the actual compiler implementation may use its own native
character set, so long as the same results are obtained.

— end note

]

2.14.4

Floating literals

[lex.fcon]

floating-literal:

fractional-constant exponent-part

opt

floating-suffix

opt

digit-sequence exponent-part floating-suffix

opt

fractional-constant:

digit-sequence

opt

.

digit-sequence

digit-sequence

.

exponent-part:

e

sign

opt

digit-sequence

E

sign

opt

digit-sequence

sign:

one of

+ -

digit-sequence:

digit
digit-sequence digit

§ 2.14.4

26

R

,

u8

,

u8R

,

u

,

uR

,

U

,

UR

,

L

, or

LR

, as in

"..."

,

R"(...)"

,

u8"..."

,

u8R"**(...)**"

,

u"..."

,

uR"*

~

(...)*

~

"

,

U"..."

,

UR"zzz(...)zzz"

,

L"..."

, or

LR"(...)"

, respectively.

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.

24

3

[

Note:

The characters

’(’

and

’)’

are permitted in a

raw-string

. Thus,

R"delimiter((a|b))delimiter"

is equivalent to

"(a|b)"

.

— end note

]

4

[

Note:

A source-file new-line in a raw string literal results in a new-line in the resulting execution

string-

literal

. Assuming no whitespace at the beginning of lines in the following example, the assert will succeed:

const char *p = R"(a\
b
c)";
assert(std::strcmp(p, "a\\\nb\nc") == 0);

— end note

]

5

After translation phase 6, a string literal that does not begin with an

encoding-prefix

is an ordinary string

literal, and is initialized with the given characters.

6

A string literal that begins with

u8

, such as

u8"asdf"

, is a UTF-8 string literal and is initialized with the

given characters as encoded in UTF-8.

7

Ordinary string literals and UTF-8 string literals are also referred to as narrow string literals. A narrow
string literal has type “array of

n

const char

”, where

n

is the size of the string as defined below, and has

A string literal that begins with

u

, such as

u"asdf"

, is a

char16_t

string literal. A

char16_t

string literal

has type “array of

n

const char16_t

”, where

n

is the size of the string as defined below; it has static storage

duration and is initialized with the given characters. A single

c-char

may produce more than one

char16_t

character in the form of surrogate pairs.

9

A string literal that begins with

U

, such as

U"asdf"

, is a

char32_t

string literal. A

char32_t

string literal

has type “array of

n

const char32_t

”, where

n

is the size of the string as defined below; it has static storage

duration and is initialized with the given characters.

10

A string literal that begins with

L

, such as

L"asdf"

, is a wide string literal. A wide string literal has type

“array of

n

const wchar_t

”, where

n

is the size of the string as defined below; it has static storage duration

and is initialized with the given characters.

11

Whether all string literals are distinct (that is, are stored in nonoverlapping objects) is implementation-
defined. The effect of attempting to modify a string literal is undefined.

12

, the resulting concatenated string literal has that

encoding-prefix

. If one string literal has

no

encoding-prefix

, it is treated as a string literal of the same

encoding-prefix

as the other operand. If a

UTF-8 string literal token is adjacent to a wide string literal token, the program is ill-formed. Any other
concatenations are conditionally supported with implementation-defined behavior. [

Note:

This concatena-

tion is an interpretation, not a conversion. Because the interpretation happens in translation phase 6 (after
each character from a literal has been translated into a value from the appropriate character set), a string

§ 2.14.5

28

Characters in concatenated strings are kept distinct.

[

Example:

"\xA" "B"

contains the two characters

’\xA’

and

’B’

after concatenation (and not the single hexadecimal character

’\xAB’

).

— end example

]

13

is appended to every string literal so

that programs that scan a string can find its end.

14

is representable either by itself or by the escape

sequence

\’

, and the double quote

"

shall be preceded by a

\

. In a narrow string literal, a universal-character-

name may map to more than one

char

element due to

multibyte encoding

. The size of a

char32_t

or wide

string literal is the total number of escape sequences, universal-character-names, and other characters, plus
one for the terminating

U’\0’

or

L’\0’

. The size of a

char16_t

string literal is the total number of escape

sequences, universal-character-names, and other characters, plus one for each character requiring a surrogate
pair, plus one for the terminating

u’\0’

. [

Note:

The size of a

char16_t

string literal is the number of code

units, not the number of characters.

— end note

] Within

char32_t

and

char16_t

literals, any universal-

character-names shall be within the range

0x0

to

0x10FFFF

. The size of a narrow string literal is the total

number of escape sequences and other characters, plus at least one for the multibyte encoding of each
universal-character-name, plus one for the terminating

’\0’

.

2.14.6

Boolean literals

[lex.bool]

boolean-literal:

false
true

1

The Boolean literals are the keywords

false

and

true

. Such literals are prvalues and have type

bool

.

2.14.7

Pointer literals

[lex.nullptr]

pointer-literal:

nullptr

24)

Use of characters with trigraph equivalents in a

d-char-sequence

may produce unintended results.

§ 2.14.7

29

user-defined-literal L

with

ud-suffix X

, the

literal-operator-id

whose literal suffix identifier is

X

is looked up in the context of

L

using the rules for unqualified name

be the set of declarations found by this lookup.

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

(

n

ULL)

Otherwise,

S

contains a raw literal operator, the

literal L

is treated as a call of the form

operator ""

X

("

n

")

Otherwise (

S

contains a literal operator template),

L

is treated as a call of the form

operator ""

X

<’

c

1

’, ’

c

2

’, ... ’

c

k

’>()

where

n

is the source character sequence

c

1

c

2

...c

k

. [

Note:

the sequence

c

1

c

2

...c

k

can only contain characters

from the basic source character set.

— end note

]

4

If

L

is a

user-defined-floating-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

(

f

L)

Otherwise,

S

contains a raw literal operator, the

literal L

is treated as a call of the form

operator ""

X

("

f

")

§ 2.14.8

30

s are

considered string literals for that purpose. During concatenation,

ud-suffix

es are removed and ignored and

the concatenation process occurs as described in

user-defined-string-literal

, all the participating

user-defined-string-

literal

s shall have the same

ud-suffix

and that suffix is applied to the result of the concatenation.

9

[

Example:

int main() {

L"A" "B" "C"x;

// OK: same as

L"ABC"x

"P"x "Q" "R"y;

// error: two different ud-suffixes

}

— end example

]

§ 2.14.8

31