ISO/IEC JTC 1/SC 22 N 4411 2008-10-09

Secretariat, ISO/IEC JTC 1, American National Standards Institute, 25 West 43rd Street, New York, NY 10036; Telephone: 1 212 642 4932; Facsimile: 1 212 840 2298; Email: lrajchel@ansi.org

ISO/IEC JTC 1/SC 22

Programming Languages Document Type: Text for CD Ballot Document Title: ISO/IEC 14882, Programming language C++ Document Source: WG 21 Convener (P.J. Plauger) Document Status: This document is circulated to National Bodies for ballot. Please submit

your vote via the online balloting system by the due date indicated. Action ID: Due Date: 2009-01-10 No. of Pages: 1314

cISO 2008 All rights reserved

ISO/IEC JTC 1/SC22/WG21 N 2800Date: 2008-10-08

ISO/IEC IS 14882

ISO/IEC JTC 1/SC22

Secretariat: ANSI

Programming Languages C++Langages de programmation C++

Warning

This document is not an ISO International Standard. It is distributed for review and comment. It is subjectto change without notice and may not be referred to as an International Standard.

Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rightsof which they are aware and to provide supporting documentation.

Document type: Draft International StandardDocument stage: (30) CommitteeDocument Language: E

Copyright notice

This ISO document is a working draft or committee draft and is copyright-protected by ISO. While thereproduction of working drafts or committee drafts in any form for use by participants in the ISO standardsdevelopment process is permitted without prior permission from ISO, neither this document nor any extractfrom it may be reproduced, stored or transmitted in any form for any other purpose without prior writtenpermission from ISO.

Requests for permission to reproduce this document for the purpose of selling it should be addressed asshown below or to ISOs member body in the country of the requestor.

ISO copyright officeCase postale 56, CH-1211 Geneva 20Tel. + 41 22 749 01 11Fax + 41 22 749 09 47E-mail copyright@iso.orgWeb www.iso.org

Reproduction for sales purposes may be subject to royalty payments or a licensing agreement.

Violators may be prosecuted.

c ISO/IEC N2800=08-0310

ContentsContents iii

List of Tables x

1 General 11.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Normative references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Implementation compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.5 Structure of this International Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.6 Syntax notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.7 The C++ memory model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.8 The C++ object model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.9 Program execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.10 Multi-threaded executions and data races . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 Lexical conventions 152.1 Phases of translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2 Character sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.3 Trigraph sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.4 Preprocessing tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.5 Alternative tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.6 Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.7 Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.8 Header names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.9 Preprocessing numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.10 Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.11 Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.12 Operators and punctuators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.13 Literals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 Basic concepts 313.1 Declarations and definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.2 One definition rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.3 Declarative regions and scopes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.4 Name lookup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.5 Program and linkage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.6 Start and termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.7 Storage duration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633.8 Object lifetime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673.9 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703.10 Lvalues and rvalues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753.11 Alignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

4 Standard conversions 79

CONTENTS iii

c ISO/IEC N2800=08-0310

4.1 Lvalue-to-rvalue conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804.2 Array-to-pointer conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804.3 Function-to-pointer conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804.4 Qualification conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804.5 Integral promotions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814.6 Floating point promotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824.7 Integral conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824.8 Floating point conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824.9 Floating-integral conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834.10 Pointer conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834.11 Pointer to member conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834.12 Boolean conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844.13 Integer conversion rank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

5 Expressions 855.1 Primary expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.2 Postfix expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915.3 Unary expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1025.4 Explicit type conversion (cast notation) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1095.5 Pointer-to-member operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1115.6 Multiplicative operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1115.7 Additive operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1125.8 Shift operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1135.9 Relational operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1145.10 Equality operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1155.11 Bitwise AND operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1165.12 Bitwise exclusive OR operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1165.13 Bitwise inclusive OR operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1165.14 Logical AND operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1165.15 Logical OR operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1165.16 Conditional operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1175.17 Assignment and compound assignment operators . . . . . . . . . . . . . . . . . . . . . . . . . 1185.18 Comma operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1195.19 Constant expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

6 Statements 1226.1 Labeled statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1226.2 Expression statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1226.3 Compound statement or block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1226.4 Selection statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1236.5 Iteration statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1246.6 Jump statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1276.7 Declaration statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1296.8 Ambiguity resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1306.9 Late-checked block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

7 Declarations 1337.1 Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1347.2 Enumeration declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1487.3 Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1517.4 The asm declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

CONTENTS iv

c ISO/IEC N2800=08-0310

7.5 Linkage specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1657.6 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

8 Declarators 1738.1 Type names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1748.2 Ambiguity resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1758.3 Meaning of declarators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1768.4 Function definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1898.5 Initializers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

9 Classes 2059.1 Class names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2079.2 Class members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2099.3 Member functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2119.4 Static members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2149.5 Unions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2169.6 Bit-fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2179.7 Nested class declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2189.8 Local class declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2199.9 Nested type names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

10 Derived classes 22110.1 Multiple base classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22210.2 Member name lookup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22410.3 Virtual functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22710.4 Abstract classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

11 Member access control 23311.1 Access specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23511.2 Accessibility of base classes and base class members . . . . . . . . . . . . . . . . . . . . . . . 23611.3 Access declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23811.4 Friends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23911.5 Protected member access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24211.6 Access to virtual functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24311.7 Multiple access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24411.8 Nested classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

12 Special member functions 24512.1 Constructors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24512.2 Temporary objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24712.3 Conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24912.4 Destructors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25212.5 Free store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25512.6 Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25712.7 Construction and destruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26212.8 Copying class objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26512.9 Inheriting Constructors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

13 Overloading 27513.1 Overloadable declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27513.2 Declaration matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

CONTENTS v

c ISO/IEC N2800=08-0310

13.3 Overload resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27913.4 Address of overloaded function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29713.5 Overloaded operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29813.6 Built-in operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

14 Templates 30714.1 Template parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30814.2 Names of template specializations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31214.3 Template arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31414.4 Type equivalence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32014.5 Template declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32114.6 Name resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34114.7 Template instantiation and specialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35414.8 Function template specializations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36714.9 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38614.10Constrained templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408

15 Exception handling 42715.1 Throwing an exception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42815.2 Constructors and destructors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43015.3 Handling an exception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43015.4 Exception specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43215.5 Special functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43515.6 Exceptions and access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436

16 Preprocessing directives 43716.1 Conditional inclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43916.2 Source file inclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44016.3 Macro replacement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44116.4 Line control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44616.5 Error directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44716.6 Pragma directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44716.7 Null directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44716.8 Predefined macro names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44716.9 Pragma operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448

17 Library introduction 45017.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45017.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45017.3 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45017.4 Additional definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45417.5 Method of description (Informative) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45417.6 Library-wide requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460

18 Language support library 47118.1 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47118.2 Implementation properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47218.3 Integer types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48118.4 Start and termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48218.5 Dynamic memory management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48418.6 Type identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488

CONTENTS vi

c ISO/IEC N2800=08-0310

18.7 Exception handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49218.8 Initializer lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49718.9 Other runtime support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499

19 Diagnostics library 50119.1 Exception classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50119.2 Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50519.3 Error numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50619.4 System error support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506

20 General utilities library 51820.1 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51820.2 Utility components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53220.3 Compile-time rational arithmetic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54520.4 Tuples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54820.5 Metaprogramming and type traits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55620.6 Function objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56820.7 Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59220.8 Time utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63620.9 Date and time functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649

21 Strings library 65021.1 Character traits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65021.2 String classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65621.3 Class template basic_string . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65921.4 Numeric Conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68521.5 Null-terminated sequence utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687

22 Localization library 69122.1 Locales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69122.2 Standard locale categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70422.3 Standard code conversion facets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74422.4 C Library Locales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746

23 Containers library 74723.1 Container requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74723.2 Sequence containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77723.3 Associative containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81923.4 Unordered associative containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839

24 Iterators library 85824.1 Iterator concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85824.2 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86524.3 Iterator operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86924.4 Predefined iterators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86924.5 Stream iterators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886

25 Algorithms library 89425.1 Non-modifying sequence operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90725.2 Mutating sequence operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91125.3 Sorting and related operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92025.4 C library algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935

CONTENTS vii

c ISO/IEC N2800=08-0310

26 Numerics library 93726.1 Numeric type requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93726.2 The floating-point environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93826.3 Complex numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93926.4 Random number generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94826.5 Numeric arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99026.6 Generalized numeric operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101026.7 C Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1014

27 Input/output library 102027.1 Iostreams requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102027.2 Forward declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102127.3 Standard iostream objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102327.4 Iostreams base classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102527.5 Stream buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104227.6 Formatting and manipulators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105327.7 String-based streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108027.8 File-based streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1092

28 Regular expressions library 110828.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110828.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110828.3 Regular expressions summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111028.4 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111128.5 Namespace std::regex_constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111728.6 Class regex_error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112028.7 Class template regex_traits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112028.8 Class template basic_regex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112328.9 Class template sub_match . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112828.10Class template match_results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113328.11Regular expression algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113728.12Regular expression Iterators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114228.13Modified ECMAScript regular expression grammar . . . . . . . . . . . . . . . . . . . . . . . . 1147

29 Atomic operations library 115029.1 Order and Consistency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115229.2 Lock-free Property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115429.3 Atomic Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115429.4 Operations on Atomic Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116029.5 Flag Type and Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116329.6 Fences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1164

30 Thread support library 116630.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116630.2 Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116730.3 Mutual exclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117230.4 Condition variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118630.5 Futures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1192

A Grammar summary 1202A.1 Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1202

CONTENTS viii

c ISO/IEC N2800=08-0310

A.2 Lexical conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1202A.3 Basic concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1207A.4 Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1207A.5 Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1211A.6 Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1212A.7 Declarators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1215A.8 Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1217A.9 Derived classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1217A.10 Special member functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1218A.11 Overloading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1218A.12 Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1218A.13 Exception handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1221A.14 Preprocessing directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1221

B Implementation quantities 1223

C Compatibility 1225C.1 C++ and ISO C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1225C.2 Standard C library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1234

D Compatibility features 1239D.1 Increment operator with bool operand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1239D.2 static keyword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1239D.3 Access declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1239D.4 Implicit conversion from const strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1239D.5 C standard library headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1239D.6 Old iostreams members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1240D.7 char* streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1241D.8 Binders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1250D.9 auto_ptr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1252D.10 Iterator primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1254

Index 1259

CONTENTS ix

c ISO/IEC N2800=08-0310

List of Tables1 Trigraph sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Alternative tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 Alternative representations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Types of integer constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 Escape sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 String literal concatenations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

8 Relations on const and volatile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

9 simple-type-specifiers and the types they specify . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

10 Relationship between operator and function call notation . . . . . . . . . . . . . . . . . . . . . . 28311 Conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

12 Library categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45113 C++ library headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46114 C++ headers for C library facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46115 C++ headers for freestanding implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462

16 Language support library summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47117 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47118 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48119 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48120 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48221 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49922 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49923 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49924 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49925 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50026 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500

27 Diagnostics library summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50128 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50529 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506

30 General utilities library summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51831 Primary type category predicates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55932 Composite type category predicates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56033 Type property predicates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56034 Type property queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56335 Type relationship predicates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56336 Const-volatile modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56537 Reference modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56538 Sign modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56639 Array modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566

List of Tables List of Tables x

c ISO/IEC N2800=08-0310

40 Pointer modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56741 Other transformations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56742 ConstructibleWithAllocator concept map constraint patterns . . . . . . . . . . . . . . . . . . 60043 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63544 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63645 Clock requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63846 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649

47 Strings library summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65048 Character traits requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65149 basic_string(const Allocator&) effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66450 basic_string(const basic_string&) effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66551 basic_string(const basic_string&, size_type, size_type, const Allocator&) effects . 66552 basic_string(const charT*, size_type, const Allocator&) effects . . . . . . . . . . . . . . 66553 basic_string(const charT*, const Allocator&) effects . . . . . . . . . . . . . . . . . . . . . 66654 basic_string(size_t, charT, const Allocator&) effects . . . . . . . . . . . . . . . . . . . . 66655 basic_string(const basic_string&, const Allocator&) and basic_string(basic_string&&,

const Allocator&) effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66656 operator=(const basic_string&) effects . . . . . . . . . . . . . 66757 operator=(const basic_string&&) effects . . . . . . . . . . . . 66758 compare() results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67959 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68860 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68961 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68962 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68963 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68964 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690

65 Localization library summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69166 Locale category facets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69567 Required specializations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69568 do_in/do_out result values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71469 do_unshift result values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71470 Integer conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71871 Length modifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71872 Integer conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72273 Floating-point conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72274 Length modifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72375 Numeric conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72376 Fill padding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72477 do_get_date effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73178 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746

79 Containers library summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74780 Container requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74881 Reversible container requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75082 Allocator-aware container requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75183 Sequence container requirements (in addition to container) . . . . . . . . . . . . . . . . . . . . . 75384 Optional sequence container operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75485 Associative container requirements (in addition to container) . . . . . . . . . . . . . . . . . . . . 75686 Container requirements that are not required for unordered associative containers . . . . . . . . . 761

List of Tables List of Tables xi

c ISO/IEC N2800=08-0310

87 Unordered associative container requirements (in addition to container) . . . . . . . . . . . . . . 762

88 Iterators library summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85889 Relations among iterator categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 859

90 Algorithms library summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89491 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935

92 Numerics library summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93793 Uniform random number generator requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 95094 Random number engine requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95195 Random number engine adaptor requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95396 Random number distribution requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95497 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101598 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015

99 Input/output library summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1020100 fmtflags effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1029101 fmtflags constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1029102 iostate effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1030103 openmode effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1030104 seekdir effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1030105 Position type requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1035106 basic_ios::init() effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1037107 seekoff positioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1085108 newoff values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1086109 File open modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1096110 seekoff effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1099111 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1107112 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1107

113 Regular expression traits class requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1109114 syntax_option_type effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1118115 regex_constants::match_flag_type effects when obtaining a match against a character con-

tainer sequence [first,last). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1118116 error_type values in the C locale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1120117 match_results assignment operator effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1135118 Effects of regex_match algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1138119 Effects of regex_search algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1140

120 Atomics library summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1150121 Atomics for built-in types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1157122 Atomics for standard typedef types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1158123 Atomic arithmetic computations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1162

124 Thread support library summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1166

125 Standard macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1235126 Standard values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1235127 Standard types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1235128 Standard structs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1235129 Standard functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1236

List of Tables List of Tables xii

c ISO/IEC N2800=08-0310

130 C headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1239131 strstreambuf(streamsize) effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1243132 strstreambuf(void* (*)(size_t), void (*)(void*)) effects . . . . . . . . . . . . . . . . . . 1243133 strstreambuf(charT*, streamsize, charT*) effects . . . . . . . . . . . . . . . . . . . . . . . . 1243134 seekoff positioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1246135 newoff values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1246

List of Tables List of Tables xiii

c ISO/IEC N2800=08-0310

1 General [intro]1.1 Scope [intro.scope]

1 This International Standard specifies requirements for implementations of the C++ programming language.The first such requirement is that they implement the language, and so this International Standard alsodefines C++. Other requirements and relaxations of the first requirement appear at various places withinthis International Standard.

2 C++ is a general purpose programming language based on the C programming language as described inISO/IEC 9899:1990 Programming languages C (1.2). In addition to the facilities provided by C, C++ provides additional data types, classes, templates, exceptions, namespaces, inline functions, operatoroverloading, function name overloading, references, free store management operators, and additional libraryfacilities.

1.2 Normative references [intro.refs]

1 The following standards contain provisions which, through reference in this text, constitute provisions ofthis International Standard. At the time of publication, the editions indicated were valid. All standardsare subject to revision, and parties to agreements based on this International Standard are encouraged toinvestigate the possibility of applying the most recent editions of the standards indicated below. Membersof IEC and ISO maintain registers of currently valid International Standards.

Ecma International, ECMAScript Language Specification, Standard Ecma-262, third edition, 1999.

ISO/IEC 2382 (all parts), Information technology Vocabulary

ISO/IEC 9899:1990, Programming languages C

ISO/IEC 9899/Amd.1:1995, Programming languages C, AMENDMENT 1: C Integrity

ISO/IEC 9899:1999, Programming languages C

ISO/IEC 9899:1999/Cor.1:2001, Programming languages C

ISO/IEC 9899:1999/Cor.2:2004, Programming languages C

ISO/IEC 9945:2003, Information Technology Portable Operating System Interface (POSIX)

ISO/IEC TR 10176:2003, Information technology Guidelines for the preparation of programminglanguage standards

ISO/IEC 10646-1:1993, Information technology Universal Multiple-Octet Coded Character Set (UCS) Part 1: Architecture and Basic Multilingual Plane

ISO/IEC TR 19769:2004, Information technology Programming languages, their environments andsystem software interfaces Extensions for the progrmming language C to support new character datatypes

2 The library described in Clause 7 of ISO/IEC 9899:1990 and Clause 7 of ISO/IEC 9899/Amd.1:1995 ishereinafter called the C standard library.1

1) With the qualifications noted in Clauses 17 through 27, and in C.2, the C standard library is a subset of the C++ standardlibrary.

1.2 1

c ISO/IEC N2800=08-0310

3 The library described in Clause 7 of ISO/IEC 9899:1999 and Clause 7 of ISO/IEC 9899:1999/Cor.1:2001and Clause 7 of ISO/IEC 9899:1999/Cor.2:2003 is hereinafter called the C99 standard library.

4 The library described in ISO/IEC TR 19769:2004 is hereinafter called the C Unicode TR.

5 The operating system interface described in ISO/IEC 9945:2003 is hereinafter called POSIX .

6 The ECMAScript Language Specification described in Standard Ecma-262 is hereinafter called ECMA-262.

1.3 Definitions [intro.defs]

1 For the purposes of this International Standard, the definitions given in ISO/IEC 2382 and the followingdefinitions apply. 17.3 defines additional terms that are used only in Clauses 17 through 27 and Annex D.

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

1.3.1 [defns.argument]argumentan expression in the comma-separated list bounded by the parentheses in a function call expression; asequence of preprocessing tokens in the comma-separated list bounded by the parentheses in a function-likemacro invocation; the operand of throw; or an expression, type-id or template-name in the comma-separatedlist bounded by the angle brackets in a template instantiation. Also known as an actual argument or actualparameter .

1.3.2 [defns.cond.supp]conditionally-supporteda program construct that an implementation is not required to support. [ Note: Each implementationdocuments all conditionally-supported constructs that it does not support. end note ]

1.3.3 [defns.diagnostic]diagnostic messagea message belonging to an implementation-defined subset of the implementations output messages.

1.3.4 [defns.dynamic.type]dynamic typethe type of the most derived object (1.8) to which the lvalue denoted by an lvalue expression refers. [ Example:if a pointer (8.3.1) p whose static type is pointer to class B is pointing to an object of class D, derived fromB (Clause 10), the dynamic type of the expression *p is D. References (8.3.2) are treated similarly. endexample ] The dynamic type of an rvalue expression is its static type.

1.3.5 [defns.ill.formed]ill-formed programinput to a C++ implementation that is not a well-formed program.

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

1.3 2

c ISO/IEC N2800=08-0310

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

1.3.7 [defns.impl.limits]implementation limitsrestrictions imposed upon programs by the implementation.

1.3.8 [defns.locale.specific]locale-specific behaviorbehavior that depends on local conventions of nationality, culture, and language that each implementationdocuments.

1.3.9 [defns.multibyte]multibyte charactera sequence of one or more bytes representing a member of the extended character set of either the source orthe execution environment. The extended character set is a superset of the basic character set (2.2).

1.3.10 [defns.parameter]parameteran object or reference declared as part of a function declaration or definition, or in the catch Clause of anexception handler, that acquires a value on entry to the function or handler; an identifier from the comma-separated list bounded by the parentheses immediately following the macro name in a function-like macrodefinition; or a template-parameter . Parameters are also known as formal arguments or formal parameters.

1.3.11 [defns.signature]signaturethe name and the parameter-type-list (8.3.5) of a function, as well as the class, concept, concept map, ornamespace of which it is a member. If a function or function template is a class member its signatureadditionally includes the cv-qualifiers (if any) and the ref-qualifier (if any) on the function or functiontemplate itself. The signature of a constrained member (9.2) includes its template requirements. Thesignature of a function template additionally includes its return type, its template parameter list, and itstemplate requirements (if any). The signature of a function template specialization includes the signatureof the template of which it is a specialization and its template arguments (whether explicitly specified ordeduced). [ Note: Signatures are used as a basis for name mangling and linking. end note ]

1.3.12 [defns.static.type]static typethe type of an expression (3.9), which type results from analysis of the program without considering executionsemantics. The static type of an expression depends only on the form of the program in which the expressionappears, and does not change while the program is executing.

1.3.13 [defns.undefined]undefined behaviorbehavior, such as might arise upon use of an erroneous program construct or erroneous data, for whichthis International Standard imposes no requirements. Undefined behavior may also be expected when thisInternational Standard omits the description of any explicit definition of behavior. [ Note: permissibleundefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving

1.3 3

c ISO/IEC N2800=08-0310

during translation or program execution in a documented manner characteristic of the environment (with orwithout the issuance of a diagnostic message), to terminating a translation or execution (with the issuanceof a diagnostic message). Many erroneous program constructs do not engender undefined behavior; they arerequired to be diagnosed. end note ]

1.3.14 [defns.unspecified]unspecified behaviorbehavior, for a well-formed program construct and correct data, that depends on the implementation. Theimplementation is not required to document which behavior occurs. [ Note: usually, the range of possiblebehaviors is delineated by this International Standard. end note ]

1.3.15 [defns.well.formed]well-formed programa C++ program constructed according to the syntax rules, diagnosable semantic rules, and the One DefinitionRule (3.2).

1.4 Implementation compliance [intro.compliance]

1 The set of diagnosable rules consists of all syntactic and semantic rules in this International Standard exceptfor those rules containing an explicit notation that no diagnostic is required or which are described asresulting in undefined behavior.

2 Although this International Standard states only requirements on C++ implementations, those requirementsare often easier to understand if they are phrased as requirements on programs, parts of programs, orexecution 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 execute2 that program.

If a program contains a violation of any diagnosable rule or an occurrence of a construct described inthis Standard as conditionally-supported when the implementation does not support that construct,a conforming implementation shall issue at least one diagnostic message.

If a program contains a violation of a rule for which no diagnostic is required, this InternationalStandard places no requirement on implementations with respect to that program.

3 For classes and class templates, the library Clauses specify partial definitions. Private members (Clause 11)are not specified, but each implementation shall supply them to complete the definitions according to thedescription in the library Clauses.

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 The names defined in the library have namespace scope (7.3). A C++ translation unit (2.1) obtains accessto these names by including the appropriate standard library header (16.2).

6 The templates, classes, functions, and objects in the library have external linkage (3.5). The implementationprovides definitions for standard library entities, as necessary, while combining translation units to form acomplete C++ program (2.1).

7 Two kinds of implementations are defined: hosted and freestanding. For a hosted implementation, thisInternational Standard defines the set of available libraries. A freestanding implementation is one in which

2) Correct execution can include undefined behavior, depending on the data being processed; see 1.3 and 1.9.

1.4 4

c ISO/IEC N2800=08-0310

execution may take place without the benefit of an operating system, and has an implementation-definedset of libraries that includes certain language-support libraries (17.6.2.4).

8 A conforming implementation may have extensions (including additional library functions), provided they donot alter the behavior of any well-formed program. Implementations are required to diagnose programs thatuse 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 thatit does not support and defines all locale-specific characteristics.3

1.5 Structure of this International Standard [intro.structure]

1 Clauses 2 through 16 describe the C++ programming language. That description includes detailed syntacticspecifications in a form described in 1.6. For convenience, Annex A repeats all such syntactic specifications.

2 Clauses 18 through 30 and Annex D (the library Clauses) describe the Standard C++ library, which providesdefinitions for the following kinds of entities: macros (16.3), values (Clause 3), types (8.1, 8.3), templates(Clause 14), classes (Clause 9), functions (8.3.5), and objects (Clause 7).

3 Annex B recommends lower bounds on the capacity of conforming implementations.

4 Annex C summarizes the evolution of C++ since its first published description, and explains in detail thedifferences between C++ and C. Certain features of C++ exist solely for compatibility purposes; Annex Ddescribes those features.

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 andnotes 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 exceptin a few cases where a long set of alternatives is presented on one line, marked by the phrase one of. Anoptional terminal or nonterminal symbol is indicated by the subscript opt , so

{ expressionopt }

indicates an optional expression enclosed in braces.

2 Names for syntactic categories have generally been chosen according to the following rules:

X-name is a use of an identifier in a context that determines its meaning (e.g. class-name, typedef-name).

X-id is an identifier with no context-dependent meaning (e.g. qualified-id).

X-seq is one or more X s without intervening delimiters (e.g. declaration-seq is a sequence of declara-tions).

X-list is one or more X s separated by intervening commas (e.g. expression-list is a sequence ofexpressions separated by commas).

3) This documentation also defines implementation-defined behavior; see 1.9.

1.6 5

c ISO/IEC N2800=08-0310

1.7 The C++ memory model [intro.memory]

1 The fundamental storage unit in the C++ memory model is the byte. A byte is at least large enough tocontain any member of the basic execution character set and the eight-bit code units of the Unicode UTF-8encoding form and is composed of a contiguous sequence of bits, the number of which is implementation-defined. The least significant bit is called the low-order bit; the most significant bit is called the high-orderbit. The memory available to a C++ program consists of one or more sequences of contiguous bytes. Everybyte has a unique address.

2 [ Note: the representation of types is described in 3.9. end note ]

3 A memory location is either an object of scalar type or a maximal sequence of adjacent bit-fields all havingnon-zero width. [ Note: Various features of the language, such as references and virtual functions, mightinvolve additional memory locations that are not accessible to programs but are managed by the implemen-tation. end note ] Two threads of execution can update and access separate memory locations withoutinterfering with each other.

4 [ Note: Thus a bit-field and an adjacent non-bit-field are in separate memory locations, and therefore can beconcurrently 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 bya zero-length bit-field declaration, or if they are separated by a non-bit-field declaration. It is not safe toconcurrently update two bit-fields in the same struct if all fields between them are also bit-fields, no matterwhat the sizes of those intervening bit-fields happen to be. end note ]

5 [ Example: A structure declared asstruct {

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 memorylocations, and can be modified concurrently without interfering with each other. The bit-fields b and ctogether constitute the fourth memory location. The bit-fields b and c cannot be concurrently modified, butb and a, for example, can be. end example ]

1.8 The C++ object model [intro.object]

1 The constructs in a C++ program create, destroy, refer to, access, and manipulate objects. An object is aregion of storage. [ Note: A function is not an object, regardless of whether or not it occupies storage in theway that objects do. end note ] An object is created by a definition (3.1), by a new-expression (5.3.4) orby the implementation (12.2) when needed. The properties of an object are determined when the object iscreated. An object can have a name (Clause 3). An object has a storage duration (3.7) which influencesits lifetime (3.8). An object has a type (3.9). The term object type refers to the type with which the objectis created. Some objects are polymorphic (10.3); the implementation generates information associated witheach such object that makes it possible to determine that objects type during program execution. For otherobjects, the interpretation of the values found therein is determined by the type of the expressions (Clause 5)used to access them.

1.8 6

c ISO/IEC N2800=08-0310

2 Objects can contain other objects, called subobjects. A subobject can be a member subobject (9.2), a baseclass subobject (Clause 10), or an array element. An object that is not a subobject of any other object iscalled a 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 If a complete object, a data member (9.2), or an array element is of class type, its type is considered themost derived class, to distinguish it from the class type of any base class subobject; an object of a mostderived class type or of a non-class type is called a most derived object.

5 Unless it is a bit-field (9.6), a most derived object shall have a non-zero size and shall occupy one or morebytes of storage. Base class subobjects may have zero size. An object of trivially copyable or standard-layouttype (3.9) shall occupy contiguous bytes of storage.

6 [ Note: C++ provides a variety of built-in types and several ways of composing new types from existingtypes (3.9). end note ]

1.9 Program execution [intro.execution]

1 The semantic descriptions in this International Standard define a parameterized nondeterministic abstractmachine. 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, conformingimplementations are required to emulate (only) the observable behavior of the abstract machine as explainedbelow.4

2 Certain aspects and operations of the abstract machine are described in this International Standard asimplementation-defined (for example, sizeof(int)). These constitute the parameters of the abstract ma-chine. Each implementation shall include documentation describing its characteristics and behavior in theserespects.5 Such documentation shall define the instance of the abstract machine that corresponds to thatimplementation (referred to as the corresponding instance below).

3 Certain other aspects and operations of the abstract machine are described in this International Standard asunspecified (for example, order of evaluation of arguments to a function). Where possible, this InternationalStandard defines a set of allowable behaviors. These define the nondeterministic aspects of the abstractmachine. An instance of the abstract machine can thus have more than one possible execution sequence fora given program and a given input.

4 Certain other operations are described in this International Standard as undefined (for example, the effect ofdereferencing the null pointer). [ Note: this International Standard imposes no requirements on the behaviorof programs that contain undefined behavior. end note ]

5 A conforming implementation executing a well-formed program shall produce the same observable behavioras one of the possible execution sequences of the corresponding instance of the abstract machine with thesame program and the same input. However, if any such execution sequence contains an undefined operation,this International Standard places no requirement on the implementation executing that program with thatinput (not even with regard to operations preceding the first undefined operation).

4) This provision is sometimes called the as-if rule, because an implementation is free to disregard any requirement of thisInternational Standard as long as the result is as if the requirement had been obeyed, as far as can be determined from theobservable behavior of the program. For instance, an actual implementation need not evaluate part of an expression if it candeduce that its value is not used and that no side effects affecting the observable behavior of the program are produced.

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

1.9 7

c ISO/IEC N2800=08-0310

6 The observable behavior of the abstract machine is its sequence of reads and writes to volatile data andcalls to library I/O functions.6

7 When the processing of the abstract machine is interrupted by receipt of a signal, the values of objects whichare neither

of type volatile std::sig_atomic_t nor

lock-free atomic objects (29.2)

are unspecified, and the value of any object not in either of these two categories that is modified by thehandler becomes undefined.

8 An instance of each object with automatic storage duration (3.7.3) is associated with each entry into itsblock. Such an object exists and retains its last-stored value during the execution of the block and while theblock is suspended (by a call of a function or receipt of a signal).

9 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 thatexecution 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 promptingmessages actually appear prior to a program waiting for input. What constitutes an interactive deviceis implementation-defined.

[ Note: more stringent correspondences between abstract and actual semantics may be defined by eachimplementation. end note ]

10 [ Note: operators can be regrouped according to the usual mathematical rules only where the operators reallyare associative or commutative.7 For example, in the following fragment

int a, b;/ ... /a = a + 32760 + b + 5;

the expression statement behaves exactly the same asa = (((a + 32760) + b) + 5);

due to the associativity and precedence of these operators. Thus, the result of the sum (a + 32760) is nextadded to b, and that result is then added to 5 which results in the value assigned to a. On a machine in whichoverflows produce an exception and in which the range of values representable by an int is [-32768,+32767],the implementation cannot rewrite this expression as

a = ((a + b) + 32765);

since if the values for a and b were, respectively, -32754 and -15, the sum a + b would produce an exceptionwhile the original expression would not; nor can the expression be rewritten either as

a = ((a + 32765) + b);

or

6) An implementation can offer additional library I/O functions as an extension. Implementations that do so should treatcalls to those functions as observable behavior as well.

7) Overloaded operators are never assumed to be associative or commutative.

1.9 8

c ISO/IEC N2800=08-0310

a = (a + (b + 32765));

since the values for a and b might have been, respectively, 4 and -8 or -17 and 12. However on a machine inwhich overflows do not produce an exception and in which the results of overflows are reversible, the aboveexpression statement can be rewritten by the implementation in any of the above ways because the sameresult will occur. end note ]

11 A full-expression is an expression that is not a subexpression of another expression. If a language constructis defined to produce an implicit call of a function, a use of the language construct is considered to be anexpression for the purposes of this definition. A call to a destructor generated at the end of the lifetime ofan object other than a temporary object is an implicit full-expression. Conversions applied to the result ofan expression in order to satisfy the requirements of the language construct in which the expression appearsare also considered to be part of the full-expression.

[ Example:struct S {

S(int i): I(i) { }int& v() { return I; }

private:int I;

};

S s1(1); // full-expression is call of S::S(int)S s2 = 2; // full-expression is call of S::S(int)

void f() {if (S(3).v()) // full-expression includes lvalue-to-rvalue and

// int to bool conversions, performed before// temporary is deleted at end of full-expression

{ }}

end example ]

12 [ Note: the evaluation of a full-expression can include the evaluation of subexpressions that are not lexicallypart of the full-expression. For example, subexpressions involved in evaluating default argument expres-sions (8.3.6) are considered to be created in the expression that calls the function, not the expression thatdefines the default argument. end note ]

13 Accessing an object designated by a volatile lvalue (3.10), modifying an object, calling a library I/Ofunction, or calling a function that does any of those operations are all side effects, which are changes in thestate of the execution environment. Evaluation of an expression (or a sub-expression) in general includesboth value computations (including determining the identity of an object for lvalue evaluation and fetchinga value previously assigned to an object for rvalue evaluation) and initiation of side effects. When a call toa library I/O function returns or an access to a volatile object is evaluated the side effect is consideredcomplete, even though some external actions implied by the call (such as the I/O itself) or by the volatileaccess may not have completed yet.

14 Sequenced before is an asymmetric, transitive, pair-wise relation between evaluations executed by a singlethread, which induces a partial order among those evaluations. Given any two evaluations A and B, if A issequenced before B, then the execution of A shall precede the execution of B. If A is not sequenced beforeB and B is not sequenced before A, then A and B are unsequenced. [ Note: The execution of unsequencedevaluations can overlap. end note ] Evaluations A and B are indeterminately sequenced when either A

1.9 9

c ISO/IEC N2800=08-0310

is sequenced before B or B is sequenced before A, but it is unspecified which. [ Note: Indeterminatelysequenced evaluations cannot overlap, but either could be executed first. end note ]

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

16 Except where noted, evaluations of operands of individual operators and of subexpressions of individualexpressions are unsequenced. [ Note: In an expression that is evaluated more than once during the executionof a program, unsequenced and indeterminately sequenced evaluations of its subexpressions need not beperformed consistently in different evaluations. end note ] The value computations of the operands of anoperator are sequenced before the value computation of the result of the operator. If a side effect on a scalarobject is unsequenced relative to either another side effect on the same scalar object or a value computationusing 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 undefinedi = 7, i++, i++; // i becomes 9

i = i++ + 1; // the behavior is undefinedi = i + 1; // the value of i is incremented

f(i = -1, i = -1); // the behavior is undefined}

end example ]

When calling a function (whether or not the function is inline), every value computation and side effectassociated with any argument expression, or with the postfix expression designating the called function, issequenced before execution of every expression or statement in the body of the called function. [ Note: Valuecomputations and side effects associated with different argument expressions are unsequenced. end note ]Every evaluation in the calling function (including other function calls) that is not otherwise specificallysequenced before or after the execution of the body of the called function is indeterminately sequenced withrespect to the execution of the called function.9 Several contexts in C++ cause evaluation of a function call,even though no corresponding function call syntax appears in the translation unit. [ Example: Evaluation ofa new expression invokes one or more allocation and constructor functions; see 5.3.4. For another example,invocation of a conversion function (12.3.2) can arise in contexts in which no function call syntax appears. end example ] 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 functionmight be.

1.10 Multi-threaded executions and data races [intro.multithread]

1 Under a hosted implementation, a C++ program can have more than one thread of execution (a.k.a. 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 theexecution can be viewed as an interleaving of all its threads. However, some kinds of atomic operations, forexample, allow executions inconsistent with a simple interleaving, as described below. end note ] Under

8) As specified in 12.2, after a full-expression is evaluated, a sequence of zero or more invocations of destructor functions fortemporary objects takes place, usually in reverse order of the construction of each temporary object.

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

1.10 10

c ISO/IEC N2800=08-0310

a freestanding implementation, it is implementation-defined whether a program can have more than onethread of execution.

2 The value of an object visible to a thread T at a particular point might be the initial value of the object, avalue assigned to the object by T , or a value assigned to the object by another thread, according to the rulesbelow. [ Note: In some cases, there may instead be undefined behavior. Much of this section is motivatedby the desire to support atomic operations with explicit and detailed visibility constraints. However, it alsoimplicitly 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 ormodifies the same memory location.

4 The library defines a number of atomic operations (Clause 29) and operations on locks (Clause 30) that arespecially identified as synchronization operations. These operations play a special role in making assignmentsin one thread visible to another. A synchronization operation on one or more memory locations is either aconsume operation, an acquire operation, a release operation, or both an acquire and release operation. Asynchronization operation without an associated memory location is a fence and can be either an acquirefence, a release fence, or both an acquire and release fence. In addition, there are relaxed atomic operations,which are not synchronization operations, and atomic read-modify-write operations, which have specialcharacteristics. [ Note: For example, a call that acquires a lock will perform an acquire operation on thelocations comprising the lock. Correspondingly, a call that releases the same lock will perform a releaseoperation on those same locations. Informally, performing a release operation on A forces prior side effectson other memory locations to become visible to other threads that later perform a consume or an acquireoperation on A. We do not include relaxed atomic operations as synchronization operations although, likesynchronization operations, they cannot contribute to data races. end note ]

5 All modifications to a particular atomic object M occur in some particular total order, called the modificationorder of M . If A and B are modifications of an atomic object M and A happens before (as defined below)B, then A shall precede B in the modification order of M , which is defined below. [ Note: This states thatthe modification orders must respect happens before. end note ] [ Note: There is a separate order for eachscalar object. There is no requirement that these can be combined into a single total order for all objects.In general this will be impossible since different threads may observe modifications to different variables ininconsistent orders. end note ]

6 A release sequence on an atomic object M is a maximal contiguous sub-sequence of side effects in themodification order of M , where the first operation is a release, and every subsequent operation

is performed by the same thread that performed the release, or

is an atomic read-modify-write operation.

7 Certain library calls synchronize with other library calls performed by another thread. In particular, anatomic operation A that performs a release operation on an object M synchronizes with an atomic operationB that performs an acquire operation on M and reads a value written by any side effect in the releasesequence headed by A. [ Note: Except in the specified cases, reading a later value does not necessarily ensurevisibility as described below. Such a requirement would sometimes interfere with efficient implementation. end note ] [ Note: The specifications of the synchronization operations define when one reads the valuewritten by another. For atomic variables, the definition is clear. All operations on a given lock occur in asingle total order. Each lock acquisition reads the value written by the last lock release. end note ]

8 An evaluation A carries a dependency to an evaluation B if

the value of A is used as an operand of B, unless:

B is an invocation of any specialization of std::kill_dependency (29.1), or

1.10 11

c ISO/IEC N2800=08-0310

A is the left operand of a built-in logical AND (&&, see 5.14) or logical OR (||, see 5.15) operator,or

A is the left operand of a conditional (?:, see 5.16) operator, or

A is the left operand of the built-in comma (,) operator (5.18);

or

A writes a scalar object or bit-field M , B reads the value written by A from M , and A is sequencedbefore 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 Mand 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 ]

10 An evaluation A inter-thread happens before an evaluation B if

A synchronizes with B, or

A is dependency-ordered before B, or

for some evaluation X

A synchronizes with X and X is sequenced before B, or

A is sequenced before X and X inter-thread happens before B, or

A inter-thread happens before X and X inter-thread happens before B.

[ Note: The inter-thread happens before relation describes arbitrary concatenations of sequenced before,synchronizes with and dependency-ordered before relationships, with two exceptions. The first exceptionis that a concatenation is not permitted to end with dependency-ordered before followed by sequencedbefore. The reason for this limitation is that a consume operation participating in a dependency-orderedbefore relationship provides ordering only with respect to operations to which this consume operationactually carries a dependency. The reason that this limitation applies only to the end of such a concatenationis that any subsequent release operation will provide the required ordering for a prior consume operation.The second exception is that a concatenation is not permitted to consist entirely of sequenced before.The reasons for this limitation are (1) to permit inter-thread happens before to be transitively closed and(2) the happens before relation, defined below, provides for relationships consisting entirely of sequencedbefore. end note ]

11 An evaluation A happens before an evaluation B if:

A is sequenced before B, or

A inter-thread happens before B.

12 A visible side effect A on an object M with respect to a value computation B of M satisfies the conditions:

A happens before B, and

1.10 12

c ISO/IEC N2800=08-0310

there is no other side effect X to M such that A happens before X and X happens before B.

The value of a non-atomic scalar object M , as determined by evaluation B, shall be the value stored by thevisible side effect A. [ Note: If there is ambiguity about which side effect to a non-atomic object is visible,then there is a data race, and the behavior is undefined. end note ] [ Note: This states that operationson ordinary variables are not visibly reordered. This is not actually detectable without data races, but itis necessary to ensure that data races, as defined here, and with suitable restrictions on the use of atomics,correspond to data races in a simple interleaved (sequentially consistent) execution. end note ]

13 The visible sequence of side effects on an atomic object M , with respect to a value computation B of M , isa maximal contiguous sub-sequence of side effects in the modification order of M , where the first side effectis visible with respect to B, and for every subsequent side effect, it is not the case that B happens before it.The value of an atomic object M , as determined by evaluation B, shall be the value stored by some operationin the visible sequence of M with respect to B. Furthermore, if a value computation A of an atomic object Mhappens before a value computation B of M , and the value computed by A corresponds to the value storedby side effect X , then the value computed by B shall either equal the value computed by A, or be the valuestored by side effect Y , where Y follows X in the modification order of M . [ Note: This effectively disallowscompiler reordering of atomic operations to a single object, even if both operations are relaxed loads. Bydoing so, we effectively make the cache coherence guarantee provided by most hardware available to C++atomic operations. end note ] [ Note: The visible sequence depends on the happens before relation, whichdepends on the values observed by loads of atomics, which we are restricting here. The intended readingis that there must exist an association of atomic loads with modifications they observe that, together withsuitably chosen modification orders and the happens before relation derived as described above, satisfy theresulting constraints as imposed here. end note ]

14 The execution of a program contains a data race if it contains two conflicting actions in different threads,at least one of which is not atomic, and neither happens before the other. Any such data race results inundefined behavior. [ Note: It can be shown that programs that correctly use simple locks to prevent all dataraces, and use no other synchronization operations, behave as though the executions of their constituentthreads were simply interleaved, with each observed value of an object being the last value assigned in thatinterleaving. This is normally referred to a