Kkhksanfklhaklfh

Document Number: Date: Revises: Reply to:

N3337
2012-01-16 N3291 Stefanus Du Toit Intel Corporation cxxeditor@gmail.com

Working Draft, Standard for Programming Language C++

Note: this is an early draft. It’s known to be incomplet and incorrekt, and it has lots of ba d for matting.

c ISO/IEC

N3337

Contents
Contents List of Tables List of Figures 1 General 1.1 Scope . . . . . . . . . . . . . . . . . . . . 1.2 Normative references . . . . . . . . . . . . 1.3 Terms and deﬁnitions . . . . . . . . . . . . 1.4 Implementation compliance . . . . . . . . 1.5 Structure of this International Standard . 1.6 Syntax notation . . . . . . . . . . . . . . . 1.7 The C++ memory model . . . . . . . . . . 1.8 The C++ object model . . . . . . . . . . . 1.9 Program execution . . . . . . . . . . . . . 1.10 Multi-threaded executions and data races 1.11 Acknowledgments . . . . . . . . . . . . . . 2 Lexical conventions 2.1 Separate translation . . . . 2.2 Phases of translation . . . . 2.3 Character sets . . . . . . . . 2.4 Trigraph sequences . . . . . 2.5 Preprocessing tokens . . . . 2.6 Alternative tokens . . . . . 2.7 Tokens . . . . . . . . . . . . 2.8 Comments . . . . . . . . . . 2.9 Header names . . . . . . . . 2.10 Preprocessing numbers . . . 2.11 Identiﬁers . . . . . . . . . . 2.12 Keywords . . . . . . . . . . 2.13 Operators and punctuators 2.14 Literals . . . . . . . . . . . 3 Basic 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 Contents concepts Declarations and deﬁnitions One deﬁnition rule . . . . . Scope . . . . . . . . . . . . Name lookup . . . . . . . . Program and linkage . . . . Start and termination . . . Storage duration . . . . . . Object lifetime . . . . . . . Types . . . . . . . . . . . . Lvalues and rvalues . . . . . ii x xiv 1 1 1 2 5 5 6 6 7 8 11 14 16 16 16 17 18 19 20 20 20 20 21 21 22 22 23 32 32 34 36 42 55 58 62 65 69 74 ii

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

c ISO/IEC

N3337

3.11

Alignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

75 77 78 78 78 78 79 80 80 80 80 80 81 81 81 83 85 93 104 111 112 113 113 114 114 116 116 117 117 117 117 117 119 120 120 124 124 124 124 125 126 129 130 131

4 Standard conversions 4.1 Lvalue-to-rvalue conversion . . 4.2 Array-to-pointer conversion . . 4.3 Function-to-pointer conversion . 4.4 Qualiﬁcation conversions . . . . 4.5 Integral promotions . . . . . . . 4.6 Floating point promotion . . . 4.7 Integral conversions . . . . . . . 4.8 Floating point conversions . . . 4.9 Floating-integral conversions . . 4.10 Pointer conversions . . . . . . . 4.11 Pointer to member conversions 4.12 Boolean conversions . . . . . . 4.13 Integer conversion rank . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5 Expressions 5.1 Primary expressions . . . . . . . . . . . . . . . . 5.2 Postﬁx expressions . . . . . . . . . . . . . . . . . 5.3 Unary expressions . . . . . . . . . . . . . . . . . . 5.4 Explicit type conversion (cast notation) . . . . . 5.5 Pointer-to-member operators . . . . . . . . . . . 5.6 Multiplicative operators . . . . . . . . . . . . . . 5.7 Additive operators . . . . . . . . . . . . . . . . . 5.8 Shift operators . . . . . . . . . . . . . . . . . . . 5.9 Relational operators . . . . . . . . . . . . . . . . 5.10 Equality operators . . . . . . . . . . . . . . . . . 5.11 Bitwise AND operator . . . . . . . . . . . . . . . 5.12 Bitwise exclusive OR operator . . . . . . . . . . . 5.13 Bitwise inclusive OR operator . . . . . . . . . . . 5.14 Logical AND operator . . . . . . . . . . . . . . . 5.15 Logical OR operator . . . . . . . . . . . . . . . . 5.16 Conditional operator . . . . . . . . . . . . . . . . 5.17 Assignment and compound assignment operators 5.18 Comma operator . . . . . . . . . . . . . . . . . . 5.19 Constant expressions . . . . . . . . . . . . . . . . 6 Statements 6.1 Labeled statement . . . . . . 6.2 Expression statement . . . . . 6.3 Compound statement or block 6.4 Selection statements . . . . . 6.5 Iteration statements . . . . . 6.6 Jump statements . . . . . . . 6.7 Declaration statement . . . . 6.8 Ambiguity resolution . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

7 Declarations 133 7.1 Speciﬁers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 7.2 Enumeration declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 Contents iii

c ISO/IEC

N3337

7.3 7.4 7.5 7.6

Namespaces . . . . . . The asm declaration . Linkage speciﬁcations Attributes . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

152 164 164 167 172 173 174 175 187 190 204 206 207 210 213 214 216 216 217 218 219 220 222 225 229 231 232 233 236 239 240 240 240 242 242 244 246 249 252 253 259 261 269

8 Declarators 8.1 Type names . . . . . . 8.2 Ambiguity resolution . 8.3 Meaning of declarators 8.4 Function deﬁnitions . . 8.5 Initializers . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

9 Classes 9.1 Class names . . . . . . . 9.2 Class members . . . . . 9.3 Member functions . . . . 9.4 Static members . . . . . 9.5 Unions . . . . . . . . . . 9.6 Bit-ﬁelds . . . . . . . . . 9.7 Nested class declarations 9.8 Local class declarations 9.9 Nested type names . . . 10 Derived classes 10.1 Multiple base classes . 10.2 Member name lookup 10.3 Virtual functions . . . 10.4 Abstract classes . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

11 Member access control 11.1 Access speciﬁers . . . . . . . . . 11.2 Accessibility of base classes and 11.3 Friends . . . . . . . . . . . . . . 11.4 Protected member access . . . . 11.5 Access to virtual functions . . . 11.6 Multiple access . . . . . . . . . 11.7 Nested classes . . . . . . . . . .

. . . . . . . . . . . . base class members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

12 Special member functions 12.1 Constructors . . . . . . . . . . . 12.2 Temporary objects . . . . . . . . 12.3 Conversions . . . . . . . . . . . . 12.4 Destructors . . . . . . . . . . . . 12.5 Free store . . . . . . . . . . . . . 12.6 Initialization . . . . . . . . . . . . 12.7 Construction and destruction . . 12.8 Copying and moving class objects 12.9 Inheriting constructors . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

13 Overloading 273 13.1 Overloadable declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

Contents

iv

c ISO/IEC

N3337

13.2 13.3 13.4 13.5 13.6

Declaration matching . . . . . . Overload resolution . . . . . . . Address of overloaded function Overloaded operators . . . . . . Built-in operators . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

275 276 294 296 299 303 304 307 308 314 315 331 345 356 377 378 380 380 382 385 387 388 389 390 395 395 396 396 396 397 398 398 399 399 402 402 407 426 426 426 427 436 438 439 445 447

14 Templates 14.1 Template parameters . . . . . . . . . . . . 14.2 Names of template specializations . . . . . 14.3 Template arguments . . . . . . . . . . . . 14.4 Type equivalence . . . . . . . . . . . . . . 14.5 Template declarations . . . . . . . . . . . 14.6 Name resolution . . . . . . . . . . . . . . . 14.7 Template instantiation and specialization 14.8 Function template specializations . . . . . 15 Exception handling 15.1 Throwing an exception . . . . 15.2 Constructors and destructors 15.3 Handling an exception . . . . 15.4 Exception speciﬁcations . . . 15.5 Special functions . . . . . . . 16 Preprocessing directives 16.1 Conditional inclusion . . 16.2 Source ﬁle inclusion . . . 16.3 Macro replacement . . . 16.4 Line control . . . . . . . 16.5 Error directive . . . . . 16.6 Pragma directive . . . . 16.7 Null directive . . . . . . 16.8 Predeﬁned macro names 16.9 Pragma operator . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

17 Library introduction 17.1 General . . . . . . . . . . . . . . . . 17.2 The C standard library . . . . . . . . 17.3 Deﬁnitions . . . . . . . . . . . . . . . 17.4 Additional deﬁnitions . . . . . . . . . 17.5 Method of description (Informative) 17.6 Library-wide requirements . . . . . . 18 Language support library 18.1 General . . . . . . . . . . . . . 18.2 Types . . . . . . . . . . . . . . 18.3 Implementation properties . . . 18.4 Integer types . . . . . . . . . . 18.5 Start and termination . . . . . 18.6 Dynamic memory management 18.7 Type identiﬁcation . . . . . . . 18.8 Exception handling . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

Contents

v

c ISO/IEC

N3337

18.9 Initializer lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452 18.10 Other runtime support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453 19 Diagnostics library 19.1 General . . . . . . . 19.2 Exception classes . . 19.3 Assertions . . . . . . 19.4 Error numbers . . . 19.5 System error support 456 456 456 460 460 460 472 472 472 476 480 490 498 513 539 558 575 578 593 599 601 601 601 607 610 639 641 641 645 645 645 646 658 699 700 702 702 702 728 760 777 793 803

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

20 General utilities library 20.1 General . . . . . . . . . . . . . . . . . . . . 20.2 Utility components . . . . . . . . . . . . . . 20.3 Pairs . . . . . . . . . . . . . . . . . . . . . . 20.4 Tuples . . . . . . . . . . . . . . . . . . . . . 20.5 Class template bitset . . . . . . . . . . . . 20.6 Memory . . . . . . . . . . . . . . . . . . . . 20.7 Smart pointers . . . . . . . . . . . . . . . . 20.8 Function objects . . . . . . . . . . . . . . . 20.9 Metaprogramming and type traits . . . . . 20.10 Compile-time rational arithmetic . . . . . . 20.11 Time utilities . . . . . . . . . . . . . . . . . 20.12 Class template scoped_allocator_adaptor 20.13 Class type_index . . . . . . . . . . . . . . . 21 Strings library 21.1 General . . . . . . . . . . . . . . 21.2 Character traits . . . . . . . . . . 21.3 String classes . . . . . . . . . . . 21.4 Class template basic_string . . 21.5 Numeric conversions . . . . . . . 21.6 Hash support . . . . . . . . . . . 21.7 Null-terminated sequence utilities 22 Localization library 22.1 General . . . . . . . . . . . . . 22.2 Header synopsis . . . 22.3 Locales . . . . . . . . . . . . . . 22.4 Standard locale categories . . 22.5 Standard code conversion facets 22.6 C library locales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

23 Containers library 23.1 General . . . . . . . . . . . . . . 23.2 Container requirements . . . . . . 23.3 Sequence containers . . . . . . . 23.4 Associative containers . . . . . . 23.5 Unordered associative containers 23.6 Container adaptors . . . . . . . . 24 Iterators library

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

Contents

vi

c ISO/IEC

N3337

24.1 24.2 24.3 24.4 24.5 24.6

General . . . . . . . . . . . . Iterator requirements . . . . . Header synopsis . Iterator primitives . . . . . . Iterator adaptors . . . . . . . Stream iterators . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

803 803 808 811 815 828 836 836 846 851 859 872 874 874 874 875 876 886 931 952 955 960 960 960 961 963 965 984 994 1021 1032 1048 1048 1048 1049 1051 1057 1061 1061 1064 1069 1076 1082 1087 1093 1096

25 Algorithms library 25.1 General . . . . . . . . . . . . . . . 25.2 Non-modifying sequence operations 25.3 Mutating sequence operations . . . 25.4 Sorting and related operations . . . 25.5 C library algorithms . . . . . . . . 26 Numerics library 26.1 General . . . . . . . . . . . . . 26.2 Numeric type requirements . . 26.3 The ﬂoating-point environment 26.4 Complex numbers . . . . . . . . 26.5 Random number generation . . 26.6 Numeric arrays . . . . . . . . . 26.7 Generalized numeric operations 26.8 C library . . . . . . . . . . . . . 27 Input/output library 27.1 General . . . . . . . . . . . . 27.2 Iostreams requirements . . . . 27.3 Forward declarations . . . . . 27.4 Standard iostream objects . . 27.5 Iostreams base classes . . . . 27.6 Stream buﬀers . . . . . . . . . 27.7 Formatting and manipulators 27.8 String-based streams . . . . . 27.9 File-based streams . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

28 Regular expressions library 28.1 General . . . . . . . . . . . . . . . . . . . . . . . . 28.2 Deﬁnitions . . . . . . . . . . . . . . . . . . . . . . . 28.3 Requirements . . . . . . . . . . . . . . . . . . . . . 28.4 Header synopsis . . . . . . . . . . . . . . . 28.5 Namespace std::regex_constants . . . . . . . . . 28.6 Class regex_error . . . . . . . . . . . . . . . . . . 28.7 Class template regex_traits . . . . . . . . . . . . 28.8 Class template basic_regex . . . . . . . . . . . . . 28.9 Class template sub_match . . . . . . . . . . . . . . 28.10 Class template match_results . . . . . . . . . . . 28.11 Regular expression algorithms . . . . . . . . . . . . 28.12 Regular expression iterators . . . . . . . . . . . . . 28.13 Modiﬁed ECMAScript regular expression grammar 29 Atomic operations library

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Contents

vii

c ISO/IEC

N3337

29.1 29.2 29.3 29.4 29.5 29.6 29.7 29.8

General . . . . . . . . . . . Header synopsis . Order and consistency . . . Lock-free property . . . . . Atomic types . . . . . . . . Operations on atomic types Flag type and operations . . Fences . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

1096 1096 1099 1101 1102 1105 1111 1112 1114 1114 1114 1117 1122 1135 1144 1161 1161 1161 1165 1165 1169 1170 1174 1176 1176 1177 1177 1177 1178 1179 1181

30 Thread support library 30.1 General . . . . . . . 30.2 Requirements . . . . 30.3 Threads . . . . . . . 30.4 Mutual exclusion . . 30.5 Condition variables . 30.6 Futures . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

A Grammar summary A.1 Keywords . . . . . . . . . A.2 Lexical conventions . . . . A.3 Basic concepts . . . . . . . A.4 Expressions . . . . . . . . A.5 Statements . . . . . . . . A.6 Declarations . . . . . . . . A.7 Declarators . . . . . . . . A.8 Classes . . . . . . . . . . . A.9 Derived classes . . . . . . A.10 Special member functions A.11 Overloading . . . . . . . . A.12 Templates . . . . . . . . . A.13 Exception handling . . . . A.14 Preprocessing directives . B Implementation quantities

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

C Compatibility 1183 C.1 C++ and ISO C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1183 C.2 C++ and ISO C++ 2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1191 C.3 C standard library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1198 D Compatibility features D.1 Increment operator with bool operand D.2 register keyword . . . . . . . . . . . D.3 Implicit declaration of copy functions . D.4 Dynamic exception speciﬁcations . . . D.5 C standard library headers . . . . . . . D.6 Old iostreams members . . . . . . . . D.7 char* streams . . . . . . . . . . . . . . D.8 Function objects . . . . . . . . . . . . D.9 Binders . . . . . . . . . . . . . . . . . D.10 auto_ptr . . . . . . . . . . . . . . . . Contents 1202 1202 1202 1202 1202 1202 1202 1204 1213 1217 1218

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

viii

c ISO/IEC

N3337

D.11 Violating exception-speciﬁcations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1221 E Universal character names for identiﬁer characters 1222 E.1 Ranges of characters allowed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1222 E.2 Ranges of characters disallowed initially . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1222 F Cross references Index Index of grammar productions Index of library names Index of implementation-deﬁned behavior 1223 1240 1269 1272 1308

Contents

ix

c ISO/IEC

N3337

List of Tables
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 Trigraph sequences . . . . . . . Alternative tokens . . . . . . . Identiﬁers with special meaning Keywords . . . . . . . . . . . . Alternative representations . . Types of integer constants . . . Escape sequences . . . . . . . . String literal concatenations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 20 22 22 22 24 26 29 74

Relations on const and volatile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

simple-type-speciﬁers and the types they specify . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 Relationship between operator and function call notation . . . . . . . . . . . . . . . . . . . . . . 281 Conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 Library categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C++ library headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C++ headers for C library facilities . . . . . . . . . . . . . . . . . . . . . C++ headers for freestanding implementations . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . Hash requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Descriptive variable deﬁnitions . . . . . . . . . . . . . . . . . . . . . . . Allocator requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . Language support library summary Header synopsis . . . . Header synopsis . . . . Header synopsis . . . . . Header synopsis . . . . Header synopsis . . . . Header synopsis . . . . Header synopsis . . . Header synopsis . . . . Header synopsis . . . Header synopsis . . . . Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398 408 408 409 410 410 410 410 411 411 411 411 413 414 414 415 426 426 436 436 438 454 454 454 454 455 455 455

List of Tables

x

c ISO/IEC

N3337

41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87

Diagnostics library summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461 General utilities library summary . . . . . . . Header synopsis . . . . . . . . . . Header synopsis . . . . . . . . . . Primary type category predicates . . . . . . . Composite type category predicates . . . . . Type property predicates . . . . . . . . . . . Type property queries . . . . . . . . . . . . . Type relationship predicates . . . . . . . . . . Const-volatile modiﬁcations . . . . . . . . . . Reference modiﬁcations . . . . . . . . . . . . Sign modiﬁcations . . . . . . . . . . . . . . . Array modiﬁcations . . . . . . . . . . . . . . Pointer modiﬁcations . . . . . . . . . . . . . . Other transformations . . . . . . . . . . . . . Expressions used to perform ratio arithmetic Clock requirements . . . . . . . . . . . . . . . Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472 512 512 562 563 563 568 569 570 570 571 572 572 573 577 580 592

Strings library summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601 Character traits requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602 basic_string(const Allocator&) eﬀects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615 basic_string(const basic_string&) eﬀects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616 basic_string(const basic_string&, size_type, size_type, const Allocator&) eﬀects . 616 basic_string(const charT*, size_type, const Allocator&) eﬀects . . . . . . . . . . . . . . 616 basic_string(const charT*, const Allocator&) eﬀects . . . . . . . . . . . . . . . . . . . . . 617 basic_string(size_t, charT, const Allocator&) eﬀects . . . . . . . . . . . . . . . . . . . . 617 basic_string(const basic_string&, const Allocator&) and basic_string(basic_string&&, const Allocator&) eﬀects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618 operator=(const basic_string&) eﬀects . . . . . . . . . . . . . 618 operator=(const basic_string&&) eﬀects . . . . . . . . . . . . 618 compare() results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633 Potential mbstate_t data races . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644 Localization library summary Locale category facets . . . . Required specializations . . . do_in/do_out result values . do_unshift result values . . Integer conversions . . . . . . Length modiﬁer . . . . . . . . Integer conversions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645 649 649 668 669 672 673 677 xi

List of Tables

c ISO/IEC

N3337

88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111

Floating-point conversions . . . Length modiﬁer . . . . . . . . . Numeric conversions . . . . . . Fill padding . . . . . . . . . . . do_get_date eﬀects . . . . . . Header synopsis . . Potential setlocale data races

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

677 677 677 678 686 701 701 702 703 705 706 707 709 711 713 719 803 803 804 805 806 807 807 808

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) . . . . . . Unordered associative container requirements (in addition to container)

Iterators library summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . Relations among iterator categories . . . . . . . . . . . . . . . . . . . . . . . Iterator requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Input iterator requirements (in addition to Iterator) . . . . . . . . . . . . . Output iterator requirements (in addition to Iterator) . . . . . . . . . . . . Forward iterator requirements (in addition to input iterator) . . . . . . . . Bidirectional iterator requirements (in addition to forward iterator) . . . . . Random access iterator requirements (in addition to bidirectional iterator)

112 Algorithms library summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836 113 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 872 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 Numerics library summary . . . . . . . . . . . . Seed sequence requirements . . . . . . . . . . . . Uniform random number generator requirements Random number engine requirements . . . . . . Random number distribution requirements . . . Header synopsis . . . . . . . . . . . . . Header synopsis . . . . . . . . . . . . Input/output library summary fmtflags eﬀects . . . . . . . . fmtflags constants . . . . . . iostate eﬀects . . . . . . . . . openmode eﬀects . . . . . . . . seekdir eﬀects . . . . . . . . . Position type requirements . . basic_ios::init() eﬀects . . basic_ios::copyfmt() eﬀects seekoff positioning . . . . . . newoff values . . . . . . . . . . File open modes . . . . . . . . seekoff eﬀects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 874 888 889 890 893 955 956 960 970 970 970 970 971 975 977 979 1026 1026 1036 1038

List of Tables

xii

c ISO/IEC

N3337

134 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1046 135 Header synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1047 136 137 138 139 140 141 142 143 144 145 146 147 Regular expressions library summary . . . . . . . . . . . . . . Regular expression traits class requirements . . . . . . . . . . syntax_option_type eﬀects . . . . . . . . . . . . . . . . . . regex_constants::match_flag_type eﬀects when obtaining tainer sequence [first,last). . . . . . . . . . . . . . . . . . error_type values in the C locale . . . . . . . . . . . . . . . match_results assignment operator eﬀects . . . . . . . . . . Eﬀects of regex_match algorithm . . . . . . . . . . . . . . . Eﬀects of regex_search algorithm . . . . . . . . . . . . . . . Atomics library summary . . . . atomic integral typedefs . . . . . atomic typedefs . Atomic arithmetic computations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a . . . . . . . . . . . . . . . . . . . . . match . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . against a character con. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1048 1049 1058 1059 1060 1079 1082 1084 1096 1105 1106 1110

148 Thread support library summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1114 149 150 151 152 153 154 155 156 157 158 159 Standard Standard Standard Standard Standard macros . values . . types . . structs . functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1198 1198 1199 1199 1200 1202 1206 1206 1206 1209 1209

C headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . strstreambuf(streamsize) eﬀects . . . . . . . . . . . . . . . . strstreambuf(void* (*)(size_t), void (*)(void*)) eﬀects strstreambuf(charT*, streamsize, charT*) eﬀects . . . . . . seekoff positioning . . . . . . . . . . . . . . . . . . . . . . . . . newoff values . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

List of Tables

xiii

c ISO/IEC

N3337

List of Figures
1 2 3 4 5 6 7 Expression category taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Directed acyclic graph . . . . Non-virtual base . . . . . . . Virtual base . . . . . . . . . . Virtual and non-virtual base Name lookup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 220 221 222 222 224

Stream position, oﬀset, and size types [non-normative] . . . . . . . . . . . . . . . . . . . . . . . . 960

List of Figures

xiv

c ISO/IEC

N3337

1
1.1
1

General
Scope

[intro]
[intro.scope]

2

This International Standard speciﬁes requirements for implementations of the C++ programming language. The ﬁrst such requirement is that they implement the language, and so this International Standard also deﬁnes C++. Other requirements and relaxations of the ﬁrst requirement appear at various places within this International Standard. C++ is a general purpose programming language based on the C programming language as described in ISO/IEC 9899:1999 Programming languages — C (hereinafter referred to as the C standard). In addition to the facilities provided by C, C++ provides additional data types, classes, templates, exceptions, namespaces, operator overloading, function name overloading, references, free store management operators, and additional library facilities.

1.2
1

Normative references

[intro.refs]

The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. — Ecma International, ECMAScript Language Speciﬁcation, Standard Ecma-262, third edition, 1999. — ISO/IEC 2382 (all parts), Information technology — Vocabulary — ISO/IEC 9899:1999, Programming languages — C — ISO/IEC 9899:1999/Cor.1:2001(E), Programming languages — C, Technical Corrigendum 1 — ISO/IEC 9899:1999/Cor.2:2004(E), Programming languages — C, Technical Corrigendum 2 — ISO/IEC 9899:1999/Cor.3:2007(E), Programming languages — C, Technical Corrigendum 3 — ISO/IEC 9945:2003, Information Technology — Portable Operating System Interface (POSIX) — 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 and system software interfaces — Extensions for the programming language C to support new character data types

2

3 4 5

The library described in Clause 7 of ISO/IEC 9899:1999 and Clause 7 of ISO/IEC 9899:1999/Cor.1:2001 and Clause 7 of ISO/IEC 9899:1999/Cor.2:2003 is hereinafter called the C standard library.1 The library described in ISO/IEC TR 19769:2004 is hereinafter called the C Unicode TR. The operating system interface described in ISO/IEC 9945:2003 is hereinafter called POSIX . The ECMAScript Language Speciﬁcation described in Standard Ecma-262 is hereinafter called ECMA-262 .
1) With the qualiﬁcations noted in Clauses 18 through 30 and in C.3, the C standard library is a subset of the C++ standard library.

§ 1.2

1

c ISO/IEC

N3337

1.3
1 2 3

Terms and deﬁnitions

[intro.defs]

For the purposes of this document, the following deﬁnitions apply. 17.3 deﬁnes additional terms that are used only in Clauses 17 through 30 and Annex D. Terms that are used only in a small portion of this International Standard are deﬁned where they are used and italicized where they are deﬁned. 1.3.1 [defns.argument] argument actual argument actual parameter expression in the comma-separated list bounded by the parentheses 1.3.2 [defns.argument.macro] argument actual argument actual parameter sequence of preprocessing tokens in the comma-separated list bounded by the parentheses 1.3.3 argument actual argument actual parameter the operand of throw [defns.argument.throw]

1.3.4 [defns.argument.templ] argument actual argument actual parameter expression, type-id or template-name in the comma-separated list bounded by the angle brackets 1.3.5 [defns.cond.supp] conditionally-supported program construct that an implementation is not required to support [ Note: Each implementation documents all conditionally-supported constructs that it does not support. — end note ] 1.3.6 [defns.diagnostic] diagnostic message message belonging to an implementation-deﬁned subset of the implementation’s output messages 1.3.7 [defns.dynamic.type] dynamic type type of the most derived object (1.8) to which the glvalue denoted by a glvalue 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 from B (Clause 10), the dynamic type of the expression *p is “D.” References (8.3.2) are treated similarly. — end example ] 1.3.8 § 1.3 [defns.dynamic.type.prvalue] 2

c ISO/IEC

N3337

dynamic type static type of the prvalue expression 1.3.9 ill-formed program program that is not well formed [defns.ill.formed]

1.3.10 [defns.impl.deﬁned] implementation-deﬁned behavior behavior, for a well-formed program construct and correct data, that depends on the implementation and that each implementation documents 1.3.11 implementation limits restrictions imposed upon programs by the implementation [defns.impl.limits]

1.3.12 [defns.locale.speciﬁc] locale-speciﬁc behavior behavior that depends on local conventions of nationality, culture, and language that each implementation documents 1.3.13 [defns.multibyte] multibyte character sequence of one or more bytes representing a member of the extended character set of either the source or the execution environment [ Note: The extended character set is a superset of the basic character set (2.3). — end note ] 1.3.14 [defns.parameter] parameter formal argument formal parameter object or reference declared as part of a function declaration or deﬁnition or in the catch clause of an exception handler that acquires a value on entry to the function or handler 1.3.15 [defns.parameter.macro] parameter formal argument formal parameter identiﬁer from the comma-separated list bounded by the parentheses immediately following the macro name 1.3.16 parameter formal argument formal parameter template-parameter 1.3.17 signature [defns.parameter.templ]

[defns.signature]

§ 1.3

3

c ISO/IEC

N3337

name, parameter type list (8.3.5), and enclosing namespace (if any) [ Note: Signatures are used as a basis for name mangling and linking. — end note ] 1.3.18 [defns.signature.templ] signature name, parameter type list (8.3.5), enclosing namespace (if any), return type, and template parameter list 1.3.19 [defns.signature.spec] signature signature of the template of which it is a specialization and its template arguments (whether explicitly speciﬁed or deduced) 1.3.20 [defns.signature.member] signature name, parameter type list (8.3.5), class of which the function is a member, cvqualiﬁers (if any), and ref-qualiﬁer (if any) 1.3.21 [defns.signature.member.templ] signature name, parameter type list (8.3.5), class of which the function is a member, cv-qualiﬁers (if any), ref-qualiﬁer (if any), return type, and template parameter list 1.3.22 [defns.signature.member.spec] signature signature of the member function template of which it is a specialization and its template arguments (whether explicitly speciﬁed or deduced) 1.3.23 [defns.static.type] static type type of an expression (3.9) resulting from analysis of the program without considering execution semantics [ Note: The static type of an expression depends only on the form of the program in which the expression appears, and does not change while the program is executing. — end note ] 1.3.24 [defns.undeﬁned] undeﬁned behavior behavior for which this International Standard imposes no requirements [ Note: Undeﬁned behavior may be expected when this International Standard omits any explicit deﬁnition of behavior or when a program uses an erroneous construct or erroneous data. Permissible undeﬁned 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 undeﬁned behavior; they are required to be diagnosed. — end note ] 1.3.25 [defns.unspeciﬁed] unspeciﬁed behavior behavior, for a well-formed program construct and correct data, that depends on the implementation

§ 1.3

4

c ISO/IEC

N3337

[ 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 C++ program constructed according to the syntax rules, diagnosable semantic rules, and the One Deﬁnition Rule (3.2).

1.4
1

Implementation compliance

[intro.compliance]

2

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 “undeﬁned behavior.” 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 implementation shall, within its resource limits, accept and correctly execute2 that program. — If a program contains a violation of any diagnosable rule or an occurrence of a construct described in this 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 International Standard places no requirement on implementations with respect to that program.

3

4

5

6

7

8

9

For classes and class templates, the library Clauses specify partial deﬁnitions. Private members (Clause 11) are not speciﬁed, but each implementation shall supply them to complete the deﬁnitions according to the description in the library Clauses. For functions, function templates, objects, and values, the library Clauses specify declarations. Implementations shall supply deﬁnitions consistent with the descriptions in the library Clauses. The names deﬁned in the library have namespace scope (7.3). A C++ translation unit (2.2) obtains access to these names by including the appropriate standard library header (16.2). The templates, classes, functions, and objects in the library have external linkage (3.5). The implementation provides deﬁnitions for standard library entities, as necessary, while combining translation units to form a complete C++ program (2.2). Two kinds of implementations are deﬁned: a hosted implementation and a freestanding implementation. For a hosted implementation, this International Standard deﬁnes the set of available libraries. A freestanding implementation is one in which execution may take place without the beneﬁt of an operating system, and has an implementation-deﬁned set of libraries that includes certain language-support libraries (17.6.1.3). 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. Each implementation shall include documentation that identiﬁes all conditionally-supported constructs that it does not support and deﬁnes all locale-speciﬁc characteristics.3

1.5
1

Structure of this International Standard

[intro.structure]

Clauses 2 through 16 describe the C++ programming language. That description includes detailed syntactic speciﬁcations in a form described in 1.6. For convenience, Annex A repeats all such syntactic speciﬁcations.
2) “Correct execution” can include undeﬁned behavior, depending on the data being processed; see 1.3 and 1.9. 3) This documentation also deﬁnes implementation-deﬁned behavior; see 1.9.

§ 1.5

5

c ISO/IEC

N3337

2

3 4

5

Clauses 18 through 30 and Annex D (the 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 17. Annex B recommends lower bounds on the capacity of conforming implementations. Annex C summarizes the evolution of C++ since its ﬁrst published description, and explains in detail the diﬀerences between C++ and C. Certain features of C++ exist solely for compatibility purposes; Annex D describes those features. 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
1

Syntax notation

[syntax]

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 too long to ﬁt on a line, the text is continued on subsequent lines indented from the ﬁrst one. An optional terminal or non-terminal symbol is indicated by the subscript “opt ”, so
{ expressionopt }

2

indicates an optional expression enclosed in braces. Names for syntactic categories have generally been chosen according to the following rules: — X-name is a use of an identiﬁer in a context that determines its meaning (e.g., class-name, typedefname). — X-id is an identiﬁer with no context-dependent meaning (e.g., qualiﬁed-id). — X-seq is one or more X ’s without intervening delimiters (e.g., declaration-seq is a sequence of declarations). — X-list is one or more X ’s separated by intervening commas (e.g., expression-list is a sequence of expressions separated by commas).

1.7
1

The C++ memory model

[intro.memory]

2 3

4

5

The fundamental storage unit in the C++ memory model is the byte. A byte is at least large enough to contain any member of the basic execution character set (2.3) and the eight-bit code units of the Unicode UTF-8 encoding form and is composed of a contiguous sequence of bits, the number of which is implementationdeﬁned. The least signiﬁcant bit is called the low-order bit; the most signiﬁcant bit is called the high-order bit. The memory available to a C++ program consists of one or more sequences of contiguous bytes. Every byte has a unique address. [ Note: The representation of types is described in 3.9. — end note ] A memory location is either an object of scalar type or a maximal sequence of adjacent bit-ﬁelds 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 implementation. — end note ] Two or more threads of execution (1.10) can update and access separate memory locations without interfering with each other. [ Note: Thus a bit-ﬁeld and an adjacent non-bit-ﬁeld are in separate memory locations, and therefore can be concurrently updated by two threads of execution without interference. The same applies to two bit-ﬁelds, 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-ﬁeld declaration, or if they are separated by a non-bit-ﬁeld declaration. It is not safe to concurrently update two bit-ﬁelds in the same struct if all ﬁelds between them are also bit-ﬁelds of non-zero width. — end note ] [ Example: A structure declared as § 1.7 6

c ISO/IEC

N3337

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

contains four separate memory locations: The ﬁeld a and bit-ﬁelds d and e.ee are each separate memory locations, and can be modiﬁed concurrently without interfering with each other. The bit-ﬁelds b and c together constitute the fourth memory location. The bit-ﬁelds b and c cannot be concurrently modiﬁed, but b and a, for example, can be. — end example ]

1.8
1

The C++ object model

[intro.object]

2

3

The constructs in a C++ program create, destroy, refer to, access, and manipulate objects. An object is a region of storage. [ Note: A function is not an object, regardless of whether or not it occupies storage in the way that objects do. — end note ] An object is created by a deﬁnition (3.1), by a new-expression (5.3.4) or by the implementation (12.2) when needed. The properties of an object are determined when the object is created. An object can have a name (Clause 3). An object has a storage duration (3.7) which inﬂuences its lifetime (3.8). An object has a type (3.9). The term object type refers to the type with which the object is created. Some objects are polymorphic (10.3); the implementation generates information associated with each such object that makes it possible to determine that object’s type during program execution. For other objects, the interpretation of the values found therein is determined by the type of the expressions (Clause 5) used to access them. Objects can contain other objects, called subobjects. A subobject can be a member subobject (9.2), a base class subobject (Clause 10), or an array element. An object that is not a subobject of any other object is called a complete object. 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

5

6

If a complete object, a data member (9.2), or an array element is of class type, its type is considered the most derived class, to distinguish it from the class type of any base class subobject; an object of a most derived class type or of a non-class type is called a most derived object. Unless it is a bit-ﬁeld (9.6), a most derived object shall have a non-zero size and shall occupy one or more bytes of storage. Base class subobjects may have zero size. An object of trivially copyable or standard-layout type (3.9) shall occupy contiguous bytes of storage. Unless an object is a bit-ﬁeld or a base class subobject of zero size, the address of that object is the address of the ﬁrst byte it occupies. Two objects that are not bit-ﬁelds may have the same address if one is a subobject of the other, or if at least one is a base class subobject of zero size and they are of diﬀerent types; otherwise, they shall have distinct addresses.4 [ Example: static const char test1 = ’x’; static const char test2 = ’x’; const bool b = &test1 != &test2;

// always true

7

— end example ] [ Note: C++ provides a variety of fundamental types and several ways of composing new types from existing types (3.9). — end note ]
4) Under the “as-if” rule an implementation is allowed to store two objects at the same machine address or not store an object at all if the program cannot observe the diﬀerence (1.9).

§ 1.8

7

c ISO/IEC

N3337

1.9
1

Program execution

[intro.execution]

2

3

4

5

6

The semantic descriptions in this International Standard deﬁne 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 implementations are required to emulate (only) the observable behavior of the abstract machine as explained below.5 Certain aspects and operations of the abstract machine are described in this International Standard as implementation-deﬁned (for example, sizeof(int)). These constitute the parameters of the abstract machine. Each implementation shall include documentation describing its characteristics and behavior in these respects.6 Such documentation shall deﬁne the instance of the abstract machine that corresponds to that implementation (referred to as the “corresponding instance” below). Certain other aspects and operations of the abstract machine are described in this International Standard as unspeciﬁed (for example, order of evaluation of arguments to a function). Where possible, this International Standard deﬁnes a set of allowable behaviors. These deﬁne the nondeterministic aspects of the abstract machine. An instance of the abstract machine can thus have more than one possible execution for a given program and a given input. Certain other operations are described in this International Standard as undeﬁned (for example, the eﬀect of attempting to modify a const object). [ Note: This International Standard imposes no requirements on the behavior of programs that contain undeﬁned behavior. — end note ] A conforming implementation executing a well-formed program shall produce the same observable behavior as one of the possible executions of the corresponding instance of the abstract machine with the same program and the same input. However, if any such execution contains an undeﬁned operation, this International Standard places no requirement on the implementation executing that program with that input (not even with regard to operations preceding the ﬁrst undeﬁned operation). When the processing of the abstract machine is interrupted by receipt of a signal, the values of objects which are neither — of type volatile std::sig_atomic_t nor — lock-free atomic objects (29.4) are unspeciﬁed during the execution of the signal handler, and the value of any object not in either of these two categories that is modiﬁed by the handler becomes undeﬁned. An instance of each object with automatic storage duration (3.7.3) is associated with each entry into its block. Such an object exists and retains its last-stored value during the execution of the block and while the block is suspended (by a call of a function or receipt of a signal). 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 ﬁles 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-deﬁned.
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 eﬀects aﬀecting the observable behavior of the program are produced. 6) This documentation also includes conditionally-supported constructs and locale-speciﬁc behavior. See 1.4.

7

8

§ 1.9

8

c ISO/IEC

N3337

9

These collectively are referred to as the observable behavior of the program. [ Note: More stringent correspondences between abstract and actual semantics may be deﬁned by each implementation. — end note ] [ Note: Operators can be regrouped according to the usual mathematical rules only where the operators really are 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 as a = (((a + 32760) + b) + 5);

due to the associativity and precedence of these operators. Thus, the result of the sum (a + 32760) is next added to b, and that result is then added to 5 which results in the value assigned to a. On a machine in which overﬂows 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 exception while the original expression would not; nor can the expression be rewritten either as a = ((a + 32765) + b);

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

10

since the values for a and b might have been, respectively, 4 and -8 or -17 and 12. However on a machine in which overﬂows do not produce an exception and in which the results of overﬂows are reversible, the above expression statement can be rewritten by the implementation in any of the above ways because the same result will occur. — end note ] A full-expression is an expression that is not a subexpression of another expression. If a language construct is deﬁned to produce an implicit call of a function, a use of the language construct is considered to be an expression for the purposes of this deﬁnition. A call to a destructor generated at the end of the lifetime of an object other than a temporary object is an implicit full-expression. Conversions applied to the result of an expression in order to satisfy the requirements of the language construct in which the expression appears are 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); S s2 = 2; void f() { if (S(3).v()) // full-expression is call of S::S(int) // full-expression is call of S::S(int)

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

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

§ 1.9

9

c ISO/IEC

N3337

11

12

13

14

15

— end example ] [ Note: The evaluation of a full-expression can include the evaluation of subexpressions that are not lexically part of the full-expression. For example, subexpressions involved in evaluating default arguments (8.3.6) are considered to be created in the expression that calls the function, not the expression that deﬁnes the default argument. — end note ] Accessing an object designated by a volatile glvalue (3.10), modifying an object, calling a library I/O function, or calling a function that does any of those operations are all side eﬀects, 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 eﬀects. When a call to a library I/O function returns or an access to a volatile object is evaluated the side eﬀect 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. Sequenced before is an asymmetric, transitive, pair-wise relation between evaluations executed by a single thread (1.10), which induces a partial order among those evaluations. Given any two evaluations A 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 unspeciﬁed which. [ Note: Indeterminately sequenced evaluations cannot overlap, but either could be executed ﬁrst. — end note ] Every value computation and side eﬀect associated with a full-expression is sequenced before every value computation and side eﬀect associated with the next full-expression to be evaluated.8 . 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 diﬀerent 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 eﬀect on a scalar object is unsequenced relative to either another side eﬀect on the same scalar object or a value computation using the value of the same scalar object, the behavior is undeﬁned. [ Example: void f(int, int); void g(int i, int* v) { i = v[i++]; // the behavior is undeﬁned i = 7, i++, i++; // i becomes 9 i = i++ + 1; i = i + 1; f(i = -1, i = -1); } // the behavior is undeﬁned // the value of i is incremented // the behavior is undeﬁned

— end example ] When calling a function (whether or not the function is inline), every value computation and side eﬀect associated with any argument expression, or with the postﬁx expression designating the called function, is sequenced before execution of every expression or statement in the body of the called function. [ Note: Value computations and side eﬀects associated with diﬀerent argument expressions are unsequenced. — end note ] Every evaluation in the calling function (including other function calls) that is not otherwise speciﬁcally sequenced before or after the execution of the body of the called function is indeterminately sequenced with respect to the execution of the called function.9 Several contexts in C++ cause evaluation of a function call,
8) As speciﬁed in 12.2, after a full-expression is evaluated, a sequence of zero or more invocations of destructor functions for temporary 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.9

10

c ISO/IEC

N3337

even though no corresponding function call syntax appears in the translation unit. [ Example: Evaluation of a 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 function might be.

1.10
1

Multi-threaded executions and data races

[intro.multithread]

2

3

4

5

6

A thread of execution (also known as a thread) is a single ﬂow of control within a program, including the initial invocation of a speciﬁc 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 deﬁned 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-deﬁned whether a program can have more than one thread of execution. Implementations should ensure that all unblocked threads eventually make progress. [ Note: Standard library functions may silently block on I/O or locks. Factors in the execution environment, including externally-imposed thread priorities, may prevent an implementation from making certain guarantees of forward progress. — end note ] 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 undeﬁned 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 ] Two expression evaluations conﬂict if one of them modiﬁes a memory location (1.7) and the other one accesses or modiﬁes the same memory location. The library deﬁnes a number of atomic operations (Clause 29) and operations on mutexes (Clause 30) that are specially identiﬁed as synchronization operations. These operations play a special role in making assignments in one thread visible to another. A synchronization operation on one or more memory locations is either a consume operation, an acquire operation, a release operation, or both an acquire and release operation. A synchronization operation without an associated memory location is a fence and can be either an acquire fence, 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 special characteristics. [ Note: For example, a call that acquires a mutex will perform an acquire operation on the locations comprising the mutex. Correspondingly, a call that releases the same mutex will perform a release operation on those same locations. Informally, performing a release operation on A forces prior side eﬀects on other memory locations to become visible to other threads that later perform a consume or an acquire operation on A. “Relaxed” atomic operations are not synchronization operations even though, like synchronization operations, they cannot contribute to data races. — end note ] All modiﬁcations to a particular atomic object M occur in some particular total order, called the modiﬁcation order of M . If A and B are modiﬁcations of an atomic object M and A happens before (as deﬁned below) B, then A shall precede B in the modiﬁcation order of M , which is deﬁned below. [ Note: This states that the modiﬁcation orders must respect the “happens before” relationship. — end note ] [ Note: There is a separate order for each atomic object. There is no requirement that these can be combined into a single total order for
10) An object with automatic or thread storage duration (3.7) is associated with one speciﬁc thread, and can be accessed by a diﬀerent thread only indirectly through a pointer or reference (3.9.2).

§ 1.10

11

c ISO/IEC

N3337

7

all objects. In general this will be impossible since diﬀerent threads may observe modiﬁcations to diﬀerent objects in inconsistent orders. — end note ] A release sequence headed by a release operation A on an atomic object M is a maximal contiguous subsequence of side eﬀects in the modiﬁcation order of M , where the ﬁrst operation is A, and every subsequent operation — is performed by the same thread that performed A, or — is an atomic read-modify-write operation.

8

9

Certain library calls synchronize with other library calls performed by another thread. For example, an atomic store-release synchronizes with a load-acquire that takes its value from the store (29.3). [ Note: Except in the speciﬁed cases, reading a later value does not necessarily ensure visibility as described below. Such a requirement would sometimes interfere with eﬃcient implementation. — end note ] [ Note: The speciﬁcations of the synchronization operations deﬁne when one reads the value written by another. For atomic objects, the deﬁnition is clear. All operations on a given mutex occur in a single total order. Each mutex acquisition “reads the value written” by the last mutex release. — end note ] 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.3), or — 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-ﬁeld 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 intrathread. — end note ] An evaluation A is dependency-ordered before an evaluation B if — A performs a release operation on an atomic object M , and, in another thread, B performs a consume operation on M and reads a value written by any side eﬀect 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 ] 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 § 1.10 12

10

11

c ISO/IEC

N3337

— 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 ﬁrst exception is that a concatenation is not permitted to end with “dependency-ordered before” followed by “sequenced before”. The reason for this limitation is that a consume operation participating in a “dependencyordered before” relationship provides ordering only with respect to operations to which this consume operation actually carries a dependency. The reason that this limitation applies only to the end of such a concatenation is 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, deﬁned below, provides for relationships consisting entirely of “sequenced before”. — end note ] An evaluation A happens before an evaluation B if: — A is sequenced before B, or — A inter-thread happens before B. The implementation shall ensure that no program execution demonstrates a cycle in the “happens before” relation. [ Note: This cycle would otherwise be possible only through the use of consume operations. — end note ] A visible side eﬀect A on a scalar object or bit-ﬁeld M with respect to a value computation B of M satisﬁes the conditions: — A happens before B and — there is no other side eﬀect X to M such that A happens before X and X happens before B. The value of a non-atomic scalar object or bit-ﬁeld M , as determined by evaluation B, shall be the value stored by the visible side eﬀect A. [ Note: If there is ambiguity about which side eﬀect to a non-atomic object or bit-ﬁeld is visible, then the behavior is either unspeciﬁed or undeﬁned. — end note ] [ Note: This states that operations on ordinary objects are not visibly reordered. This is not actually detectable without data races, but it is necessary to ensure that data races, as deﬁned below, and with suitable restrictions on the use of atomics, correspond to data races in a simple interleaved (sequentially consistent) execution. — end note ] The visible sequence of side eﬀects on an atomic object M , with respect to a value computation B of M , is a maximal contiguous sub-sequence of side eﬀects in the modiﬁcation order of M , where the ﬁrst side eﬀect is visible with respect to B, and for every side eﬀect, 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 operation in the visible sequence of M with respect to B. [ Note: It can be shown that the visible sequence of side eﬀects of a value computation is unique given the coherence requirements below. — end note ] If an operation A that modiﬁes an atomic object M happens before an operation B that modiﬁes M , then A shall be earlier than B in the modiﬁcation order of M . [ Note: This requirement is known as write-write coherence. — end note ] If a value computation A of an atomic object M happens before a value computation B of M , and A takes its value from a side eﬀect X on M , then the value computed by B shall either be the value stored by X or the value stored by a side eﬀect Y on M , where Y follows X in the modiﬁcation order of M . [ Note: This requirement is known as read-read coherence. — end note ] If a value computation A of an atomic object M happens before an operation B on M , then A shall take its value from a side eﬀect X on M , where X precedes B in the modiﬁcation order of M . [ Note: This requirement is known as read-write coherence. — end note ] § 1.10 13

12

13

14

15

16

17

c ISO/IEC

N3337

18

19

20

21

22

23

24

If a side eﬀect X on an atomic object M happens before a value computation B of M , then the evaluation B shall take its value from X or from a side eﬀect Y that follows X in the modiﬁcation order of M . [ Note: This requirement is known as write-read coherence. — end note ] [ Note: The four preceding coherence requirements eﬀectively disallow compiler reordering of atomic operations to a single object, even if both operations are relaxed loads. This eﬀectively makes the cache coherence guarantee provided by most hardware available to C++ atomic operations. — end note ] [ Note: The visible sequence of side eﬀects depends on the “happens before” relation, which depends on the values observed by loads of atomics, which we are restricting here. The intended reading is that there must exist an association of atomic loads with modiﬁcations they observe that, together with suitably chosen modiﬁcation orders and the “happens before” relation derived as described above, satisfy the resulting constraints as imposed here. — end note ] The execution of a program contains a data race if it contains two conﬂicting actions in diﬀerent threads, at least one of which is not atomic, and neither happens before the other. Any such data race results in undeﬁned behavior. [ Note: It can be shown that programs that correctly use mutexes and memory_order_seq_cst operations to prevent all data races and use no other synchronization operations behave as if the operations executed by their constituent threads were simply interleaved, with each value computation of an object being taken from the last side eﬀect on that object in that interleaving. This is normally referred to as “sequential consistency”. However, this applies only to data-race-free programs, and data-race-free programs cannot observe most program transformations that do not change single-threaded program semantics. In fact, most single-threaded program transformations continue to be allowed, since any program that behaves diﬀerently as a result must perform an undeﬁned operation. — end note ] [ Note: Compiler transformations that introduce assignments to a potentially shared memory location that would not be modiﬁed by the abstract machine are generally precluded by this standard, since such an assignment might overwrite another assignment by a diﬀerent thread in cases in which an abstract machine execution would not have encountered a data race. This includes implementations of data member assignment that overwrite adjacent members in separate memory locations. Reordering of atomic loads in cases in which the atomics in question may alias is also generally precluded, since this may violate the “visible sequence” rules. — end note ] [ Note: Transformations that introduce a speculative read of a potentially shared memory location may not preserve the semantics of the C++ program as deﬁned in this standard, since they potentially introduce a data race. However, they are typically valid in the context of an optimizing compiler that targets a speciﬁc machine with well-deﬁned semantics for data races. They would be invalid for a hypothetical machine that is not tolerant of races or provides hardware race detection. — end note ] The implementation may assume that any thread will eventually do one of the following: — terminate, — make a call to a library I/O function, — access or modify a volatile object, or — perform a synchronization operation or an atomic operation. [ Note: This is intended to allow compiler transformations such as removal of empty loops, even when termination cannot be proven. — end note ] An implementation should ensure that the last value (in modiﬁcation order) assigned by an atomic or synchronization operation will become visible to all other threads in a ﬁnite period of time.

25

1.11
1

Acknowledgments

[intro.ack]

The C++ programming language as described in this International Standard is based on the language as described in Chapter R (Reference Manual) of Stroustrup: The C++ Programming Language (second edition, Addison-Wesley Publishing Company, ISBN 0-201-53992-6, copyright c 1991 AT&T). That, in turn, is based § 1.11 14

c ISO/IEC

N3337

2

3 4

on the C programming language as described in Appendix A of Kernighan and Ritchie: The C Programming Language (Prentice-Hall, 1978, ISBN 0-13-110163-3, copyright c 1978 AT&T). Portions of the library Clauses of this International Standard are based on work by P.J. Plauger, which was published as The Draft Standard C++ Library (Prentice-Hall, ISBN 0-13-117003-1, copyright c 1995 P.J. Plauger). POSIX R is a registered trademark of the Institute of Electrical and Electronic Engineers, Inc. All rights in these originals are reserved.

§ 1.11

15

c ISO/IEC

N3337

2
2.1
1

Lexical conventions
Separate translation

[lex]
[lex.separate]

2

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

2.2
1

Phases of translation
11

[lex.phases]

The precedence among the syntax rules of translation is speciﬁed by the following phases. 1. Physical source ﬁle characters are mapped, in an implementation-deﬁned manner, to the basic source character set (introducing new-line characters for end-of-line indicators) if necessary. The set of physical source ﬁle characters accepted is implementation-deﬁned. Trigraph sequences (2.4) are replaced by corresponding single-character internal representations. Any source ﬁle character not in the basic source character set (2.3) is replaced by the universal-character-name that designates that character. (An implementation may use any internal encoding, so long as an actual extended character encountered in the source ﬁle, and the same extended character expressed in the source ﬁle as a universal-character-name (i.e., using the \uXXXX notation), are handled equivalently except where this replacement is reverted in a raw string literal.) 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 undeﬁned. A source ﬁle 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 ﬁle. 3. The source ﬁle is decomposed into preprocessing tokens (2.5) and sequences of white-space characters (including comments). A source ﬁle shall not end in a partial preprocessing token or in a partial comment.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 unspeciﬁed. The process of dividing a source ﬁle’s characters into preprocessing tokens is context-dependent. [ Example: see the handling of < within a #include preprocessing directive. — end example ] 4. Preprocessing directives are executed, macro invocations are expanded, and _Pragma unary operator expressions are executed. If a character sequence that matches the syntax of a universal-character-name
11) Implementations must behave as if these separate phases occur, although in practice diﬀerent phases might be folded together. 12) A partial preprocessing token would arise from a source ﬁle ending in the ﬁrst 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 ﬁle ending with an unclosed /* comment.

§ 2.2

16

c ISO/IEC

N3337

is produced by token concatenation (16.3.3), the behavior is undeﬁned. A #include preprocessing directive causes the named header or source ﬁle to be processed from phase 1 through phase 4, recursively. All preprocessing directives are then deleted. 5. Each source character set member in a character literal or a string literal, as well as each escape sequence and universal-character-name in a character literal or a non-raw string literal, is converted to the corresponding member of the execution character set (2.14.3, 2.14.5); if there is no corresponding member, it is converted to an implementation-deﬁned member other than the null (wide) character.13 6. Adjacent string literal tokens are concatenated. 7. White-space characters separating tokens are no longer signiﬁcant. Each preprocessing token is converted into a token. (2.7). The resulting tokens are syntactically and semantically analyzed and translated as a translation unit. [ Note: The process of analyzing and translating the tokens may occasionally result in one token being replaced by a sequence of other tokens (14.2). — end note ] [ Note: Source ﬁles, translation units and translated translation units need not necessarily be stored as ﬁles, 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 explicitly requested (14.7.2). — end note ] The deﬁnitions of the required templates are located. It is implementation-deﬁned whether the source of the translation units containing these deﬁnitions is required to be available. [ Note: An implementation could encode suﬃcient 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 deﬁnitions. — 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 deﬁned 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
1

Character sets

[lex.charset]

The basic source character set consists of 96 characters: the space character, the control characters representing horizontal tab, vertical tab, form feed, and new-line, plus the following 91 graphical characters: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 _ { } [ ] # ( ) < > % : ; . ? * + - / ^ & | ∼ ! = , \ " ’

2

The universal-character-name construct provides a way to name other characters. hex-quad: hexadecimal-digit hexadecimal-digit hexadecimal-digit hexadecimal-digit
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 ﬁle characters to the source character set (described in translation phase 1) is speciﬁed as implementation-deﬁned, an implementation is required to document how the basic source characters are represented in source ﬁles.

§ 2.3

17

c ISO/IEC

N3337

universal-character-name: \u hex-quad \U hex-quad hex-quad

3

The character designated by the universal-character-name \UNNNNNNNN is that character whose character short name in ISO/IEC 10646 is NNNNNNNN; the character designated by the universal-character-name \uNNNN is that character whose character short name in ISO/IEC 10646 is 0000NNNN. If the hexadecimal value for a universal-character-name corresponds to a surrogate code point (in the range 0xD800–0xDFFF, inclusive), the program is ill-formed. Additionally, if the hexadecimal value for a universal-character-name outside the c-char-sequence, s-char-sequence, or r-char-sequence of a character or string literal corresponds to a control character (in either of the ranges 0x00–0x1F or 0x7F–0x9F, both inclusive) or to a character in the basic source character set, the program is ill-formed.15 The basic execution character set and the basic execution wide-character set shall each contain all the members of the basic source character set, plus control characters representing alert, backspace, and carriage return, plus a null character (respectively, null wide character), whose representation has all zero bits. For each basic execution character set, the values of the members shall be non-negative and distinct from one another. In both the source and execution basic character sets, the value of each character after 0 in the above list of decimal digits shall be one greater than the value of the previous. The execution character set and the execution wide-character set are implementation-deﬁned supersets of the basic execution character set and the basic execution wide-character set, respectively. The values of the members of the execution character sets and the sets of additional members are locale-speciﬁc.

2.4
1

Trigraph sequences

[lex.trigraph]

Before any other processing takes place, each occurrence of one of the following sequences of three characters (“trigraph sequences”) is replaced by the single character indicated in Table 1. Table 1 — Trigraph sequences 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]
3

— end example ] No other trigraph sequence exists. Each ? that does not begin one of the trigraphs listed above is not changed.
15) A sequence of characters resembling a universal-character-name in an r-char-sequence (2.14.5) does not form a universalcharacter-name.

§ 2.4

18

c ISO/IEC

N3337

2.5

Preprocessing tokens preprocessing-token: header-name identiﬁer pp-number character-literal user-deﬁned-character-literal string-literal user-deﬁned-string-literal preprocessing-op-or-punc each non-white-space character that cannot be one of the above

[lex.pptoken]

1

2

3

Each preprocessing token that is converted to a token (2.7) shall have the lexical form of a keyword, an identiﬁer, a literal, an operator, or a punctuator. A preprocessing token is the minimal lexical element of the language in translation phases 3 through 6. The categories of preprocessing token are: header names, identiﬁers, preprocessing numbers, character literals (including user-deﬁned character literals), string literals (including user-deﬁned 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 undeﬁned. Preprocessing tokens can be separated by white space; this consists of comments (2.8), or white-space characters (space, horizontal tab, new-line, vertical tab, and form-feed), or both. As described in Clause 16, in certain circumstances during translation phase 4, white space (or the absence thereof) serves as more than preprocessing token separation. White space can appear within a preprocessing token only as part of a header name or between the quotation characters in a character literal or string literal. If the input stream has been parsed into preprocessing tokens up to a given character: — If the next character begins a sequence of characters that could be the preﬁx and initial double quote of a raw string literal, such as R", the next preprocessing token shall be a raw string literal. Between the initial and ﬁnal double quote characters of the raw string, any transformations performed in phases 1 and 2 (trigraphs, universal-character-names, and line splicing) are reverted; this reversion shall apply before any d-char, r-char, or delimiting parenthesis is identiﬁed. The raw string literal is deﬁned as the shortest sequence of characters that matches the raw-string pattern encoding-preﬁxopt R raw-string

— Otherwise, if the next three characters are , the < is treated as a preprocessor token by itself and not as the ﬁrst character of the alternative token " 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 >

[lex.header]

16) These include “digraphs” and additional reserved words. The term “digraph” (token consisting of two characters) is not perfectly descriptive, since one of the alternative preprocessing-tokens is %:%: and of course several primary tokens contain two characters. Nonetheless, those alternative tokens that aren’t lexical keywords are colloquially known as “digraphs”. 17) Thus the “stringized” values (16.3.2) of [ and > ++ compl

## %:%: .* ˆ -= >>= -not

( ; & *=

Each preprocessing-op-or-punc is converted to a single token in translation phase 7 (2.2).

2.14 2.14.1
1

Literals Kinds of literals
21

[lex.literal] [lex.literal.kinds]

There are several kinds of literals. literal: integer-literal character-literal ﬂoating-literal string-literal boolean-literal pointer-literal user-deﬁned-literal

2.14.2

Integer literals integer-literal: decimal-literal integer-suﬃxopt octal-literal integer-suﬃxopt hexadecimal-literal integer-suﬃxopt 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-suﬃx: unsigned-suﬃx long-suﬃxopt unsigned-suﬃx long-long-suﬃxopt long-suﬃx unsigned-suﬃxopt long-long-suﬃx unsigned-suﬃxopt

[lex.icon]

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

§ 2.14.2

23

c ISO/IEC

N3337

1

2

An integer literal is a sequence of digits that has no period or exponent part. An integer literal may have a preﬁx that speciﬁes its base and a suﬃx that speciﬁes its type. The lexically ﬁrst digit of the sequence of digits is the most signiﬁcant. A decimal integer literal (base ten) begins with a digit other than 0 and consists of a sequence of decimal digits. An octal integer literal (base eight) begins with the digit 0 and consists of a sequence of octal digits.22 A hexadecimal integer literal (base sixteen) begins with 0x or 0X and consists of a sequence of hexadecimal digits, which include the decimal digits and the letters a through f and A through F with decimal values ten through ﬁfteen. [ Example: the number twelve can be written 12, 014, or 0XC. — end example ] The type of an integer literal is the ﬁrst of the corresponding list in Table 6 in which its value can be represented. Table 6 — Types of integer constants Suﬃx none Decimal constants int long int long long int Octal or hexadecimal constant int unsigned int long int unsigned long int long long int unsigned long long int unsigned int unsigned long int unsigned long long int long int unsigned long int long long int unsigned long long int unsigned long int unsigned long long int long long int unsigned long long int unsigned long long int

unsigned-suﬃx: one of u U long-suﬃx: one of l L long-long-suﬃx: one of ll LL

u or U

l or L

unsigned int unsigned long int unsigned long long int long int long long int

Both u or U and l or L ll or LL Both u or U and ll or LL
3

unsigned long int unsigned long long int long long int unsigned long long int

If an integer literal cannot be represented by any type in its list and an extended integer type (3.9.1) can represent its value, it may have that extended integer type. If all of the types in the list for the literal are signed, the extended integer type shall be signed. If all of the types in the list for the literal are unsigned, the extended integer type shall be unsigned. If the list contains both signed and unsigned types, the extended integer type may be signed or unsigned. A program is ill-formed if one of its translation units contains an
22) The digits 8 and 9 are not octal digits.

§ 2.14.2

24

c ISO/IEC

N3337

integer literal that cannot be represented by any of the allowed types.

2.14.3

Character literals character-literal: ’ c-char-sequence ’ u’ c-char-sequence ’ U’ c-char-sequence ’ L’ c-char-sequence ’ c-char-sequence: c-char c-char-sequence c-char c-char: any member of the source character set except the single-quote ’, backslash \, or new-line character escape-sequence universal-character-name escape-sequence: simple-escape-sequence octal-escape-sequence hexadecimal-escape-sequence simple-escape-sequence: one of \’ \" \? \\ \a \b \f \n \r \t \v octal-escape-sequence: \ octal-digit \ octal-digit octal-digit \ octal-digit octal-digit octal-digit hexadecimal-escape-sequence: \x hexadecimal-digit hexadecimal-escape-sequence hexadecimal-digit

[lex.ccon]

1

2

A character literal is one or more characters enclosed in single quotes, as in ’x’, optionally preceded by one of the letters u, U, or L, as in u’y’, U’z’, or L’x’, respectively. A character literal that does not begin with u, U, or L is an ordinary character literal, also referred to as a narrow-character literal. An ordinary character literal that contains a single c-char has type char, with value equal to the numerical value of the encoding of the c-char in the execution character set. An ordinary character literal that contains more than one c-char is a multicharacter literal. A multicharacter literal has type int and implementation-deﬁned value. A character literal that begins with the letter u, such as u’y’, is a character literal of type char16_t. The value of a char16_t literal containing a single c-char is equal to its ISO 10646 code point value, provided that the code point is representable with a single 16-bit code unit. (That is, provided it is a basic multi-lingual plane code point.) If the value is not representable within 16 bits, the program is ill-formed. A char16_t literal containing multiple c-chars is ill-formed. A character literal that begins with the letter U, such as U’z’, is a character literal of type char32_t. The value of a char32_t literal containing a single c-char is equal to its ISO 10646 code point value. A char32_t literal containing multiple c-chars is ill-formed. A character literal that begins with the letter L, such as L’x’, is a wide-character literal. A wide-character literal has type wchar_t.23 The value of a wide-character literal containing a single c-char has value equal to the numerical value of the encoding of the c-char in the execution wide-character set, unless the c-char has no representation in the execution wide-character set, in which case the value is implementation-deﬁned. [ Note: The type wchar_t is able to represent all members of the execution wide-character set (see 3.9.1). — end note ]. The value of a wide-character literal containing multiple c-chars is implementation-deﬁned.
23) They are intended for character sets where a character does not ﬁt into a single byte.

§ 2.14.3

25

c ISO/IEC

N3337

3

Certain nongraphic characters, the single quote ’, the double quote ", the question mark ?,24 and the backslash \, can be represented according to Table 7. The double quote " and the question mark ?, can be represented as themselves or by the escape sequences \" and \? respectively, but the single quote ’ and the backslash \ shall be represented by the escape sequences \’ and \\ respectively. Escape sequences in which the character following the backslash is not listed in Table 7 are conditionally-supported, with implementation-deﬁned semantics. An escape sequence speciﬁes a single character. Table 7 — Escape sequences new-line horizontal tab vertical tab backspace carriage return form feed alert backslash question mark single quote double quote octal number hex number NL(LF) HT VT BS CR FF BEL \ ? ’ " ooo hhh \n \t \v \b \r \f \a \\ \? \’ \" \ooo \xhhh

4

5

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 ﬁrst character that is not an octal digit or a hexadecimal digit, respectively. The value of a character literal is implementation-deﬁned if it falls outside of the implementation-deﬁned range deﬁned for char (for literals with no preﬁx), char16_t (for literals preﬁxed by ’u’), char32_t (for literals preﬁxed by ’U’), or wchar_t (for literals preﬁxed by ’L’). 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 implementationdeﬁned 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 ﬂoating-literal: fractional-constant exponent-partopt ﬂoating-suﬃxopt digit-sequence exponent-part ﬂoating-suﬃxopt fractional-constant: digit-sequenceopt . digit-sequence digit-sequence . exponent-part: e signopt digit-sequence E signopt digit-sequence

[lex.fcon]

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

§ 2.14.4

26

c ISO/IEC

N3337

1

A ﬂoating literal consists of an integer part, a decimal point, a fraction part, an e or E, an optionally signed integer exponent, and an optional type suﬃx. The integer and fraction parts both consist of a sequence of decimal (base ten) digits. Either the integer part or the fraction part (not both) can be omitted; either the decimal point or the letter e (or E ) and the exponent (not both) can be omitted. The integer part, the optional decimal point and the optional fraction part form the signiﬁcant part of the ﬂoating literal. The exponent, if present, indicates the power of 10 by which the signiﬁcant part is to be scaled. If the scaled value is in the range of representable values for its type, the result is the scaled value if representable, else the larger or smaller representable value nearest the scaled value, chosen in an implementation-deﬁned manner. The type of a ﬂoating literal is double unless explicitly speciﬁed by a suﬃx. The suﬃxes f and F specify float, the suﬃxes l and L specify long double. If the scaled value is not in the range of representable values for its type, the program is ill-formed.

sign: one of + digit-sequence: digit digit-sequence digit ﬂoating-suﬃx: one of f l F L

2.14.5

String literals string-literal: encoding-preﬁxopt " s-char-sequenceopt " encoding-preﬁxopt R raw-string encoding-preﬁx: u8 u U L s-char-sequence: s-char s-char-sequence s-char s-char: any member of the source character set except the double-quote ", backslash \, or new-line character escape-sequence universal-character-name raw-string: " d-char-sequenceopt ( r-char-sequenceopt ) d-char-sequenceopt " r-char-sequence: r-char r-char-sequence r-char r-char: any member of the source character set, except a right parenthesis ) followed by the initial d-char-sequence (which may be empty) followed by a double quote ". d-char-sequence: d-char d-char-sequence d-char d-char: any member of the basic source character set except: space, the left parenthesis (, the right parenthesis ), the backslash \, and the control characters representing horizontal tab, vertical tab, form feed, and newline.

[lex.string]

§ 2.14.5

27

c ISO/IEC

N3337

1

2

3

4

A string literal is a sequence of characters (as deﬁned in 2.14.3) surrounded by double quotes, optionally preﬁxed by 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. A string literal that has an R in the preﬁx 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-charsequence. A d-char-sequence shall consist of at most 16 characters. [ Note: The characters ’(’ and ’)’ are permitted in a raw-string. Thus, R"delimiter((a|b))delimiter" is equivalent to "(a|b)". — end note ] [ Note: A source-ﬁle new-line in a raw string literal results in a new-line in the resulting execution stringliteral. 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);

5

— end note ] [ Example: The raw string
R"a( )\ a" )a"

is equivalent to "\n)\\\na\"\n". The raw string
R"(??)"

is equivalent to "\?\?". The raw string
R"#( )??=" )#"
6

7

8

9

10

11

12

13

is equivalent to "\n)\?\?=\"\n". — end example ] After translation phase 6, a string literal that does not begin with an encoding-preﬁx is an ordinary string literal, and is initialized with the given characters. 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. 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 deﬁned below, and has static storage duration (3.7). 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 deﬁned 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. 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 deﬁned below; it has static storage duration and is initialized with the given characters. 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 deﬁned below; it has static storage duration and is initialized with the given characters. Whether all string literals are distinct (that is, are stored in nonoverlapping objects) is implementationdeﬁned. The eﬀect of attempting to modify a string literal is undeﬁned. In translation phase 6 (2.2), adjacent string literals are concatenated. If both string literals have the same encoding-preﬁx, the resulting concatenated string literal has that encoding-preﬁx. If one string literal has § 2.14.5 28

c ISO/IEC

N3337

no encoding-preﬁx, it is treated as a string literal of the same encoding-preﬁx 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-deﬁned behavior. [ Note: This concatenation 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 literal’s initial rawness has no eﬀect on the interpretation or well-formedness of the concatenation. — end note ] Table 8 has some examples of valid concatenations. Table 8 — String literal concatenations Source u"a" u"b" u"a" "b" "a" u"b" Means u"ab" u"ab" u"ab" Source U"a" U"b" U"a" "b" "a" U"b" Means U"ab" U"ab" U"ab" Source L"a" L"b" L"a" "b" "a" L"b" Means L"ab" L"ab" L"ab"

Characters in concatenated strings are kept distinct. [ Example:
"\xA" "B"

14

15

contains the two characters ’\xA’ and ’B’ after concatenation (and not the single hexadecimal character ’\xAB’). — end example ] After any necessary concatenation, in translation phase 7 (2.2), ’\0’ is appended to every string literal so that programs that scan a string can ﬁnd its end. Escape sequences and universal-character-names in non-raw string literals have the same meaning as in character literals (2.14.3), except that the single quote ’ 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-charactername 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 universalcharacter-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 boolean-literal: false true

[lex.bool]

1

The Boolean literals are the keywords false and true. Such literals are prvalues and have type bool.

2.14.7

Pointer literals pointer-literal: nullptr

[lex.nullptr]

1

The pointer literal is the keyword nullptr. It is a prvalue of type std::nullptr_t. [ Note: std::nullptr_t is a distinct type that is neither a pointer type nor a pointer to member type; rather, a prvalue of this type is

§ 2.14.7

29

c ISO/IEC

N3337

a null pointer constant and can be converted to a null pointer value or null member pointer value. See 4.10 and 4.11. — end note ]

2.14.8

User-deﬁned literals user-deﬁned-literal: user-deﬁned-integer-literal user-deﬁned-ﬂoating-literal user-deﬁned-string-literal user-deﬁned-character-literal user-deﬁned-integer-literal: decimal-literal ud-suﬃx octal-literal ud-suﬃx hexadecimal-literal ud-suﬃx user-deﬁned-ﬂoating-literal: fractional-constant exponent-partopt ud-suﬃx digit-sequence exponent-part ud-suﬃx user-deﬁned-string-literal: string-literal ud-suﬃx user-deﬁned-character-literal: character-literal ud-suﬃx ud-suﬃx: identiﬁer

[lex.ext]

1

2

3

If a token matches both user-deﬁned-literal and another literal kind, it is treated as the latter. [ Example: 123_km is a user-deﬁned-literal, but 12LL is an integer-literal. — end example ] The syntactic non-terminal preceding the ud-suﬃx in a user-deﬁned-literal is taken to be the longest sequence of characters that could match that non-terminal. A user-deﬁned-literal is treated as a call to a literal operator or literal operator template (13.5.8). To determine the form of this call for a given user-deﬁned-literal L with ud-suﬃx X , the literal-operator-id whose literal suﬃx identiﬁer is X is looked up in the context of L using the rules for unqualiﬁed name lookup (3.4.1). Let S be the set of declarations found by this lookup. S shall not be empty. If L is a user-deﬁned-integer-literal, let n be the literal without its ud-suﬃx. 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 shall contain a raw literal operator or a literal operator template (13.5.8) but not both. If S contains a raw literal operator, the literal L is treated as a call of the form operator "" X ("n ")

Otherwise (S contains a literal operator template), L is treated as a call of the form operator "" X ()

4

where n is the source character sequence c1 c2 ...ck . [ Note: The sequence c1 c2 ...ck can only contain characters from the basic source character set. — end note ] If L is a user-deﬁned-ﬂoating-literal, let f be the literal without its ud-suﬃx. 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 shall contain a raw literal operator or a literal operator template (13.5.8) but not both. If S contains a raw literal operator, the literal L is treated as a call of the form operator "" X ("f ")

Otherwise (S contains a literal operator template), L is treated as a call of the form § 2.14.8 30

c ISO/IEC

N3337

operator "" X ()

5

where f is the source character sequence c1 c2 ...ck . [ Note: The sequence c1 c2 ...ck can only contain characters from the basic source character set. — end note ] If L is a user-deﬁned-string-literal, let str be the literal without its ud-suﬃx and let len be the number of code units in str (i.e., its length excluding the terminating null character). The literal L is treated as a call of the form operator "" X (str , len )

6

If L is a user-deﬁned-character-literal, let ch be the literal without its ud-suﬃx. S shall contain a literal operator (13.5.8) whose only parameter has the type of ch and the literal L is treated as a call of the form operator "" X (ch )

7

[ Example: long double operator "" _w(long double); std::string operator "" _w(const char16_t*, size_t); unsigned operator "" _w(const char*); int main() { 1.2_w; // calls operator "" _w(1.2L) u"one"_w; // calls operator "" _w(u"one", 3) 12_w; // calls operator "" _w("12") "two"_w; // error: no applicable literal operator }

8

9

— end example ] In translation phase 6 (2.2), adjacent string literals are concatenated and user-deﬁned-string-literals are considered string literals for that purpose. During concatenation, ud-suﬃxes are removed and ignored and the concatenation process occurs as described in 2.14.5. At the end of phase 6, if a string literal is the result of a concatenation involving at least one user-deﬁned-string-literal, all the participating user-deﬁned-stringliterals shall have the same ud-suﬃx and that suﬃx is applied to the result of the concatenation. [ Example: int main() { L"A" "B" "C"_x; // OK: same as L"ABC"_x "P"_x "Q" "R"_y;// error: two diﬀerent ud-suﬃxes }

10

— end example ] Some identiﬁers appearing as ud-suﬃxes are reserved for future standardization (17.6.4.3.5). A program containing such a ud-suﬃx is ill-formed, no diagnostic required.

§ 2.14.8

31

c ISO/IEC

N3337

3
1

Basic concepts

[basic]

2

3

4

5

6

7

8

[ Note: This Clause presents the basic concepts of the C++ language. It explains the diﬀerence between an object and a name and how they relate to the value categories for expressions. It introduces the concepts of a declaration and a deﬁnition and presents C++’s notion of type, scope, linkage, and storage duration. The mechanisms for starting and terminating a program are discussed. Finally, this Clause presents the fundamental types of the language and lists the ways of constructing compound types from these. — end note ] [ Note: This Clause does not cover concepts that aﬀect only a single part of the language. Such concepts are discussed in the relevant Clauses. — end note ] An entity is a value, object, reference, function, enumerator, type, class member, template, template specialization, namespace, parameter pack, or this. A name is a use of an identiﬁer (2.11), operator-function-id (13.5), literal-operator-id (13.5.8), conversionfunction-id (12.3.2), or template-id (14.2) that denotes an entity or label (6.6.4, 6.1). Every name that denotes an entity is introduced by a declaration. Every name that denotes a label is introduced either by a goto statement (6.6.4) or a labeled-statement (6.1). A variable is introduced by the declaration of a reference other than a non-static data member or of an object. The variable’s name denotes the reference or object. Some names denote types or templates. In general, whenever a name is encountered it is necessary to determine whether that name denotes one of these entities before continuing to parse the program that contains it. The process that determines this is called name lookup (3.4). Two names are the same if — they are identiﬁers composed of the same character sequence, or — they are operator-function-ids formed with the same operator, or — they are conversion-function-ids formed with the same type, or — they are template-ids that refer to the same class or function (14.4), or — they are the names of literal operators (13.5.8) formed with the same literal suﬃx identiﬁer.

9

A name used in more than one translation unit can potentially refer to the same entity in these translation units depending on the linkage (3.5) of the name speciﬁed in each translation unit.

3.1
1

Declarations and deﬁnitions

[basic.def]

A declaration (Clause 7) may introduce one or more names into a translation unit or redeclare names introduced by previous declarations. If so, the declaration speciﬁes the interpretation and attributes of these names. A declaration may also have eﬀects including: — a static assertion (Clause 7), — controlling template instantiation (14.7.2), — use of attributes (Clause 7), and — nothing (in the case of an empty-declaration).

§ 3.1

32

c ISO/IEC

N3337

2

A declaration is a deﬁnition unless it declares a function without specifying the function’s body (8.4), it contains the extern speciﬁer (7.1.1) or a linkage-speciﬁcation 25 (7.5) and neither an initializer nor a functionbody, it declares a static data member in a class deﬁnition (9.2, 9.4), it is a class name declaration (9.1), it is an opaque-enum-declaration (7.2), it is a template-parameter (14.1), it is a parameter-declaration (8.3.5) in a function declarator that is not the declarator of a function-deﬁnition, or it is a typedef declaration (7.1.3), an alias-declaration (7.1.3), a using-declaration (7.3.3), a static_assert-declaration (Clause 7), an attributedeclaration (Clause 7), an empty-declaration (Clause 7), or a using-directive (7.3.4). [ Example: all but one of the following are deﬁnitions: int a; extern const int c = 1; int f(int x) { return x+a; } struct S { int a; int b; }; struct X { int x; static int y; X(): x(0) { } }; int X::y = 1; enum { up, down }; namespace N { int d; } namespace N1 = N; X anX; // // // // // // // // // // // // // deﬁnes a deﬁnes c deﬁnes f and deﬁnes x deﬁnes S, S::a, and S::b deﬁnes X deﬁnes non-static data member x declares static data member y deﬁnes a constructor of X deﬁnes deﬁnes deﬁnes deﬁnes deﬁnes X::y up and down N and N::d N1 anX

whereas these are just declarations: extern int a; extern const int c; int f(int); struct S; typedef int Int; extern X anotherX; using N::d;
3

// // // // // // //

declares declares declares declares declares declares declares

a c f S Int anotherX d

— end example ] [ Note: In some circumstances, C++ implementations implicitly deﬁne the default constructor (12.1), copy constructor (12.8), move constructor (12.8), copy assignment operator (12.8), move assignment operator (12.8), or destructor (12.4) member functions. — end note ] [ Example: given
#include struct C { std::string s; }; int C C b } main() { a; b = a; = a;

// std::string is the standard library class (Clause 21)

the implementation will implicitly deﬁne functions to make the deﬁnition of C equivalent to struct C { std::string s;
25) Appearing inside the braced-enclosed declaration-seq in a linkage-speciﬁcation does not aﬀect whether a declaration is a deﬁnition.

§ 3.1

33

c ISO/IEC

N3337

C() : s() { } C(const C& x): s(x.s) { } C(C&& x): s(static_cast(x.s)) { } // : s(std::move(x.s)) { } C& operator=(const C& x) { s = x.s; return *this; } C& operator=(C&& x) { s = static_cast(x.s); return *this; } // { s = std::move(x.s); return *this; } ~C() { } };
4 5

— end example ] [ Note: A class name can also be implicitly declared by an elaborated-type-speciﬁer (7.1.6.3). — end note ] A program is ill-formed if the deﬁnition of any object gives the object an incomplete type (3.9).

3.2
1

One deﬁnition rule

[basic.def.odr]

2

3

4

No translation unit shall contain more than one deﬁnition of any variable, function, class type, enumeration type, or template. An expression is potentially evaluated unless it is an unevaluated operand (Clause 5) or a subexpression thereof. A variable whose name appears as a potentially-evaluated expression is odr-used unless it is an object that satisﬁes the requirements for appearing in a constant expression (5.19) and the lvalue-to-rvalue conversion (4.1) is immediately applied. this is odr-used if it appears as a potentially-evaluated expression (including as the result of the implicit transformation in the body of a non-static member function (9.3.1)). A virtual member function is odr-used if it is not pure. A non-overloaded function whose name appears as a potentially-evaluated expression or a member of a set of candidate functions, if selected by overload resolution when referred to from a potentially-evaluated expression, is odr-used, unless it is a pure virtual function and its name is not explicitly qualiﬁed. [ Note: This covers calls to named functions (5.2.2), operator overloading (Clause 13), user-deﬁned conversions (12.3.2), allocation function for placement new (5.3.4), as well as non-default initialization (8.5). A copy constructor or move constructor is odr-used even if the call is actually elided by the implementation. — end note ] An allocation or deallocation function for a class is odr-used by a new expression appearing in a potentially-evaluated expression as speciﬁed in 5.3.4 and 12.5. A deallocation function for a class is odr-used by a delete expression appearing in a potentially-evaluated expression as speciﬁed in 5.3.5 and 12.5. A non-placement allocation or deallocation function for a class is odr-used by the deﬁnition of a constructor of that class. A non-placement deallocation function for a class is odr-used by the deﬁnition of the destructor of that class, or by being selected by the lookup at the point of deﬁnition of a virtual destructor (12.4).26 A copy-assignment function for a class is odr-used by an implicitlydeﬁned copy-assignment function for another class as speciﬁed in 12.8. A move-assignment function for a class is odr-used by an implicitly-deﬁned move-assignment function for another class as speciﬁed in 12.8. A default constructor for a class is odr-used by default initialization or value initialization as speciﬁed in 8.5. A constructor for a class is odr-used as speciﬁed in 8.5. A destructor for a class is odr-used as speciﬁed in 12.4. Every program shall contain exactly one deﬁnition of every non-inline function or variable that is odr-used in that program; no diagnostic required. The deﬁnition can appear explicitly in the program, it can be found in the standard or a user-deﬁned library, or (when appropriate) it is implicitly deﬁned (see 12.1, 12.4 and 12.8). An inline function shall be deﬁned in every translation unit in which it is odr-used. Exactly one deﬁnition of a class is required in a translation unit if the class is used in a way that requires the class type to be complete. [ Example: the following complete translation unit is well-formed, even though it never deﬁnes X: struct X; struct X* x1; // declare X as a struct type // use X in pointer formation

26) An implementation is not required to call allocation and deallocation functions from constructors or destructors; however, this is a permissible implementation technique.

§ 3.2

34

c ISO/IEC

N3337

X* x2;

// use X in pointer formation

— end example ] [ Note: The rules for declarations and expressions describe in which contexts complete class types are required. A class type T must be complete if: — an object of type T is deﬁned (3.1), or — a non-static class data member of type T is declared (9.2), or — T is used as the object type or array element type in a new-expression (5.3.4), or — an lvalue-to-rvalue conversion is applied to a glvalue referring to an object of type T (4.1), or — an expression is converted (either implicitly or explicitly) to type T (Clause 4, 5.2.3, 5.2.7, 5.2.9, 5.4), or — an expression that is not a null pointer constant, and has type other than void*, is converted to the type pointer to T or reference to T using an implicit conversion (Clause 4), a dynamic_cast (5.2.7) or a static_cast (5.2.9), or — a class member access operator is applied to an expression of type T (5.2.5), or — the typeid operator (5.2.8) or the sizeof operator (5.3.3) is applied to an operand of type T, or — a function with a return type or argument type of type T is deﬁned (3.1) or called (5.2.2), or — a class with a base class of type T is deﬁned (Clause 10), or — an lvalue of type T is assigned to (5.17), or — the type T is the subject of an alignof expression (5.3.6), or — an exception-declaration has type T, reference to T, or pointer to T (15.3). — end note ] There can be more than one deﬁnition of a class type (Clause 9), enumeration type (7.2), inline function with external linkage (7.1.2), class template (Clause 14), non-static function template (14.5.6), static data member of a class template (14.5.1.3), member function of a class template (14.5.1.1), or template specialization for which some template parameters are not speciﬁed (14.7, 14.5.5) in a program provided that each deﬁnition appears in a diﬀerent translation unit, and provided the deﬁnitions satisfy the following requirements. Given such an entity named D deﬁned in more than one translation unit, then — each deﬁnition of D shall consist of the same sequence of tokens; and — in each deﬁnition of D, corresponding names, looked up according to 3.4, shall refer to an entity deﬁned within the deﬁnition of D, or shall refer to the same entity, after overload resolution (13.3) and after matching of partial template specialization (14.8.3), except that a name can refer to a const object with internal or no linkage if the object has the same literal type in all deﬁnitions of D, and the object is initialized with a constant expression (5.19), and the value (but not the address) of the object is used, and the object has the same value in all deﬁnitions of D; and — in each deﬁnition of D, corresponding entities shall have the same language linkage; and — in each deﬁnition of D, the overloaded operators referred to, the implicit calls to conversion functions, constructors, operator new functions and operator delete functions, shall refer to the same function, or to a function deﬁned within the deﬁnition of D; and

5

§ 3.2

35

c ISO/IEC

N3337

— in each deﬁnition of D, a default argument used by an (implicit or explicit) function call is treated as if its token sequence were present in the deﬁnition of D; that is, the default argument is subject to the three requirements described above (and, if the default argument has sub-expressions with default arguments, this requirement applies recursively).27 — if D is a class with an implicitly-declared constructor (12.1), it is as if the constructor was implicitly deﬁned in every translation unit where it is odr-used, and the implicit deﬁnition in every translation unit shall call the same constructor for a base class or a class member of D. [ Example:
//translation unit 1: struct X { X(int); X(int, int); }; X::X(int = 0) { } class D: public X { }; D d2; //translation unit 2: struct X { X(int); X(int, int); }; X::X(int = 0, int = 0) { } class D: public X { };

// X(int) called by D()

// X(int, int) called by D(); // D()’s implicit deﬁnition // violates the ODR

— end example ] If D is a template and is deﬁned in more than one translation unit, then the preceding requirements shall apply both to names from the template’s enclosing scope used in the template deﬁnition (14.6.3), and also to dependent names at the point of instantiation (14.6.2). If the deﬁnitions of D satisfy all these requirements, then the program shall behave as if there were a single deﬁnition of D. If the deﬁnitions of D do not satisfy these requirements, then the behavior is undeﬁned.

3.3 3.3.1
1

Scope Declarative regions and scopes

[basic.scope] [basic.scope.declarative]

2

Every name is introduced in some portion of program text called a declarative region, which is the largest part of the program in which that name is valid, that is, in which that name may be used as an unqualiﬁed name to refer to the same entity. In general, each particular name is valid only within some possibly discontiguous portion of program text called its scope. To determine the scope of a declaration, it is sometimes convenient to refer to the potential scope of a declaration. The scope of a declaration is the same as its potential scope unless the potential scope contains another declaration of the same name. In that case, the potential scope of the declaration in the inner (contained) declarative region is excluded from the scope of the declaration in the outer (containing) declarative region. [ Example: in int j = 24; int main() { int i = j, j; j = 42; }
27) 8.3.6 describes how default argument names are looked up.

§ 3.3.1

36

c ISO/IEC

N3337

3

4

the identiﬁer j is declared twice as a name (and used twice). The declarative region of the ﬁrst j includes the entire example. The potential scope of the ﬁrst j begins immediately after that j and extends to the end of the program, but its (actual) scope excludes the text between the , and the }. The declarative region of the second declaration of j (the j immediately before the semicolon) includes all the text between { and }, but its potential scope excludes the declaration of i. The scope of the second declaration of j is the same as its potential scope. — end example ] The names declared by a declaration are introduced into the scope in which the declaration occurs, except that the presence of a friend speciﬁer (11.3), certain uses of the elaborated-type-speciﬁer (7.1.6.3), and using-directives (7.3.4) alter this general behavior. Given a set of declarations in a single declarative region, each of which speciﬁes the same unqualiﬁed name, — they shall all refer to the same entity, or all refer to functions and function templates; or — exactly one declaration shall declare a class name or enumeration name that is not a typedef name and the other declarations shall all refer to the same variable or enumerator, or all refer to functions and function templates; in this case the class name or enumeration name is hidden (3.3.10). [ Note: A namespace name or a class template name must be unique in its declarative region (7.3.2, Clause 14). — end note ] [ Note: These restrictions apply to the declarative region into which a name is introduced, which is not necessarily the same as the region in which the declaration occurs. In particular, elaborated-type-speciﬁers (7.1.6.3) and friend declarations (11.3) may introduce a (possibly not visible) name into an enclosing namespace; these restrictions apply to that region. Local extern declarations (3.5) may introduce a name into the declarative region where the declaration appears and also introduce a (possibly not visible) name into an enclosing namespace; these restrictions apply to both regions. — end note ] [ Note: The name lookup rules are summarized in 3.4. — end note ]

5

3.3.2
1

Point of declaration

[basic.scope.pdecl]

The point of declaration for a name is immediately after its complete declarator (Clause 8) and before its initializer (if any), except as noted below. [ Example: int x = 12; { int x = x; }

2

Here the second x is initialized with its own (indeterminate) value. — end example ] [ Note: a name from an outer scope remains visible up to the point of declaration of the name that hides it.[ Example: const int i = 2; { int i[i]; }

3

4

declares a block-scope array of two integers. — end example ] — end note ] The point of declaration for a class or class template ﬁrst declared by a class-speciﬁer is immediately after the identiﬁer or simple-template-id (if any) in its class-head (Clause 9). The point of declaration for an enumeration is immediately after the identiﬁer (if any) in either its enum-speciﬁer (7.2) or its ﬁrst opaque-enum-declaration (7.2), whichever comes ﬁrst. The point of declaration of an alias or alias template immediately follows the type-id to which the alias refers. The point of declaration for an enumerator is immediately after its enumerator-deﬁnition.[ Example: const int x = 12; { enum { x = x }; }

5

Here, the enumerator x is initialized with the value of the constant x, namely 12. — end example ] After the point of declaration of a class member, the member name can be looked up in the scope of its class. [ Note: this is true even if the class is an incomplete class. For example,

§ 3.3.2

37

c ISO/IEC

N3337

struct X { enum E { z = 16 }; int b[X::z]; // OK };
6

— end note ] The point of declaration of a class ﬁrst declared in an elaborated-type-speciﬁer is as follows: — for a declaration of the form class-key attribute-speciﬁer-seqopt identiﬁer ;

the identiﬁer is declared to be a class-name in the scope that contains the declaration, otherwise — for an elaborated-type-speciﬁer of the form class-key identiﬁer

if the elaborated-type-speciﬁer is used in the decl-speciﬁer-seq or parameter-declaration-clause of a function deﬁned in namespace scope, the identiﬁer is declared as a class-name in the namespace that contains the declaration; otherwise, except as a friend declaration, the identiﬁer is declared in the smallest namespace or block scope that contains the declaration. [ Note: These rules also apply within templates. — end note ] [ Note: Other forms of elaborated-type-speciﬁer do not declare a new name, and therefore must refer to an existing type-name. See 3.4.4 and 7.1.6.3. — end note ]
7

8

9

The point of declaration for an injected-class-name (Clause 9) is immediately following the opening brace of the class deﬁnition. The point of declaration for a function-local predeﬁned variable (8.4) is immediately before the function-body of a function deﬁnition. The point of declaration for a template parameter is immediately after its complete template-parameter. [ Example: typedef unsigned char T; template struct A { };

10

11

— end example ] [ Note: Friend declarations refer to functions or classes that are members of the nearest enclosing namespace, but they do not introduce new names into that namespace (7.3.1.2). Function declarations at block scope and variable declarations with the extern speciﬁer at block scope refer to declarations that are members of an enclosing namespace, but they do not introduce new names into that scope. — end note ] [ Note: For point of instantiation of a template, see 14.6.4.1. — end note ]

3.3.3
1

Block scope

[basic.scope.local]

2

3

A name declared in a block (6.3) is local to that block; it has block scope. Its potential scope begins at its point of declaration (3.3.2) and ends at the end of its block. A variable declared at block scope is a local variable. The potential scope of a function parameter name (including one appearing in a lambda-declarator) or of a function-local predeﬁned variable in a function deﬁnition (8.4) begins at its point of declaration. If the function has a function-try-block the potential scope of a parameter or of a function-local predeﬁned variable ends at the end of the last associated handler, otherwise it ends at the end of the outermost block of the function deﬁnition. A parameter name shall not be redeclared in the outermost block of the function deﬁnition nor in the outermost block of any handler associated with a function-try-block. The name declared in an exception-declaration is local to the handler and shall not be redeclared in the outermost block of the handler. § 3.3.3 38

c ISO/IEC

N3337

4

Names declared in the for-init-statement, the for-range-declaration, and in the condition of if, while, for, and switch statements are local to the if, while, for, or switch statement (including the controlled statement), and shall not be redeclared in a subsequent condition of that statement nor in the outermost block (or, for the if statement, any of the outermost blocks) of the controlled statement; see 6.4.

3.3.4
1

Function prototype scope

[basic.scope.proto]

In a function declaration, or in any function declarator except the declarator of a function deﬁnition (8.4), names of parameters (if supplied) have function prototype scope, which terminates at the end of the nearest enclosing function declarator.

3.3.5
1

Function scope

[basic.funscope]

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

3.3.6
1

Namespace scope

[basic.scope.namespace]

The declarative region of a namespace-deﬁnition is its namespace-body. The potential scope denoted by an original-namespace-name is the concatenation of the declarative regions established by each of the namespace-deﬁnitions in the same declarative region with that original-namespace-name. Entities declared in a namespace-body are said to be members of the namespace, and names introduced by these declarations into the declarative region of the namespace are said to be member names of the namespace. A namespace member name has namespace scope. Its potential scope includes its namespace from the name’s point of declaration (3.3.2) onwards; and for each using-directive (7.3.4) that nominates the member’s namespace, the member’s potential scope includes that portion of the potential scope of the using-directive that follows the member’s point of declaration. [ Example: namespace N { int i; int g(int a) { return a; } int j(); void q(); } namespace { int l=1; } // the potential scope of l is from its point of declaration // to the end of the translation unit namespace N { int g(char a) { return l+a; } int i; int j(); int j() { return g(i); } int q(); }

// overloads N::g(int) // l is from unnamed namespace

// error: duplicate deﬁnition // OK: duplicate function declaration // OK: deﬁnition of N::j() // calls N::g(int) // error: diﬀerent return type

2

3

— end example ] A namespace member can also be referred to after the :: scope resolution operator (5.1) applied to the name of its namespace or the name of a namespace which nominates the member’s namespace in a using-directive; see 3.4.3.2. The outermost declarative region of a translation unit is also a namespace, called the global namespace. A name declared in the global namespace has global namespace scope (also called global scope). The potential § 3.3.6 39

c ISO/IEC

N3337

scope of such a name begins at its point of declaration (3.3.2) and ends at the end of the translation unit that is its declarative region. Names with global namespace scope are said to be global name.

3.3.7
1

Class scope

[basic.scope.class]

The following rules describe the scope of names declared in classes. 1) The potential scope of a name declared in a class consists not only of the declarative region following the name’s point of declaration, but also of all function bodies, brace-or-equal-initializers of non-static data members, and default arguments in that class (including such things in nested classes). 2) A name N used in a class S shall refer to the same declaration in its context and when re-evaluated in the completed scope of S. No diagnostic is required for a violation of this rule. 3) If reordering member declarations in a class yields an alternate valid program under (1) and (2), the program is ill-formed, no diagnostic is required. 4) A name declared within a member function hides a declaration of the same name whose scope extends to or past the end of the member function’s class. 5) The potential scope of a declaration that extends to or past the end of a class deﬁnition also extends to the regions deﬁned by its member deﬁnitions, even if the members are deﬁned lexically outside the class (this includes static data member deﬁnitions, nested class deﬁnitions, member function deﬁnitions (including the member function body and any portion of the declarator part of such deﬁnitions which follows the declarator-id, including a parameter-declaration-clause and any default arguments (8.3.6).[ Example: typedef int c; enum { i = 1 }; class X { char v[i]; int f() { return sizeof(c); } char c; enum { i = 2 }; }; typedef char* struct Y { T a; typedef long T b; }; typedef int I; class D { typedef I I; }; T; // error: T refers to ::T // but when reevaluated is Y::T T;

// error: i refers to ::i // but when reevaluated is X::i // OK: X::c

// error, even though no reordering involved

— end example ]
2

The name of a class member shall only be used as follows: — in the scope of its class (as described above) or a class derived (Clause 10) from its class, — after the . operator applied to an expression of the type of its class (5.2.5) or a class derived from its class, § 3.3.7 40

c ISO/IEC

N3337

— after the -> operator applied to a pointer to an object of its class (5.2.5) or a class derived from its class, — after the :: scope resolution operator (5.1) applied to the name of its class or a class derived from its class.

3.3.8
1

Enumeration scope

[basic.scope.enum]

The name of a scoped enumerator (7.2) has enumeration scope. Its potential scope begins at its point of declaration and terminates at the end of the enum-speciﬁer.

3.3.9
1

Template parameter scope

[basic.scope.temp]

2

The declarative region of the name of a template parameter of a template template-parameter is the smallest template-parameter-list in which the name was introduced. The declarative region of the name of a template parameter of a template is the smallest template-declaration in which the name was introduced. Only template parameter names belong to this declarative region; any other kind of name introduced by the declaration of a template-declaration is instead introduced into the same declarative region where it would be introduced as a result of a non-template declaration of the same name. [ Example: namespace N { template struct A { }; template void f(U) { } struct B { template friend int g(struct C*); }; } // #1 // #2 // #3

3

The declarative regions of T, U and V are the template-declarations on lines #1, #2 and #3, respectively. But the names A, f, g and C all belong to the same declarative region — namely, the namespace-body of N. (g is still considered to belong to this declarative region in spite of its being hidden during qualiﬁed and unqualiﬁed name lookup.) — end example ] The potential scope of a template parameter name begins at its point of declaration (3.3.2) and ends at the end of its declarative region. [ Note: This implies that a template-parameter can be used in the declaration of subsequent template-parameters and their default arguments but cannot be used in preceding templateparameters or their default arguments. For example, template class X { /∗ ... ∗/ }; template void f(T* p = new T);

This also implies that a template-parameter can be used in the speciﬁcation of base classes. For example, template class X : public Array { /∗ ... ∗/ }; template class Y : public T { /∗ ... ∗/ };

4

The use of a template parameter as a base class implies that a class used as a template argument must be deﬁned and not just declared when the class template is instantiated. — end note ] The declarative region of the name of a template parameter is nested within the immediately-enclosing declarative region. [ Note: As a result, a template-parameter hides any entity with the same name in an enclosing scope (3.3.10). [ Example: typedef int N; template struct A;

Here, X is a non-type template parameter of type int and Y is a non-type template parameter of the same type as the second template parameter of A. — end example ] — end note ]

§ 3.3.9

41

c ISO/IEC

N3337

5

[ Note: Because the name of a template parameter cannot be redeclared within its potential scope (14.6.1), a template parameter’s scope is often its potential scope. However, it is still possible for a template parameter name to be hidden; see 14.6.1. — end note ]

3.3.10
1

Name hiding

[basic.scope.hiding]

2

3

4

5

A name can be hidden by an explicit declaration of that same name in a nested declarative region or derived class (10.2). A class name (9.1) or enumeration name (7.2) can be hidden by the name of a variable, data member, function, or enumerator declared in the same scope. If a class or enumeration name and a variable, data member, function, or enumerator are declared in the same scope (in any order) with the same name, the class or enumeration name is hidden wherever the variable, data member, function, or enumerator name is visible. In a member function deﬁnition, the declaration of a name at block scope hides the declaration of a member of the class with the same name; see 3.3.7. The declaration of a member in a derived class (Clause 10) hides the declaration of a member of a base class of the same name; see 10.2. During the lookup of a name qualiﬁed by a namespace name, declarations that would otherwise be made visible by a using-directive can be hidden by declarations with the same name in the namespace containing the using-directive; see (3.4.3.2). If a name is in scope and is not hidden it is said to be visible.

3.4
1

Name lookup

[basic.lookup]

2

3

4

The name lookup rules apply uniformly to all names (including typedef-names (7.1.3), namespace-names (7.3), and class-names (9.1)) wherever the grammar allows such names in the context discussed by a particular rule. Name lookup associates the use of a name with a declaration (3.1) of that name. Name lookup shall ﬁnd an unambiguous declaration for the name (see 10.2). Name lookup may associate more than one declaration with a name if it ﬁnds the name to be a function name; the declarations are said to form a set of overloaded functions (13.1). Overload resolution (13.3) takes place after name lookup has succeeded. The access rules (Clause 11) are considered only once name lookup and function overload resolution (if applicable) have succeeded. Only after name lookup, function overload resolution (if applicable) and access checking have succeeded are the attributes introduced by the name’s declaration used further in expression processing (Clause 5). A name “looked up in the context of an expression” is looked up as an unqualiﬁed name in the scope where the expression is found. The injected-class-name of a class (Clause 9) is also considered to be a member of that class for the purposes of name hiding and lookup. [ Note: 3.5 discusses linkage issues. The notions of scope, point of declaration and name hiding are discussed in 3.3. — end note ]

3.4.1
1

Unqualiﬁed name lookup

[basic.lookup.unqual]

2

3

In all the cases listed in 3.4.1, the scopes are searched for a declaration in the order listed in each of the respective categories; name lookup ends as soon as a declaration is found for the name. If no declaration is found, the program is ill-formed. The declarations from the namespace nominated by a using-directive become visible in a namespace enclosing the using-directive; see 7.3.4. For the purpose of the unqualiﬁed name lookup rules described in 3.4.1, the declarations from the namespace nominated by the using-directive are considered members of that enclosing namespace. The lookup for an unqualiﬁed name used as the postﬁx-expression of a function call is described in 3.4.2. [ Note: For purposes of determining (during parsing) whether an expression is a postﬁx-expression for a function call, the usual name lookup rules apply. The rules in 3.4.2 have no eﬀect on the syntactic interpretation of an expression. For example, typedef int f; namespace N {

§ 3.4.1

42

c ISO/IEC

N3337

struct A { friend void f(A &); operator int(); void g(A a) { int i = f(a); } }; }

// f is the typedef, not the friend // function: equivalent to int(a)

4

5

6

Because the expression is not a function call, the argument-dependent name lookup (3.4.2) does not apply and the friend function f is not found. — end note ] A name used in global scope, outside of any function, class or user-declared namespace, shall be declared before its use in global scope. A name used in a user-declared namespace outside of the deﬁnition of any function or class shall be declared before its use in that namespace or before its use in a namespace enclosing its namespace. A name used in the deﬁnition of a function following the function’s declarator-id 28 that is a member of namespace N (where, only for the purpose of exposition, N could represent the global scope) shall be declared before its use in the block in which it is used or in one of its enclosing blocks (6.3) or, shall be declared before its use in namespace N or, if N is a nested namespace, shall be declared before its use in one of N’s enclosing namespaces. [ Example: namespace A { namespace N { void f(); } } void A::N::f() { i = 5; // The following scopes are searched for a declaration of i: // 1) outermost block scope of A::N::f, before the use of i // 2) scope of namespace N // 3) scope of namespace A // 4) global scope, before the deﬁnition of A::N::f }

7

— end example ] A name used in the deﬁnition of a class X outside of a member function body or nested class deﬁnition29 shall be declared in one of the following ways: — before its use in class X or be a member of a base class of X (10.2), or — if X is a nested class of class Y (9.7), before the deﬁnition of X in Y, or shall be a member of a base class of Y (this lookup applies in turn to Y ’s enclosing classes, starting with the innermost enclosing class),30 or — if X is a local class (9.8) or is a nested class of a local class, before the deﬁnition of class X in a block enclosing the deﬁnition of class X, or
28) This refers to unqualiﬁed names that occur, for instance, in a type or default argument in the parameter-declaration-clause or used in the function body. 29) This refers to unqualiﬁed names following the class name; such a name may be used in the base-clause or may be used in the class deﬁnition. 30) This lookup applies whether the deﬁnition of X is nested within Y’s deﬁnition or whether X’s deﬁnition appears in a namespace scope enclosing Y ’s deﬁnition (9.7).

§ 3.4.1

43

c ISO/IEC

N3337

— if X is a member of namespace N, or is a nested class of a class that is a member of N, or is a local class or a nested class within a local class of a function that is a member of N, before the deﬁnition of class X in namespace N or in one of N ’s enclosing namespaces. [ Example: namespace M { class B { }; } namespace class Y class int }; }; } // // // // // // N { : public M::B { X { a[i];

The following scopes are searched for a declaration of i: 1) scope of class N::Y::X, before the use of i 2) scope of class N::Y, before the deﬁnition of N::Y::X 3) scope of N::Y’s base class M::B 4) scope of namespace N, before the deﬁnition of N::Y 5) global scope, before the deﬁnition of N

8

— end example ] [ Note: When looking for a prior declaration of a class or function introduced by a friend declaration, scopes outside of the innermost enclosing namespace scope are not considered; see 7.3.1.2. — end note ] [ Note: 3.3.7 further describes the restrictions on the use of names in a class deﬁnition. 9.7 further describes the restrictions on the use of names in nested class deﬁnitions. 9.8 further describes the restrictions on the use of names in local class deﬁnitions. — end note ] A name used in the deﬁnition of a member function (9.3) of class X following the function’s declarator-id 31 or in the brace-or-equal-initializer of a non-static data member (9.2) of class X shall be declared in one of the following ways: — before its use in the block in which it is used or in an enclosing block (6.3), or — shall be a member of class X or be a member of a base class of X (10.2), or — if X is a nested class of class Y (9.7), shall be a member of Y, or shall be a member of a base class of Y (this lookup applies in turn to Y’s enclosing classes, starting with the innermost enclosing class),32 or — if X is a local class (9.8) or is a nested class of a local class, before the deﬁnition of class X in a block enclosing the deﬁnition of class X, or — if X is a member of namespace N, or is a nested class of a class that is a member of N, or is a local class or a nested class within a local class of a function that is a member of N, before the use of the name, in namespace N or in one of N ’s enclosing namespaces. [ Example:
31) That is, an unqualiﬁed name that occurs, for instance, in a type or default argument in the parameter-declaration-clause or in the function body. 32) This lookup applies whether the member function is deﬁned within the deﬁnition of class X or whether the member function is deﬁned in a namespace scope enclosing X’s deﬁnition.

§ 3.4.1

44

c ISO/IEC

N3337

class B { }; namespace M { namespace N { class X : public B { void f(); }; } } void M::N::X::f() { i = 16; } // // // // // // // The following scopes are searched for a declaration of i: 1) outermost block scope of M::N::X::f, before the use of i 2) scope of class M::N::X 3) scope of M::N::X’s base class B 4) scope of namespace M::N 5) scope of namespace M 6) global scope, before the deﬁnition of M::N::X::f

9

10

— end example ] [ Note: 9.3 and 9.4 further describe the restrictions on the use of names in member function deﬁnitions. 9.7 further describes the restrictions on the use of names in the scope of nested classes. 9.8 further describes the restrictions on the use of names in local class deﬁnitions. — end note ] Name lookup for a name used in the deﬁnition of a friend function (11.3) deﬁned inline in the class granting friendship shall proceed as described for lookup in member function deﬁnitions. If the friend function is not deﬁned in the class granting friendship, name lookup in the friend function deﬁnition shall proceed as described for lookup in namespace member function deﬁnitions. In a friend declaration naming a member function, a name used in the function declarator and not part of a template-argument in the declarator-id is ﬁrst looked up in the scope of the member function’s class (10.2). If it is not found, or if the name is part of a template-argument in the declarator-id, the look up is as described for unqualiﬁed names in the deﬁnition of the class granting friendship. [ Example: struct A { typedef int AT; void f1(AT); void f2(float); template void f3(); }; struct B { typedef char AT; typedef float BT; friend void A::f1(AT); // parameter type is A::AT friend void A::f2(BT); // parameter type is B::BT friend void A::f3(); // template argument is B::AT };

11

12

— end example ] During the lookup for a name used as a default argument (8.3.6) in a function parameter-declaration-clause or used in the expression of a mem-initializer for a constructor (12.6.2), the function parameter names are visible and hide the names of entities declared in the block, class or namespace scopes containing the function declaration. [ Note: 8.3.6 further describes the restrictions on the use of names in default arguments. 12.6.2 further describes the restrictions on the use of names in a ctor-initializer. — end note ] During the lookup of a name used in the constant-expression of an enumerator-deﬁnition, previously declared enumerators of the enumeration are visible and hide the names of entities declared in the block, class, or namespace scopes containing the enum-speciﬁer. § 3.4.1 45

c ISO/IEC

N3337

13

14

A name used in the deﬁnition of a static data member of class X (9.4.2) (after the qualiﬁed-id of the static member) is looked up as if the name was used in a member function of X. [ Note: 9.4.2 further describes the restrictions on the use of names in the deﬁnition of a static data member. — end note ] If a variable member of a namespace is deﬁned outside of the scope of its namespace then any name that appears in the deﬁnition of the member (after the declarator-id) is looked up as if the deﬁnition of the member occurred in its namespace. [ Example: namespace N { int i = 4; extern int j; } int i = 2; int N::j = i; // N::j == 4

15

16

— end example ] A name used in the handler for a function-try-block (Clause 15) is looked up as if the name was used in the outermost block of the function deﬁnition. In particular, the function parameter names shall not be redeclared in the exception-declaration nor in the outermost block of a handler for the function-try-block. Names declared in the outermost block of the function deﬁnition are not found when looked up in the scope of a handler for the function-try-block. [ Note: But function parameter names are found. — end note ] [ Note: The rules for name lookup in template deﬁnitions are described in 14.6. — end note ]

3.4.2
1

Argument-dependent name lookup

[basic.lookup.argdep]

When the postﬁx-expression in a function call (5.2.2) is an unqualiﬁed-id, other namespaces not considered during the usual unqualiﬁed lookup (3.4.1) may be searched, and in those namespaces, namespace-scope friend function declarations (11.3) not otherwise visible may be found. These modiﬁcations to the search depend on the types of the arguments (and for template template arguments, the namespace of the template argument). [ Example: namespace N { struct S { }; void f(S); } void g() { N::S s; f(s); (f)(s); }

// OK: calls N::f // error: N::f not considered; parentheses // prevent argument-dependent lookup

2

— end example ] For each argument type T in the function call, there is a set of zero or more associated namespaces and a set of zero or more associated classes to be considered. The sets of namespaces and classes is determined entirely by the types of the function arguments (and the namespace of any template template argument). Typedef names and using-declarations used to specify the types do not contribute to this set. The sets of namespaces and classes are determined in the following way: — If T is a fundamental type, its associated sets of namespaces and classes are both empty. — If T is a class type (including unions), its associated classes are: the class itself; the class of which it is a member, if any; and its direct and indirect base classes. Its associated namespaces are the namespaces of which its associated classes are members. Furthermore, if T is a class template specialization, its associated namespaces and classes also include: the namespaces and classes associated with the § 3.4.2 46

c ISO/IEC

N3337

types of the template arguments provided for template type parameters (excluding template template parameters); the namespaces of which any template template arguments are members; and the classes of which any member templates used as template template arguments are members. [ Note: Non-type template arguments do not contribute to the set of associated namespaces. — end note ] — If T is an enumeration type, its associated namespace is the namespace in which it is deﬁned. If it is class member, its associated class is the member’s class; else it has no associated class. — If T is a pointer to U or an array of U, its associated namespaces and classes are those associated with U. — If T is a function type, its associated namespaces and classes are those associated with the function parameter types and those associated with the return type. — If T is a pointer to a member function of a class X, its associated namespaces and classes are those associated with the function parameter types and return type, together with those associated with X. — If T is a pointer to a data member of class X, its associated namespaces and classes are those associated with the member type together with those associated with X. If an associated namespace is an inline namespace (7.3.1), its enclosing namespace is also included in the set. If an associated namespace directly contains inline namespaces, those inline namespaces are also included in the set. In addition, if the argument is the name or address of a set of overloaded functions and/or function templates, its associated classes and namespaces are the union of those associated with each of the members of the set, i.e., the classes and namespaces associated with its parameter types and return type. Additionally, if the aforementioned set of overloaded functions is named with a template-id, its associated classes and namespaces also include those of its type template-arguments and its template template-arguments. Let X be the lookup set produced by unqualiﬁed lookup (3.4.1) and let Y be the lookup set produced by argument dependent lookup (deﬁned as follows). If X contains — a declaration of a class member, or — a block-scope function declaration that is not a using-declaration, or — a declaration that is neither a function or a function template then Y is empty. Otherwise Y is the set of declarations found in the namespaces associated with the argument types as described below. The set of declarations found by the lookup of the name is the union of X and Y . [ Note: The namespaces and classes associated with the argument types can include namespaces and classes already considered by the ordinary unqualiﬁed lookup. — end note ] [ Example: namespace NS { class T { }; void f(T); void g(T, int); } NS::T parm; void g(NS::T, float); int main() { f(parm); extern void g(NS::T, float); g(parm, 1); }

3

// OK: calls NS::f // OK: calls g(NS::T, float)

§ 3.4.2

47

c ISO/IEC

N3337

4

— end example ] When considering an associated namespace, the lookup is the same as the lookup performed when the associated namespace is used as a qualiﬁer (3.4.3.2) except that: — Any using-directives in the associated namespace are ignored. — Any namespace-scope friend functions or friend function templates declared in associated classes are visible within their respective namespaces even if they are not visible during an ordinary lookup (11.3). — All names except those of (possibly overloaded) functions and function templates are ignored.

3.4.3
1

Qualiﬁed name lookup

[basic.lookup.qual]

The name of a class or namespace member or enumerator can be referred to after the :: scope resolution operator (5.1) applied to a nested-name-speciﬁer that denotes its class, namespace, or enumeration. If a :: scope resolution operator in a nested-name-speciﬁer is not preceded by a decltype-speciﬁer, lookup of the name preceding that :: considers only namespaces, types, and templates whose specializations are types. If the name found does not designate a namespace or a class, enumeration, or dependent type, the program is ill-formed.[ Example: class A { public: static int n; }; int main() { int A; A::n = 42; A b; }

// OK // ill-formed: A does not name a type

2

3

— end example ] [ Note: Multiply qualiﬁed names, such as N1::N2::N3::n, can be used to refer to members of nested classes (9.7) or members of nested namespaces. — end note ] In a declaration in which the declarator-id is a qualiﬁed-id, names used before the qualiﬁed-id being declared are looked up in the deﬁning namespace scope; names following the qualiﬁed-id are looked up in the scope of the member’s class or namespace. [ Example: class X { }; class C { class X { }; static const int number = 50; static X arr[number]; }; X C::arr[number]; // ill-formed: // equivalent to: ::X C::arr[C::number]; // not to: C::X C::arr[C::number];

4

5

6

— end example ] A name preﬁxed by the unary scope operator :: (5.1) is looked up in global scope, in the translation unit where it is used. The name shall be declared in global namespace scope or shall be a name whose declaration is visible in global scope because of a using-directive (3.4.3.2). The use of :: allows a global name to be referred to even if its identiﬁer has been hidden (3.3.10). A name preﬁxed by a nested-name-speciﬁer that nominates an enumeration type shall represent an enumerator of that enumeration. If a pseudo-destructor-name (5.2.4) contains a nested-name-speciﬁer, the type-names are looked up as types in the scope designated by the nested-name-speciﬁer. Similarly, in a qualiﬁed-id of the form: § 3.4.3 48

c ISO/IEC

N3337

nested-name-speciﬁeropt class-name ::

~ class-name

the second class-name is looked up in the same scope as the ﬁrst. [ Example: struct C { typedef int I; }; typedef int I1, I2; extern int* p; extern int* q; p->C::I::~I(); // I is looked up in the scope of C q->I1::~I2(); // I2 is looked up in the scope of // the postﬁx-expression struct A { ~A(); }; typedef A AB; int main() { AB *p; p->AB::~AB(); }

// explicitly calls the destructor for A

— end example ] [ Note: 3.4.5 describes how name lookup proceeds after the . and -> operators. — end note ] 3.4.3.1 Class members [class.qual]
1

If the nested-name-speciﬁer of a qualiﬁed-id nominates a class, the name speciﬁed after the nested-namespeciﬁer is looked up in the scope of the class (10.2), except for the cases listed below. The name shall represent one or more members of that class or of one of its base classes (Clause 10). [ Note: A class member can be referred to using a qualiﬁed-id at any point in its potential scope (3.3.7). — end note ] The exceptions to the name lookup rule above are the following: — a destructor name is looked up as speciﬁed in 3.4.3; — a conversion-type-id of a conversion-function-id is looked up in the same manner as a conversion-type-id in a class member access (see 3.4.5); — the names in a template-argument of a template-id are looked up in the context in which the entire postﬁx-expression occurs. — the lookup for a name speciﬁed in a using-declaration (7.3.3) also ﬁnds class or enumeration names hidden within the same scope (3.3.10).

2

In a lookup in which the constructor is an acceptable lookup result and the nested-name-speciﬁer nominates a class C: — if the name speciﬁed after the nested-name-speciﬁer, when looked up in C, is the injected-class-name of C (Clause 9), or — in a using-declaration (7.3.3) that is a member-declaration, if the name speciﬁed after the nested-namespeciﬁer is the same as the identiﬁer or the simple-template-id’s template-name in the last component of the nested-name-speciﬁer, the name is instead considered to name the constructor of class C. [ Note: For example, the constructor is not an acceptable lookup result in an elaborated-type-speciﬁer so the constructor would not be used in place of the injected-class-name. — end note ] Such a constructor name shall be used only in the declarator-id of a declaration that names a constructor or in a using-declaration. [ Example: § 3.4.3.1 49

c ISO/IEC

N3337

struct A { A(); }; struct B: public A { B(); }; A::A() { } B::B() { } B::A ba; A::A a; struct A::A a2;
3

// object of type A // error, A::A is not a type name // object of type A

— end example ] A class member name hidden by a name in a nested declarative region or by the name of a derived class member can still be found if qualiﬁed by the name of its class followed by the :: operator. 3.4.3.2 Namespace members [namespace.qual]

1

2

3

If the nested-name-speciﬁer of a qualiﬁed-id nominates a namespace, the name speciﬁed after the nestedname-speciﬁer is looked up in the scope of the namespace. If a qualiﬁed-id starts with ::, the name after the :: is looked up in the global namespace. In either case, the names in a template-argument of a template-id are looked up in the context in which the entire postﬁx-expression occurs. For a namespace X and name m, the namespace-qualiﬁed lookup set S(X, m) is deﬁned as follows: Let S (X, m) be the set of all declarations of m in X and the inline namespace set of X (7.3.1). If S (X, m) is not empty, S(X, m) is S (X, m); otherwise, S(X, m) is the union of S(Ni , m) for all namespaces Ni nominated by using-directives in X and its inline namespace set. Given X::m (where X is a user-declared namespace), or given ::m (where X is the global namespace), if S(X, m) is the empty set, the program is ill-formed. Otherwise, if S(X, m) has exactly one member, or if the context of the reference is a using-declaration (7.3.3), S(X, m) is the required set of declarations of m. Otherwise if the use of m is not one that allows a unique declaration to be chosen from S(X, m), the program is ill-formed. [ Example: int x; namespace Y { void f(float); void h(int); } namespace Z { void h(double); } namespace A { using namespace Y; void f(int); void g(int); int i; } namespace B { using namespace Z; void f(char); int i; } namespace AB { using namespace A; using namespace B;

§ 3.4.3.2

50

c ISO/IEC

N3337

void g(); } void h() { AB::g(); AB::f(1);

AB::f(’c’); AB::x++;

// // // // // // // // // // // // // // // // // // // // // //

g is declared directly in AB, therefore S is { AB::g() } and AB::g() is chosen f is not declared directly in AB so the rules are applied recursively to A and B; namespace Y is not searched and Y::f(float) is not considered; S is { A::f(int), B::f(char) } and overload resolution chooses A::f(int) as above but resolution chooses B::f(char) x is not declared directly in AB, and is not declared in A or B , so the rules are applied recursively to Y and Z, S is { } so the program is ill-formed i is not declared directly in AB so the rules are applied recursively to A and B, S is { A::i , B::i } so the use is ambiguous and the program is ill-formed h is not declared directly in AB and not declared directly in A or B so the rules are applied recursively to Y and Z, S is { Y::h(int), Z::h(double) } and overload resolution chooses Z::h(double)

AB::i++;

AB::h(16.8);

}
4

The same declaration found more than once is not an ambiguity (because it is still a unique declaration). For example: namespace A { int a; } namespace B { using namespace A; } namespace C { using namespace A; } namespace BC { using namespace B; using namespace C; } void f() { BC::a++; } namespace D {

// OK: S is { A::a, A::a }

§ 3.4.3.2

51

c ISO/IEC

N3337

using A::a; } namespace BD { using namespace B; using namespace D; } void g() { BD::a++; }
5

// OK: S is {

A::a, A::a }

Because each referenced namespace is searched at most once, the following is well-deﬁned: namespace B { int b; } namespace A { using namespace B; int a; } namespace B { using namespace A; } void f() { A::a++; B::a++; A::b++; B::b++; }

// // // //

OK: OK: OK: OK:

a declared directly in A, S is { A::a} both A and B searched (once), S is { A::a} both A and B searched (once), S is { B::b} b declared directly in B, S is { B::b}

6

— end example ] During the lookup of a qualiﬁed namespace member name, if the lookup ﬁnds more than one declaration of the member, and if one declaration introduces a class name or enumeration name and the other declarations either introduce the same variable, the same enumerator or a set of functions, the non-type name hides the class or enumeration name if and only if the declarations are from the same namespace; otherwise (the declarations are from diﬀerent namespaces), the program is ill-formed. [ Example: namespace A { struct x { }; int x; int y; } namespace B { struct y { }; } namespace C { using namespace A; using namespace B; int i = C::x; // OK, A::x (of type int )

§ 3.4.3.2

52

c ISO/IEC

N3337

int j = C::y; }
7

// ambiguous, A::y or B::y

— end example ] In a declaration for a namespace member in which the declarator-id is a qualiﬁed-id, given that the qualiﬁed-id for the namespace member has the form nested-name-speciﬁer unqualiﬁed-id

the unqualiﬁed-id shall name a member of the namespace designated by the nested-name-speciﬁer or of an element of the inline namespace set (7.3.1) of that namespace. [ Example: namespace A { namespace B { void f1(int); } using namespace B; } void A::f1(int){ } // ill-formed, f1 is not a member of A

— end example ] However, in such namespace member declarations, the nested-name-speciﬁer may rely on using-directives to implicitly provide the initial part of the nested-name-speciﬁer. [ Example: namespace A { namespace B { void f1(int); } } namespace C { namespace D { void f1(int); } } using namespace A; using namespace C::D; void B::f1(int){ } // OK, deﬁnes A::B::f1(int)

— end example ]

3.4.4
1

Elaborated type speciﬁers

[basic.lookup.elab]

2

An elaborated-type-speciﬁer (7.1.6.3) may be used to refer to a previously declared class-name or enum-name even though the name has been hidden by a non-type declaration (3.3.10). If the elaborated-type-speciﬁer has no nested-name-speciﬁer, and unless the elaborated-type-speciﬁer appears in a declaration with the following form: class-key attribute-speciﬁer-seqopt identiﬁer ;

the identiﬁer is looked up according to 3.4.1 but ignoring any non-type names that have been declared. If the elaborated-type-speciﬁer is introduced by the enum keyword and this lookup does not ﬁnd a previously declared type-name, the elaborated-type-speciﬁer is ill-formed. If the elaborated-type-speciﬁer is introduced by the class-key and this lookup does not ﬁnd a previously declared type-name, or if the elaborated-type-speciﬁer appears in a declaration with the form: class-key attribute-speciﬁer-seqopt identiﬁer ;
3

the elaborated-type-speciﬁer is a declaration that introduces the class-name as described in 3.3.2. If the elaborated-type-speciﬁer has a nested-name-speciﬁer, qualiﬁed name lookup is performed, as described in 3.4.3, but ignoring any non-type names that have been declared. If the name lookup does not ﬁnd a previously declared type-name, the elaborated-type-speciﬁer is ill-formed. [ Example:

§ 3.4.4

53

c ISO/IEC

N3337

struct Node { struct Node* Next; struct Data* Data; }; struct Data { struct Node* Node; friend struct ::Glob; friend struct Glob; // at global scope. /∗ ... ∗/ }; struct Base { struct Data; struct ::Data* thatData; struct Base::Data* thisData; friend class ::Data; friend class Data; struct Data { /* ... */ }; }; struct struct struct struct struct Data; ::Data; Base::Data; Base::Datum; Base::Data* pBase;

// OK: Refers to Node at global scope // OK: Declares type Data // at global scope and member Data

// // // //

OK: Refers to Node at global scope error: Glob is not declared cannot introduce a qualiﬁed type (7.1.6.3) OK: Refers to (as yet) undeclared Glob

// // // // // //

OK: Declares nested Data OK: Refers to ::Data OK: Refers to nested Data OK: global Data is a friend OK: nested Data is a friend Deﬁnes nested Data

// // // // //

OK: Redeclares Data at global scope error: cannot introduce a qualiﬁed type (7.1.6.3) error: cannot introduce a qualiﬁed type (7.1.6.3) error: Datum undeﬁned OK: refers to nested Data

— end example ]

3.4.5
1

Class member access

[basic.lookup.classref]

2

3

In a class member access expression (5.2.5), if the . or -> token is immediately followed by an identiﬁer followed by a ~A(); }

// OK: lookup in *a ﬁnds the injected-class-name

§ 3.4.5

54

c ISO/IEC

N3337

4

— end example ] If the id-expression in a class member access is a qualiﬁed-id of the form class-name-or-namespace-name::... the class-name-or-namespace-name following the . or -> operator is ﬁrst looked up in the class of the object expression and the name, if found, is used. Otherwise it is looked up in the context of the entire postﬁx-expression. [ Note: See 3.4.3, which describes the lookup of a name before ::, which will only ﬁnd a type or namespace name. — end note ] If the qualiﬁed-id has the form ::class-name-or-namespace-name::...

5

6

7

the class-name-or-namespace-name is looked up in global scope as a class-name or namespace-name. If the nested-name-speciﬁer contains a simple-template-id (14.2), the names in its template-arguments are looked up in the context in which the entire postﬁx-expression occurs. If the id-expression is a conversion-function-id, its conversion-type-id is ﬁrst looked up in the class of the object expression and the name, if found, is used. Otherwise it is looked up in the context of the entire postﬁx-expression. In each of these lookups, only names that denote types or templates whose specializations are types are considered. [ Example: struct A { }; namespace N { struct A { void g() { } template operator T(); }; } int main() { N::A a; a.operator A(); }

// calls N::A::operator N::A

— end example ]

3.4.6
1

Using-directives and namespace aliases

[basic.lookup.udir]

In a using-directive or namespace-alias-deﬁnition, during the lookup for a namespace-name or for a name in a nested-name-speciﬁer only namespace names are considered.

3.5
1

Program and linkage

[basic.link]

A program consists of one or more translation units (Clause 2) linked together. A translation unit consists of a sequence of declarations. translation-unit: declaration-seqopt

2

A name is said to have linkage when it might denote the same object, reference, function, type, template, namespace or value as a name introduced by a declaration in another scope: — When a name has external linkage , the entity it denotes can be referred to by names from scopes of other translation units or from other scopes of the same translation unit. — When a name has internal linkage , the entity it denotes can be referred to by names from other scopes in the same translation unit. — When a name has no linkage , the entity it denotes cannot be referred to by names from other scopes.

3

A name having namespace scope (3.3.6) has internal linkage if it is the name of § 3.5 55

c ISO/IEC

N3337

— a variable, function or function template that is explicitly declared static; or, — a variable that is explicitly declared const or constexpr and neither explicitly declared extern nor previously declared to have external linkage; or — a data member of an anonymous union.
4

An unnamed namespace or a namespace declared directly or indirectly within an unnamed namespace has internal linkage. All other namespaces have external linkage. A name having namespace scope that has not been given internal linkage above has the same linkage as the enclosing namespace if it is the name of — a variable; or — a function; or — a named class (Clause 9), or an unnamed class deﬁned in a typedef declaration in which the class has the typedef name for linkage purposes (7.1.3); or — a named enumeration (7.2), or an unnamed enumeration deﬁned in a typedef declaration in which the enumeration has the typedef name for linkage purposes (7.1.3); or — an enumerator belonging to an enumeration with linkage; or — a template.

5

6

In addition, a member function, static data member, a named class or enumeration of class scope, or an unnamed class or enumeration deﬁned in a class-scope typedef declaration such that the class or enumeration has the typedef name for linkage purposes (7.1.3), has external linkage if the name of the class has external linkage. The name of a function declared in block scope and the name of a variable declared by a block scope extern declaration have linkage. If there is a visible declaration of an entity with linkage having the same name and type, ignoring entities declared outside the innermost enclosing namespace scope, the block scope declaration declares that same entity and receives the linkage of the previous declaration. If there is more than one such matching entity, the program is ill-formed. Otherwise, if no matching entity is found, the block scope entity receives external linkage.[ Example: static void f(); static int i = 0; void g() { extern void f(); int i; { extern void f(); extern int i; } } // #1 // internal linkage // #2 i has no linkage // internal linkage // #3 external linkage

7

There are three objects named i in this program. The object with internal linkage introduced by the declaration in global scope (line #1 ), the object with automatic storage duration and no linkage introduced by the declaration on line #2, and the object with static storage duration and external linkage introduced by the declaration on line #3. — end example ] When a block scope declaration of an entity with linkage is not found to refer to some other declaration, then that entity is a member of the innermost enclosing namespace. However such a declaration does not introduce the member name in its namespace scope. [ Example:

§ 3.5

56

c ISO/IEC

N3337

namespace X { void p() { q(); extern void q(); } void middle() { q(); } void q() { /* ... } void q() { /* ...
8

// error: q not yet declared // q is a member of namespace X

// error: q not yet declared

*/ }

// deﬁnition of X::q

*/ }

// some other, unrelated q

— end example ] Names not covered by these rules have no linkage. Moreover, except as noted, a name declared at block scope (3.3.3) has no linkage. A type is said to have linkage if and only if: — it is a class or enumeration type that is named (or has a name for linkage purposes (7.1.3)) and the name has linkage; or — it is an unnamed class or enumeration member of a class with linkage; or — it is a specialization of a class template (14)33 ; or — it is a fundamental type (3.9.1); or — it is a compound type (3.9.2) other than a class or enumeration, compounded exclusively from types that have linkage; or — it is a cv-qualiﬁed (3.9.3) version of a type that has linkage. A type without linkage shall not be used as the type of a variable or function with external linkage unless — the entity has C language linkage (7.5), or — the entity is declared within an unnamed namespace (7.3.1), or — the entity is not odr-used (3.2) or is deﬁned in the same translation unit. [ Note: In other words, a type without linkage contains a class or enumeration that cannot be named outside its translation unit. An entity with external linkage declared using such a type could not correspond to any other entity in another translation unit of the program and thus must be deﬁned in the translation unit if it is odr-used. Also note that classes with linkage may contain members whose types do not have linkage, and that typedef names are ignored in the determination of whether a type has linkage. — end note ] [ Example: template struct B { void g(T) { } void h(T); friend void i(B, T) { } };
33) A class template always has external linkage, and the requirements of 14.3.1 and 14.3.2 ensure that the template arguments will also have appropriate linkage.

§ 3.5

57

c ISO/IEC

N3337

void f() { struct A { int x; }; A a = { 1 }; B ba; ba.g(a); ba.h(a); i(ba, a); }
9

// no linkage // // // // declares B::g(A) and B::h(A) OK error: B::h(A) not defined in the translation unit OK

— end example ] Two names that are the same (Clause 3) and that are declared in diﬀerent scopes shall denote the same variable, function, type, enumerator, template or namespace if — both names have external linkage or else both names have internal linkage and are declared in the same translation unit; and — both names refer to members of the same namespace or to members, not by inheritance, of the same class; and — when both names denote functions, the parameter-type-lists of the functions (8.3.5) are identical; and — when both names denote function templates, the signatures (14.5.6.1) are the same.

10

11

After all adjustments of types (during which typedefs (7.1.3) are replaced by their deﬁnitions), the types speciﬁed by all declarations referring to a given variable or function shall be identical, except that declarations for an array object can specify array types that diﬀer by the presence or absence of a major array bound (8.3.4). A violation of this rule on type identity does not require a diagnostic. [ Note: Linkage to non-C++ declarations can be achieved using a linkage-speciﬁcation (7.5). — end note ]

3.6 3.6.1
1

Start and termination Main function

[basic.start] [basic.start.main]

2

A program shall contain a global function called main, which is the designated start of the program. It is implementation-deﬁned whether a program in a freestanding environment is required to deﬁne a main function. [ Note: In a freestanding environment, start-up and termination is implementation-deﬁned; startup contains the execution of constructors for objects of namespace scope with static storage duration; termination contains the execution of destructors for objects with static storage duration. — end note ] An implementation shall not predeﬁne the main function. This function shall not be overloaded. It shall have a return type of type int, but otherwise its type is implementation-deﬁned. All implementations shall allow both of the following deﬁnitions of main: int main() { /* ... */ }

and int main(int argc, char* argv[]) { /* ... */ }

In the latter form argc shall be the number of arguments passed to the program from the environment in which the program is run. If argc is nonzero these arguments shall be supplied in argv[0] through argv[argc-1] as pointers to the initial characters of null-terminated multibyte strings (ntmbs s) (17.5.2.1.4.2) and argv[0] shall be the pointer to the initial character of a ntmbs that represents the name used to invoke the program or "". The value of argc shall be non-negative. The value of argv[argc] shall be 0. [ Note: It is recommended that any further (optional) parameters be added after argv. — end note ]

§ 3.6.1

58

c ISO/IEC

N3337

3

4

5

The function main shall not be used within a program. The linkage (3.5) of main is implementation-deﬁned. A program that deﬁnes main as deleted or that declares main to be inline, static, or constexpr is illformed. The name main is not otherwise reserved. [ Example: member functions, classes, and enumerations can be called main, as can entities in other namespaces. — end example ] Terminating the program without leaving the current block (e.g., by calling the function std::exit(int) (18.5)) does not destroy any objects with automatic storage duration (12.4). If std::exit is called to end a program during the destruction of an object with static or thread storage duration, the program has undeﬁned behavior. A return statement in main has the eﬀect of leaving the main function (destroying any objects with automatic storage duration) and calling std::exit with the return value as the argument. If control reaches the end of main without encountering a return statement, the eﬀect is that of executing return 0;

3.6.2
1

Initialization of non-local variables

[basic.start.init]

2

There are two broad classes of named non-local variables: those with static storage duration (3.7.1) and those with thread storage duration (3.7.2). Non-local variables with static storage duration are initialized as a consequence of program initiation. Non-local variables with thread storage duration are initialized as a consequence of thread execution. Within each of these phases of initiation, initialization occurs as follows. Variables with static storage duration (3.7.1) or thread storage duration (3.7.2) shall be zero-initialized (8.5) before any other initialization takes place. Constant initialization is performed: — if each full-expression (including implicit conversions) that appears in the initializer of a reference with static or thread storage duration is a constant expression (5.19) and the reference is bound to an lvalue designating an object with static storage duration or to a temporary (see 12.2); — if an object with static or thread storage duration is initialized by a constructor call, if the constructor is a constexpr constructor, if all constructor arguments are constant expressions (including conversions), and if, after function invocation substitution (7.1.5), every constructor call and full-expression in the mem-initializers and in the brace-or-equal-initializers for non-static data members is a constant expression; — if an object with static or thread storage duration is not initialized by a constructor call and if every full-expression that appears in its initializer is a constant expression. Together, zero-initialization and constant initialization are called static initialization; all other initialization is dynamic initialization. Static initialization shall be performed before any dynamic initialization takes place. Dynamic initialization of a non-local variable with static storage duration is either ordered or unordered. Deﬁnitions of explicitly specialized class template static data members have ordered initialization. Other class template static data members (i.e., implicitly or explicitly instantiated specializations) have unordered initialization. Other non-local variables with static storage duration have ordered initialization. Variables with ordered initialization deﬁned within a single translation unit shall be initialized in the order of their deﬁnitions in the translation unit. If a program starts a thread (30.3), the subsequent initialization of a variable is unsequenced with respect to the initialization of a variable deﬁned in a diﬀerent translation unit. Otherwise, the initialization of a variable is indeterminately sequenced with respect to the initialization of a variable deﬁned in a diﬀerent translation unit. If a program starts a thread, the subsequent unordered initialization of a variable is unsequenced with respect to every other dynamic initialization. Otherwise, the unordered initialization of a variable is indeterminately sequenced with respect to every other dynamic initialization. [ Note: This deﬁnition permits initialization of a sequence of ordered variables concurrently with another sequence. — end note ] [ Note: The initialization of local static variables is described in 6.7. — end note ]

§ 3.6.2

59

c ISO/IEC

N3337

3

An implementation is permitted to perform the initialization of a non-local variable with static storage duration as a static initialization even if such initialization is not required to be done statically, provided that — the dynamic version of the initialization does not change the value of any other object of namespace scope prior to its initialization, and — the static version of the initialization produces the same value in the initialized variable as would be produced by the dynamic initialization if all variables not required to be initialized statically were initialized dynamically. [ Note: As a consequence, if the initialization of an object obj1 refers to an object obj2 of namespace scope potentially requiring dynamic initialization and deﬁned later in the same translation unit, it is unspeciﬁed whether the value of obj2 used will be the value of the fully initialized obj2 (because obj2 was statically initialized) or will be the value of obj2 merely zero-initialized. For example, inline double fd() { return 1.0; } extern double d1; double d2 = d1; // unspeciﬁed: // may be statically initialized to 0.0 or // dynamically initialized to 0.0 if d1 is // dynamically initialized, or 1.0 otherwise double d1 = fd(); // may be initialized statically or dynamically to 1.0

4

— end note ] It is implementation-deﬁned whether the dynamic initialization of a non-local variable with static storage duration is done before the ﬁrst statement of main. If the initialization is deferred to some point in time after the ﬁrst statement of main, it shall occur before the ﬁrst odr-use (3.2) of any function or variable deﬁned in the same translation unit as the variable to be initialized.34 [ Example:
// - File 1 #include "a.h" #include "b.h" B b; A::A(){ b.Use(); } // - File 2 #include "a.h" A a; // - File 3 #include "a.h" #include "b.h" extern A a; extern B b; int main() { a.Use(); b.Use(); }
34) A non-local variable with static storage duration having initialization with side-eﬀects must be initialized even if it is not odr-used (3.2, 3.7.1).

§ 3.6.2

60

c ISO/IEC

N3337

5

6

It is implementation-deﬁned whether either a or b is initialized before main is entered or whether the initializations are delayed until a is ﬁrst odr-used in main. In particular, if a is initialized before main is entered, it is not guaranteed that b will be initialized before it is odr-used by the initialization of a, that is, before A::A is called. If, however, a is initialized at some point after the ﬁrst statement of main, b will be initialized prior to its use in A::A. — end example ] It is implementation-deﬁned whether the dynamic initialization of a non-local variable with static or thread storage duration is done before the ﬁrst statement of the initial function of the thread. If the initialization is deferred to some point in time after the ﬁrst statement of the initial function of the thread, it shall occur before the ﬁrst odr-use (3.2) of any variable with thread storage duration deﬁned in the same translation unit as the variable to be initialized. If the initialization of a non-local variable with static or thread storage duration exits via an exception, std::terminate is called (15.5.1).

3.6.3
1

Termination

[basic.start.term]

2

3

4

Destructors (12.4) for initialized objects (that is, objects whose lifetime (3.8) has begun) with static storage duration are called as a result of returning from main and as a result of calling std::exit (18.5). Destructors for initialized objects with thread storage duration within a given thread are called as a result of returning from the initial function of that thread and as a result of that thread calling std::exit. The completions of the destructors for all initialized objects with thread storage duration within that thread are sequenced before the initiation of the destructors of any object with static storage duration. If the completion of the constructor or dynamic initialization of an object with thread storage duration is sequenced before that of another, the completion of the destructor of the second is sequenced before the initiation of the destructor of the ﬁrst. If the completion of the constructor or dynamic initialization of an object with static storage duration is sequenced before that of another, the completion of the destructor of the second is sequenced before the initiation of the destructor of the ﬁrst. [ Note: This deﬁnition permits concurrent destruction. — end note ] If an object is initialized statically, the object is destroyed in the same order as if the object was dynamically initialized. For an object of array or class type, all subobjects of that object are destroyed before any block-scope object with static storage duration initialized during the construction of the subobjects is destroyed. If the destruction of an object with static or thread storage duration exits via an exception, std::terminate is called (15.5.1). If a function contains a block-scope object of static or thread storage duration that has been destroyed and the function is called during the destruction of an object with static or thread storage duration, the program has undeﬁned behavior if the ﬂow of control passes through the deﬁnition of the previously destroyed blockscope object. Likewise, the behavior is undeﬁned if the block-scope object is used indirectly (i.e., through a pointer) after its destruction. If the completion of the initialization of an object with static storage duration is sequenced before a call to std::atexit (see , 18.5), the call to the function passed to std::atexit is sequenced before the call to the destructor for the object. If a call to std::atexit is sequenced before the completion of the initialization of an object with static storage duration, the call to the destructor for the object is sequenced before the call to the function passed to std::atexit. If a call to std::atexit is sequenced before another call to std::atexit, the call to the function passed to the second std::atexit call is sequenced before the call to the function passed to the ﬁrst std::atexit call. If there is a use of a standard library object or function not permitted within signal handlers (18.10) that does not happen before (1.10) completion of destruction of objects with static storage duration and execution of std::atexit registered functions (18.5), the program has undeﬁned behavior. [ Note: If there is a use of an object with static storage duration that does not happen before the object’s destruction, the program has undeﬁned behavior. Terminating every thread before a call to std::exit or the exit from main is suﬃcient, but not necessary, to satisfy these requirements. These requirements permit thread managers as static-storage-duration objects. — end note ]

§ 3.6.3

61

c ISO/IEC

N3337

5

Calling the function std::abort() declared in terminates the program without executing any destructors and without calling the functions passed to std::atexit() or std::at_quick_exit().

3.7
1

Storage duration

[basic.stc]

Storage duration is the property of an object that deﬁnes the minimum potential lifetime of the storage containing the object. The storage duration is determined by the construct used to create the object and is one of the following: — static storage duration — thread storage duration — automatic storage duration — dynamic storage duration

2

3

Static, thread, and automatic storage durations are associated with objects introduced by declarations (3.1) and implicitly created by the implementation (12.2). The dynamic storage duration is associated with objects created with operator new (5.3.4). The storage duration categories apply to references as well. The lifetime of a reference is its storage duration.

3.7.1
1

Static storage duration

[basic.stc.static]

2

3

4

All variables which do not have dynamic storage duration, do not have thread storage duration, and are not local have static storage duration. The storage for these entities shall last for the duration of the program (3.6.2, 3.6.3). If a variable with static storage duration has initialization or a destructor with side eﬀects, it shall not be eliminated even if it appears to be unused, except that a class object or its copy/move may be eliminated as speciﬁed in 12.8. The keyword static can be used to declare a local variable with static storage duration. [ Note: 6.7 describes the initialization of local static variables; 3.6.3 describes the destruction of local static variables. — end note ] The keyword static applied to a class data member in a class deﬁnition gives the data member static storage duration.

3.7.2
1

Thread storage duration

[basic.stc.thread]

2

All variables declared with the thread_local keyword have thread storage duration. The storage for these entities shall last for the duration of the thread in which they are created. There is a distinct object or reference per thread, and use of the declared name refers to the entity associated with the current thread. A variable with thread storage duration shall be initialized before its ﬁrst odr-use (3.2) and, if constructed, shall be destroyed on thread exit.

3.7.3
1

Automatic storage duration

[basic.stc.auto]

2 3

Block-scope variables explicitly declared register or not explicitly declared static or extern have automatic storage duration. The storage for these entities lasts until the block in which they are created exits. [ Note: These variables are initialized and destroyed as described in 6.7. — end note ] If a variable with automatic storage duration has initialization or a destructor with side eﬀects, it shall not be destroyed before the end of its block, nor shall it be eliminated as an optimization even if it appears to be unused, except that a class object or its copy/move may be eliminated as speciﬁed in 12.8.

3.7.4
1

Dynamic storage duration

[basic.stc.dynamic]

Objects can be created dynamically during program execution (1.9), using new-expressions (5.3.4), and destroyed using delete-expressions (5.3.5). A C++ implementation provides access to, and management of, dynamic storage via the global allocation functions operator new and operator new[] and the global deallocation functions operator delete and operator delete[]. § 3.7.4 62

c ISO/IEC

N3337

2

The library provides default deﬁnitions for the global allocation and deallocation functions. Some global allocation and deallocation functions are replaceable (18.6.1). A C++ program shall provide at most one deﬁnition of a replaceable allocation or deallocation function. Any such function deﬁnition replaces the default version provided in the library (17.6.4.6). The following allocation and deallocation functions (18.6) are implicitly declared in global scope in each translation unit of a program. void* operator new(std::size_t); void* operator new[](std::size_t); void operator delete(void*); void operator delete[](void*);

3

These implicit declarations introduce only the function names operator new, operator new[], operator delete, and operator delete[]. [ Note: The implicit declarations do not introduce the names std, std::size_t, or any other names that the library uses to declare these names. Thus, a new-expression, delete-expression or function call that refers to one of these functions without including the header is well-formed. However, referring to std or std::size_t is ill-formed unless the name has been declared by including the appropriate header. — end note ] Allocation and/or deallocation functions can also be declared and deﬁned for any class (12.5). Any allocation and/or deallocation functions deﬁned in a C++ program, including the default versions in the library, shall conform to the semantics speciﬁed in 3.7.4.1 and 3.7.4.2. 3.7.4.1 Allocation functions [basic.stc.dynamic.allocation] An allocation function shall be a class member function or a global function; a program is ill-formed if an allocation function is declared in a namespace scope other than global scope or declared static in global scope. The return type shall be void*. The ﬁrst parameter shall have type std::size_t (18.2). The ﬁrst parameter shall not have an associated default argument (8.3.6). The value of the ﬁrst parameter shall be interpreted as the requested size of the allocation. An allocation function can be a function template. Such a template shall declare its return type and ﬁrst parameter as speciﬁed above (that is, template parameter types shall not be used in the return type and ﬁrst parameter type). Template allocation functions shall have two or more parameters. The allocation function attempts to allocate the requested amount of storage. If it is successful, it shall return the address of the start of a block of storage whose length in bytes shall be at least as large as the requested size. There are no constraints on the contents of the allocated storage on return from the allocation function. The order, contiguity, and initial value of storage allocated by successive calls to an allocation function are unspeciﬁed. The pointer returned shall be suitably aligned so that it can be converted to a pointer of any complete object type with a fundamental alignment requirement (3.11) and then used to access the object or array in the storage allocated (until the storage is explicitly deallocated by a call to a corresponding deallocation function). Even if the size of the space requested is zero, the request can fail. If the request succeeds, the value returned shall be a non-null pointer value (4.10) p0 diﬀerent from any previously returned value p1, unless that value p1 was subsequently passed to an operator delete. The eﬀect of dereferencing a pointer returned as a request for zero size is undeﬁned.35 An allocation function that fails to allocate storage can invoke the currently installed new-handler function (18.6.2.3), if any. [ Note: A program-supplied allocation function can obtain the address of the currently installed new_handler using the std::get_new_handler function (18.6.2.4). — end note ] If an allocation function declared with a non-throwing exception-speciﬁcation (15.4) fails to allocate storage, it shall return a null pointer. Any other allocation function that fails to allocate storage shall indicate failure only by throwing an exception of a type that would match a handler (15.3) of type std::bad_alloc (18.6.2.1). A global allocation function is only called as the result of a new expression (5.3.4), or called directly using the function call syntax (5.2.2), or called indirectly through calls to the functions in the C++ standard library. [ Note: In particular, a global allocation function is not called to allocate storage for objects with static
35) The intent is to have operator new() implementable by calling std::malloc() or std::calloc(), so the rules are substantially the same. C++ diﬀers from C in requiring a zero request to return a non-null pointer.

1

2

3

4

§ 3.7.4.1

63

c ISO/IEC

N3337

storage duration (3.7.1), for objects or references with thread storage duration (3.7.2), for objects of type std::type_info (5.2.8), or for the copy of an object thrown by a throw expression (15.1). — end note ] 3.7.4.2 Deallocation functions [basic.stc.dynamic.deallocation]
1

2

3

4

Deallocation functions shall be class member functions or global functions; a program is ill-formed if deallocation functions are declared in a namespace scope other than global scope or declared static in global scope. Each deallocation function shall return void and its ﬁrst parameter shall be void*. A deallocation function can have more than one parameter. If a class T has a member deallocation function named operator delete with exactly one parameter, then that function is a usual (non-placement) deallocation function. If class T does not declare such an operator delete but does declare a member deallocation function named operator delete with exactly two parameters, the second of which has type std::size_t (18.2), then this function is a usual deallocation function. Similarly, if a class T has a member deallocation function named operator delete[] with exactly one parameter, then that function is a usual (non-placement) deallocation function. If class T does not declare such an operator delete[] but does declare a member deallocation function named operator delete[] with exactly two parameters, the second of which has type std::size_t, then this function is a usual deallocation function. A deallocation function can be an instance of a function template. Neither the ﬁrst parameter nor the return type shall depend on a template parameter. [ Note: That is, a deallocation function template shall have a ﬁrst parameter of type void* and a return type of void (as speciﬁed above). — end note ] A deallocation function template shall have two or more function parameters. A template instance is never a usual deallocation function, regardless of its signature. If a deallocation function terminates by throwing an exception, the behavior is undeﬁned. The value of the ﬁrst argument supplied to a deallocation function may be a null pointer value; if so, and if the deallocation function is one supplied in the standard library, the call has no eﬀect. Otherwise, the behavior is undeﬁned if the value supplied to operator delete(void*) in the standard library is not one of the values returned by a previous invocation of either operator new(std::size_t) or operator new(std::size_t, const std::nothrow_t&) in the standard library, and the behavior is undeﬁned if the value supplied to operator delete[](void*) in the standard library is not one of the values returned by a previous invocation of either operator new[](std::size_t) or operator new[](std::size_t, const std::nothrow_t&) in the standard library. If the argument given to a deallocation function in the standard library is a pointer that is not the null pointer value (4.10), the deallocation function shall deallocate the storage referenced by the pointer, rendering invalid all pointers referring to any part of the deallocated storage. The eﬀect of using an invalid pointer value (including passing it to a deallocation function) is undeﬁned.36 3.7.4.3 Safely-derived pointers [basic.stc.dynamic.safety] A traceable pointer object is — an object of an object pointer type (3.9.2), or — an object of an integral type that is at least as large as std::intptr_t, or — a sequence of elements in an array of character type, where the size and alignment of the sequence match those of some object pointer type.

1

2

A pointer value is a safely-derived pointer to a dynamic object only if it has an object pointer type and it is one of the following: — the value returned by a call to the C++ standard library implementation of ::operator new(std:: size_t);37
36) On some implementations, it causes a system-generated runtime fault. 37) This section does not impose restrictions on dereferencing pointers to memory not allocated by ::operator new. This

maintains the ability of many C++ implementations to use binary libraries and components written in other languages. In particular, this applies to C binaries, because dereferencing pointers to memory allocated by malloc is not restricted.

§ 3.7.4.3

64

c ISO/IEC

N3337

— the result of taking the address of an object (or one of its subobjects) designated by an lvalue resulting from dereferencing a safely-derived pointer value; — the result of well-deﬁned pointer arithmetic (5.7) using a safely-derived pointer value; — the result of a well-deﬁned pointer conversion (4.10, 5.4) of a safely-derived pointer value; — the result of a reinterpret_cast of a safely-derived pointer value; — the result of a reinterpret_cast of an integer representation of a safely-derived pointer value; — the value of an object whose value was copied from a traceable pointer object, where at the time of the copy the source object contained a copy of a safely-derived pointer value.
3

An integer value is an integer representation of a safely-derived pointer only if its type is at least as large as std::intptr_t and it is one of the following: — the result of a reinterpret_cast of a safely-derived pointer value; — the result of a valid conversion of an integer representation of a safely-derived pointer value; — the value of an object whose value was copied from a traceable pointer object, where at the time of the copy the source object contained an integer representation of a safely-derived pointer value; — the result of an additive or bitwise operation, one of whose operands is an integer representation of a safely-derived pointer value P, if that result converted by reinterpret_cast would compare equal to a safely-derived pointer computable from reinterpret_cast(P).

4

An implementation may have relaxed pointer safety, in which case the validity of a pointer value does not depend on whether it is a safely-derived pointer value. Alternatively, an implementation may have strict pointer safety, in which case a pointer value that is not a safely-derived pointer value is an invalid pointer value unless the referenced complete object is of dynamic storage duration and has previously been declared reachable (20.6.4). [ Note: the eﬀect of using an invalid pointer value (including passing it to a deallocation function) is undeﬁned, see 3.7.4.2. This is true even if the unsafely-derived pointer value might compare equal to some safely-derived pointer value. — end note ] It is implementation deﬁned whether an implementation has relaxed or strict pointer safety.

3.7.5
1

Duration of subobjects

[basic.stc.inherit]

The storage duration of member subobjects, base class subobjects and array elements is that of their complete object (1.8).

3.8
1

Object lifetime

[basic.life]

The lifetime of an object is a runtime property of the object. An object is said to have non-trivial initialization if it is of a class or aggregate type and it or one of its members is initialized by a constructor other than a trivial default constructor. [ Note: initialization by a trivial copy/move constructor is non-trivial initialization. — end note ] The lifetime of an object of type T begins when: — storage with the proper alignment and size for type T is obtained, and — if the object has non-trivial initialization, its initialization is complete. The lifetime of an object of type T ends when: — if T is a class type with a non-trivial destructor (12.4), the destructor call starts, or — the storage which the object occupies is reused or released. § 3.8 65

c ISO/IEC

N3337

2

3

4

5

[ Note: The lifetime of an array object starts as soon as storage with proper size and alignment is obtained, and its lifetime ends when the storage which the array occupies is reused or released. 12.6.2 describes the lifetime of base and member subobjects. — end note ] The properties ascribed to objects throughout this International Standard apply for a given object only during its lifetime. [ Note: In particular, before the lifetime of an object starts and after its lifetime ends there are signiﬁcant restrictions on the use of the object, as described below, in 12.6.2 and in 12.7. Also, the behavior of an object under construction and destruction might not be the same as the behavior of an object whose lifetime has started and not ended. 12.6.2 and 12.7 describe the behavior of objects during the construction and destruction phases. — end note ] A program may end the lifetime of any object by reusing the storage which the object occupies or by explicitly calling the destructor for an object of a class type with a non-trivial destructor. For an object of a class type with a non-trivial destructor, the program is not required to call the destructor explicitly before the storage which the object occupies is reused or released; however, if there is no explicit call to the destructor or if a delete-expression (5.3.5) is not used to release the storage, the destructor shall not be implicitly called and any program that depends on the side eﬀects produced by the destructor has undeﬁned behavior. Before the lifetime of an object has started but after the storage which the object will occupy has been allocated38 or, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, any pointer that refers to the storage location where the object will be or was located may be used but only in limited ways. For an object under construction or destruction, see 12.7. Otherwise, such a pointer refers to allocated storage (3.7.4.2), and using the pointer as if the pointer were of type void*, is well-deﬁned. Such a pointer may be dereferenced but the resulting lvalue may only be used in limited ways, as described below. The program has undeﬁned behavior if: — the object will be or was of a class type with a non-trivial destructor and the pointer is used as the operand of a delete-expression, — the pointer is used to access a non-static data member or call a non-static member function of the object, or — the pointer is implicitly converted (4.10) to a pointer to a base class type, or — the pointer is used as the operand of a static_cast (5.2.9) (except when the conversion is to void*, or to void* and subsequently to char*, or unsigned char*), or — the pointer is used as the operand of a dynamic_cast (5.2.7). [ Example:
#include struct B { virtual void f(); void mutate(); virtual ~B(); }; struct D1 : B { void f(); }; struct D2 : B { void f(); }; void B::mutate() { new (this) D2; f(); ... = this; }

// reuses storage — ends the lifetime of *this // undeﬁned behavior // OK, this points to valid memory

38) For example, before the construction of a global object of non-POD class type (12.7).

§ 3.8

66

c ISO/IEC

N3337

void g() { void* p = std::malloc(sizeof(D1) + sizeof(D2)); B* pb = new (p) D1; pb->mutate(); &pb; // OK: pb points to valid memory void* q = pb; // OK: pb points to valid memory pb->f(); // undeﬁned behavior, lifetime of *pb has ended }

— end example ]
6

Similarly, before the lifetime of an object has started but after the storage which the object will occupy has been allocated or, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, any glvalue that refers to the original object may be used but only in limited ways. For an object under construction or destruction, see 12.7. Otherwise, such a glvalue refers to allocated storage (3.7.4.2), and using the properties of the glvalue that do not depend on its value is well-deﬁned. The program has undeﬁned behavior if: — an lvalue-to-rvalue conversion (4.1) is applied to such a glvalue, — the glvalue is used to access a non-static data member or call a non-static member function of the object, or — the glvalue is implicitly converted (4.10) to a reference to a base class type, or — the glvalue is used as the operand of a static_cast (5.2.9) except when the conversion is ultimately to cv char& or cv unsigned char&, or — the glvalue is used as the operand of a dynamic_cast (5.2.7) or as the operand of typeid.

7

If, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, a new object is created at the storage location which the original object occupied, a pointer that pointed to the original object, a reference that referred to the original object, or the name of the original object will automatically refer to the new object and, once the lifetime of the new object has started, can be used to manipulate the new object, if: — the storage for the new object exactly overlays the storage location which the original object occupied, and — the new object is of the same type as the original object (ignoring the top-level cv-qualiﬁers), and — the type of the original object is not const-qualiﬁed, and, if a class type, does not contain any non-static data member whose type is const-qualiﬁed or a reference type, and — the original object was a most derived object (1.8) of type T and the new object is a most derived object of type T (that is, they are not base class subobjects). [ Example: struct C { int i; void f(); const C& operator=( const C& ); }; const C& C::operator=( const C& other) { if ( this != &other ) {

§ 3.8

67

c ISO/IEC

N3337

this->~C(); new (this) C(other); f(); } return *this; } C c1; C c2; c1 = c2; c1.f();

// lifetime of *this ends // new object of type C created // well-deﬁned

// well-deﬁned // well-deﬁned; c1 refers to a new object of type C

— end example ]
8

If a program ends the lifetime of an object of type T with static (3.7.1), thread (3.7.2), or automatic (3.7.3) storage duration and if T has a non-trivial destructor,39 the program must ensure that an object of the original type occupies that same storage location when the implicit destructor call takes place; otherwise the behavior of the program is undeﬁned. This is true even if the block is exited with an exception. [ Example: class T { }; struct B { ~B(); }; void h() { B b; new (&b) T; }

// undeﬁned behavior at block exit

9

— end example ] Creating a new object at the storage location that a const object with static, thread, or automatic storage duration occupies or, at the storage location that such a const object used to occupy before its lifetime ended results in undeﬁned behavior. [ Example: struct B { B(); ~B(); }; const B b; void h() { b.~B(); new (const_cast(&b)) const B; }

// undeﬁned behavior

10

— end example ] In this section, “before” and “after” refer to the “happens before” relation (1.10). [ Note: Therefore, undeﬁned behavior results if an object that is being constructed in one thread is referenced from another thread without adequate synchronization. — end note ]
39) That is, an object for which a destructor will be called implicitly—upon exit from the block for an object with automatic storage duration, upon exit from the thread for an object with thread storage duration, or upon exit from the program for an object with static storage duration.

§ 3.8

68

c ISO/IEC

N3337

3.9
1

Types

[basic.types]

2

[ Note: 3.9 and the subclauses thereof impose requirements on implementations regarding the representation of types. There are two kinds of types: fundamental types and compound types. Types describe objects (1.8), references (8.3.2), or functions (8.3.5). — end note ] For any object (other than a base-class subobject) of trivially copyable type T, whether or not the object holds a valid value of type T, the underlying bytes (1.7) making up the object can be copied into an array of char or unsigned char.40 If the content of the array of char or unsigned char is copied back into the object, the object shall subsequently hold its original value. [ Example:
#define N sizeof(T) char buf[N]; T obj; std::memcpy(buf, &obj, N); std::memcpy(&obj, buf, N);

// // // // //

obj initialized to its original value between these two calls to std::memcpy, obj might be modiﬁed at this point, each subobject of obj of scalar type holds its original value

3

— end example ] For any trivially copyable type T, if two pointers to T point to distinct T objects obj1 and obj2, where neither obj1 nor obj2 is a base-class subobject, if the underlying bytes (1.7) making up obj1 are copied into obj2,41 obj2 shall subsequently hold the same value as obj1. [ Example:
T* t1p; T* t2p; // provided that t2p points to an initialized object ... std::memcpy(t1p, t2p, sizeof(T)); // at this point, every subobject of trivially copyable type in *t1p contains // the same value as the corresponding subobject in *t2p

4

5

6

— end example ] The object representation of an object of type T is the sequence of N unsigned char objects taken up by the object of type T, where N equals sizeof(T). The value representation of an object is the set of bits that hold the value of type T. For trivially copyable types, the value representation is a set of bits in the object representation that determines a value, which is one discrete element of an implementation-deﬁned set of values.42 A class that has been declared but not deﬁned, or an array of unknown size or of incomplete element type, is an incompletely-deﬁned object type.43 Incompletely-deﬁned object types and the void types are incomplete types (3.9.1). Objects shall not be deﬁned to have an incomplete type. A class type (such as “class X”) might be incomplete at one point in a translation unit and complete later on; the type “class X” is the same type at both points. The declared type of an array object might be an array of incomplete class type and therefore incomplete; if the class type is completed later on in the translation unit, the array type becomes complete; the array type at those two points is the same type. The declared type of an array object might be an array of unknown size and therefore be incomplete at one point in a translation unit and complete later on; the array types at those two points (“array of unknown bound of T” and “array of N T”) are diﬀerent types. The type of a pointer to array of unknown size, or of a type deﬁned by a typedef declaration to be an array of unknown size, cannot be completed. [ Example: class X; extern X* xp; extern int arr[];
40) 41) 42) 43)

// X is an incomplete type // xp is a pointer to an incomplete type // the type of arr is incomplete

By using, for example, the library functions (17.6.1.2) std::memcpy or std::memmove. By using, for example, the library functions (17.6.1.2) std::memcpy or std::memmove. The intent is that the memory model of C++ is compatible with that of ISO/IEC 9899 Programming Language C. The size and layout of an instance of an incompletely-deﬁned object type is unknown.

§ 3.9

69

c ISO/IEC

N3337

typedef int UNKA[]; UNKA* arrp; UNKA** arrpp; void foo() { xp++; arrp++; arrpp++; } struct X { int i; }; int arr[10]; X x; void bar() { xp = &x; arrp = &arr; xp++; arrp++; }
7

// UNKA is an incomplete type // arrp is a pointer to an incomplete type

// ill-formed: X is incomplete // ill-formed: incomplete type // OK: sizeof UNKA* is known

// now X is a complete type // now the type of arr is complete

// // // //

OK; type is “pointer to X” ill-formed: diﬀerent types OK: X is complete ill-formed: UNKA can’t be completed

8

9

10

— end example ] [ Note: The rules for declarations and expressions describe in which contexts incomplete types are prohibited. — end note ] An object type is a (possibly cv-qualiﬁed) type that is not a function type, not a reference type, and not a void type. Arithmetic types (3.9.1), enumeration types, pointer types, pointer to member types (3.9.2), std::nullptr_t, and cv-qualiﬁed versions of these types (3.9.3) are collectively called scalar types. Scalar types, POD classes (Clause 9), arrays of such types and cv-qualiﬁed versions of these types (3.9.3) are collectively called POD types. Scalar types, trivially copyable class types (Clause 9), arrays of such types, and cv-qualiﬁed versions of these types (3.9.3) are collectively called trivially copyable types. Scalar types, trivial class types (Clause 9), arrays of such types and cv-qualiﬁed versions of these types (3.9.3) are collectively called trivial types. Scalar types, standard-layout class types (Clause 9), arrays of such types and cv-qualiﬁed versions of these types (3.9.3) are collectively called standard-layout types. A type is a literal type if it is: — a scalar type; or — a reference type referring to a literal type; or — an array of literal type; or — a class type (Clause 9) that has all of the following properties: — it has a trivial destructor, — every constructor call and full-expression in the brace-or-equal-initializers for non-static data members (if any) is a constant expression (5.19), — it is an aggregate type (8.5.1) or has at least one constexpr constructor or constructor template that is not a copy or move constructor, and — all of its non-static data members and base classes are of literal types.

11

If two types T1 and T2 are the same type, then T1 and T2 are layout-compatible types. [ Note: Layoutcompatible enumerations are described in 7.2. Layout-compatible standard-layout structs and standardlayout unions are described in 9.2. — end note ] § 3.9 70

c ISO/IEC

N3337

3.9.1
1

Fundamental types

[basic.fundamental]

2

3

4

5

6

7

Objects declared as characters (char) shall be large enough to store any member of the implementation’s basic character set. If a character from this set is stored in a character object, the integral value of that character object is equal to the value of the single character literal form of that character. It is implementation-deﬁned whether a char object can hold negative values. Characters can be explicitly declared unsigned or signed. Plain char, signed char, and unsigned char are three distinct types. A char, a signed char, and an unsigned char occupy the same amount of storage and have the same alignment requirements (3.11); that is, they have the same object representation. For character types, all bits of the object representation participate in the value representation. For unsigned character types, all possible bit patterns of the value representation represent numbers. These requirements do not hold for other types. In any particular implementation, a plain char object can take on either the same values as a signed char or an unsigned char; which one is implementation-deﬁned. There are ﬁve standard signed integer types : “signed char”, “short int”, “int”, “long int”, and “long long int”. In this list, each type provides at least as much storage as those preceding it in the list. There may also be implementation-deﬁned extended signed integer types. The standard and extended signed integer types are collectively called signed integer types. Plain ints have the natural size suggested by the architecture of the execution environment44 ; the other signed integer types are provided to meet special needs. For each of the standard signed integer types, there exists a corresponding (but diﬀerent) standard unsigned integer type: “unsigned char”, “unsigned short int”, “unsigned int”, “unsigned long int”, and “unsigned long long int”, each of which occupies the same amount of storage and has the same alignment requirements (3.11) as the corresponding signed integer type45 ; that is, each signed integer type has the same object representation as its corresponding unsigned integer type. Likewise, for each of the extended signed integer types there exists a corresponding extended unsigned integer type with the same amount of storage and alignment requirements. The standard and extended unsigned integer types are collectively called unsigned integer types. The range of non-negative values of a signed integer type is a subrange of the corresponding unsigned integer type, and the value representation of each corresponding signed/unsigned type shall be the same. The standard signed integer types and standard unsigned integer types are collectively called the standard integer types, and the extended signed integer types and extended unsigned integer types are collectively called the extended integer types. Unsigned integers, declared unsigned, shall obey the laws of arithmetic modulo 2n where n is the number of bits in the value representation of that particular size of integer.46 Type wchar_t is a distinct type whose values can represent distinct codes for all members of the largest extended character set speciﬁed among the supported locales (22.3.1). Type wchar_t shall have the same size, signedness, and alignment requirements (3.11) as one of the other integral types, called its underlying type. Types char16_t and char32_t denote distinct types with the same size, signedness, and alignment as uint_least16_t and uint_least32_t, respectively, in , called the underlying types. Values of type bool are either true or false.47 [ Note: There are no signed, unsigned, short, or long bool types or values. — end note ] Values of type bool participate in integral promotions (4.5). Types bool, char, char16_t, char32_t, wchar_t, and the signed and unsigned integer types are collectively called integral types.48 A synonym for integral type is integer type. The representations of integral types shall deﬁne values by use of a pure binary numeration system.49 [ Example: this International Standard
44) that is, large enough to contain any value in the range of INT_MIN and INT_MAX, as deﬁned in the header . 45) See 7.1.6.2 regarding the correspondence between types and the sequences of type-speciﬁers that designate them. 46) This implies that unsigned arithmetic does not overﬂow because a result that cannot be represented by the resulting

unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting unsigned integer type. 47) Using a bool value in ways described by this International Standard as “undeﬁned,” such as by examining the value of an uninitialized automatic object, might cause it to behave as if it is neither true nor false. 48) Therefore, enumerations (7.2) are not integral; however, enumerations can be promoted to integral types as speciﬁed in 4.5. 49) A positional representation for integers that uses the binary digits 0 and 1, in which the values represented by successive

§ 3.9.1

71

c ISO/IEC

N3337

8

9

10

11

permits 2’s complement, 1’s complement and signed magnitude representations for integral types. — end example ] There are three ﬂoating point types: float, double, and long double. The type double provides at least as much precision as float, and the type long double provides at least as much precision as double. The set of values of the type float is a subset of the set of values of the type double; the set of values of the type double is a subset of the set of values of the type long double. The value representation of ﬂoating-point types is implementation-deﬁned. Integral and ﬂoating types are collectively called arithmetic types. Specializations of the standard template std::numeric_limits (18.3) shall specify the maximum and minimum values of each arithmetic type for an implementation. The void type has an empty set of values. The void type is an incomplete type that cannot be completed. It is used as the return type for functions that do not return a value. Any expression can be explicitly converted to type cv void (5.4). An expression of type void shall be used only as an expression statement (6.2), as an operand of a comma expression (5.18), as a second or third operand of ?: (5.16), as the operand of typeid or decltype, as the expression in a return statement (6.6.3) for a function with the return type void, or as the operand of an explicit conversion to type cv void. A value of type std::nullptr_t is a null pointer constant (4.10). Such values participate in the pointer and the pointer to member conversions (4.10, 4.11). sizeof(std::nullptr_t) shall be equal to sizeof(void*). [ Note: Even if the implementation deﬁnes two or more basic types to have the same value representation, they are nevertheless diﬀerent types. — end note ]

3.9.2
1

Compound types

[basic.compound]

Compound types can be constructed in the following ways: — arrays of objects of a given type, 8.3.4; — functions, which have parameters of given types and return void or references or objects of a given type, 8.3.5; — pointers to void or objects or functions (including static members of classes) of a given type, 8.3.1; — references to objects or functions of a given type, 8.3.2. There are two types of references: — lvalue reference — rvalue reference — classes containing a sequence of objects of various types (Clause 9), a set of types, enumerations and functions for manipulating these objects (9.3), and a set of restrictions on the access to these entities (Clause 11); — unions, which are classes capable of containing objects of diﬀerent types at diﬀerent times, 9.5; — enumerations, which comprise a set of named constant values. Each distinct enumeration constitutes a diﬀerent enumerated type, 7.2; — pointers to non-static given class, 8.3.3.
50

class members, which identify members of a given type within objects of a

2

3

These methods of constructing types can be applied recursively; restrictions are mentioned in 8.3.1, 8.3.4, 8.3.5, and 8.3.2. The type of a pointer to void or a pointer to an object type is called an object pointer type. [ Note: A pointer to void does not have a pointer-to-object type, however, because void is not an object type. — end note ] The type of a pointer that can designate a function is called a function pointer type. A pointer to objects bits are additive, begin with 1, and are multiplied by successive integral power of 2, except perhaps for the bit with the highest position. (Adapted from the American National Dictionary for Information Processing Systems.) 50) Static class members are objects or functions, and pointers to them are ordinary pointers to objects or functions.

§ 3.9.2

72

c ISO/IEC

N3337

4

of type T is referred to as a “pointer to T.” [ Example: a pointer to an object of type int is referred to as “pointer to int ” and a pointer to an object of class X is called a “pointer to X.” — end example ] Except for pointers to static members, text referring to “pointers” does not apply to pointers to members. Pointers to incomplete types are allowed although there are restrictions on what can be done with them (3.11). A valid value of an object pointer type represents either the address of a byte in memory (1.7) or a null pointer (4.10). If an object of type T is located at an address A, a pointer of type cv T* whose value is the address A is said to point to that object, regardless of how the value was obtained. [ Note: For instance, the address one past the end of an array (5.7) would be considered to point to an unrelated object of the array’s element type that might be located at that address. There are further restrictions on pointers to objects with dynamic storage duration; see 3.7.4.3. — end note ] The value representation of pointer types is implementation-deﬁned. Pointers to cv-qualiﬁed and cv-unqualiﬁed versions (3.9.3) of layout-compatible types shall have the same value representation and alignment requirements (3.11). [ Note: Pointers to over-aligned types (3.11) have no special representation, but their range of valid values is restricted by the extended alignment requirement. This International Standard speciﬁes only two ways of obtaining such a pointer: taking the address of a valid object with an over-aligned type, and using one of the runtime pointer alignment functions. An implementation may provide other means of obtaining a valid pointer value for an over-aligned type. — end note ] A pointer to cv-qualiﬁed (3.9.3) or cv-unqualiﬁed void can be used to point to objects of unknown type. Such a pointer shall be able to hold any object pointer. An object of type cv void* shall have the same representation and alignment requirements as cv char*.

3.9.3
1

CV-qualiﬁers

[basic.type.qualiﬁer]

2

3

4

5

A type mentioned in 3.9.1 and 3.9.2 is a cv-unqualiﬁed type. Each type which is a cv-unqualiﬁed complete or incomplete object type or is void (3.9) has three corresponding cv-qualiﬁed versions of its type: a const-qualiﬁed version, a volatile-qualiﬁed version, and a const-volatile-qualiﬁed version. The term object type (1.8) includes the cv-qualiﬁers speciﬁed when the object is created. The presence of a const speciﬁer in a decl-speciﬁer-seq declares an object of const-qualiﬁed object type; such object is called a const object. The presence of a volatile speciﬁer in a decl-speciﬁer-seq declares an object of volatile-qualiﬁed object type; such object is called a volatile object. The presence of both cv-qualiﬁers in a decl-speciﬁer-seq declares an object of const-volatile-qualiﬁed object type; such object is called a const volatile object. The cv-qualiﬁed or cv-unqualiﬁed versions of a type are distinct types; however, they shall have the same representation and alignment requirements (3.9).51 A compound type (3.9.2) is not cv-qualiﬁed by the cv-qualiﬁers (if any) of the types from which it is compounded. Any cv-qualiﬁers applied to an array type aﬀect the array element type, not the array type (8.3.4). Each non-static, non-mutable, non-reference data member of a const-qualiﬁed class object is const-qualiﬁed, each non-static, non-reference data member of a volatile-qualiﬁed class object is volatile-qualiﬁed and similarly for members of a const-volatile class. See 8.3.5 and 9.3.2 regarding function types that have cv-qualiﬁers. There is a partial ordering on cv-qualiﬁers, so that a type can be said to be more cv-qualiﬁed than another. Table 9 shows the relations that constitute this ordering. In this International Standard, the notation cv (or cv1 , cv2 , etc.), used in the description of types, represents an arbitrary set of cv-qualiﬁers, i.e., one of {const}, {volatile}, {const, volatile}, or the empty set. Cv-qualiﬁers applied to an array type attach to the underlying element type, so the notation “cv T,” where T is an array type, refers to an array whose elements are so-qualiﬁed. Such array types can be said to be

§ 3.9.3

73

c ISO/IEC

N3337

Table 9 — Relations on const and volatile no cv-qualiﬁer no cv-qualiﬁer no cv-qualiﬁer const volatile < < < < < const volatile const volatile const volatile const volatile

expression glvalue lvalue xvalue rvalue prvalue

Figure 1 — Expression category taxonomy

more (or less) cv-qualiﬁed than other types based on the cv-qualiﬁcation of the underlying element types.

3.10
1

Lvalues and rvalues

[basic.lval]

Expressions are categorized according to the taxonomy in Figure 1. — An lvalue (so called, historically, because lvalues could appear on the left-hand side of an assignment expression) designates a function or an object. [ Example: If E is an expression of pointer type, then *E is an lvalue expression referring to the object or function to which E points. As another example, the result of calling a function whose return type is an lvalue reference is an lvalue. — end example ] — An xvalue (an “eXpiring” value) also refers to an object, usually near the end of its lifetime (so that its resources may be moved, for example). An xvalue is the result of certain kinds of expressions involving rvalue references (8.3.2). [ Example: The result of calling a function whose return type is an rvalue reference is an xvalue. — end example ] — A glvalue (“generalized” lvalue) is an lvalue or an xvalue. — An rvalue (so called, historically, because rvalues could appear on the right-hand side of an assignment expression) is an xvalue, a temporary object (12.2) or subobject thereof, or a value that is not associated with an object. — A prvalue (“pure” rvalue) is an rvalue that is not an xvalue. [ Example: The result of calling a function whose return type is not a reference is a prvalue. The value of a literal such as 12, 7.3e5, or true is also a prvalue. — end example ] Every expression belongs to exactly one of the fundamental classiﬁcations in this taxonomy: lvalue, xvalue, or prvalue. This property of an expression is called its value category. [ Note: The discussion of each built-in operator in Clause 5 indicates the category of the value it yields and the value categories of the operands it expects. For example, the built-in assignment operators expect that the left operand is an lvalue and that the right operand is a prvalue and yield an lvalue as the result. User-deﬁned operators are
51) The same representation and alignment requirements are meant to imply interchangeability as arguments to functions, return values from functions, and non-static data members of unions.

§ 3.10

74

c ISO/IEC

N3337

2

3

4

5

6 7

8

9

10

functions, and the categories of values they expect and yield are determined by their parameter and return types. — end note ] Whenever a glvalue appears in a context where a prvalue is expected, the glvalue is converted to a prvalue; see 4.1, 4.2, and 4.3. [ Note: An attempt to bind an rvalue reference to an lvalue is not such a context; see 8.5.3. — end note ] The discussion of reference initialization in 8.5.3 and of temporaries in 12.2 indicates the behavior of lvalues and rvalues in other signiﬁcant contexts. Class prvalues can have cv-qualiﬁed types; non-class prvalues always have cv-unqualiﬁed types. Unless otherwise indicated (5.2.2), prvalues shall always have complete types or the void type; in addition to these types, glvalues can also have incomplete types. An lvalue for an object is necessary in order to modify the object except that an rvalue of class type can also be used to modify its referent under certain circumstances. [ Example: a member function called for an object (9.3) can modify the object. — end example ] Functions cannot be modiﬁed, but pointers to functions can be modiﬁable. A pointer to an incomplete type can be modiﬁable. At some point in the program when the pointed to type is complete, the object at which the pointer points can also be modiﬁed. The referent of a const-qualiﬁed expression shall not be modiﬁed (through that expression), except that if it is of class type and has a mutable component, that component can be modiﬁed (7.1.6.1). If an expression can be used to modify the object to which it refers, the expression is called modiﬁable. A program that attempts to modify an object through a nonmodiﬁable lvalue or rvalue expression is ill-formed. If a program attempts to access the stored value of an object through a glvalue of other than one of the following types the behavior is undeﬁned:52 — the dynamic type of the object, — a cv-qualiﬁed version of the dynamic type of the object, — a type similar (as deﬁned in 4.4) to the dynamic type of the object, — a type that is the signed or unsigned type corresponding to the dynamic type of the object, — a type that is the signed or unsigned type corresponding to a cv-qualiﬁed version of the dynamic type of the object, — an aggregate or union type that includes one of the aforementioned types among its elements or nonstatic data members (including, recursively, an element or non-static data member of a subaggregate or contained union), — a type that is a (possibly cv-qualiﬁed) base class type of the dynamic type of the object, — a char or unsigned char type.

3.11
1

Alignment

[basic.align]

2

Object types have alignment requirements (3.9.1, 3.9.2) which place restrictions on the addresses at which an object of that type may be allocated. An alignment is an implementation-deﬁned integer value representing the number of bytes between successive addresses at which a given object can be allocated. An object type imposes an alignment requirement on every object of that type; stricter alignment can be requested using the alignment speciﬁer (7.6.2). A fundamental alignment is represented by an alignment less than or equal to the greatest alignment supported by the implementation in all contexts, which is equal to alignof(std::max_align_t) (18.2). The alignment required for a type might be diﬀerent when it is used as the type of a complete object and when it is used as the type of a subobject. [ Example:
52) The intent of this list is to specify those circumstances in which an object may or may not be aliased.

§ 3.11

75

c ISO/IEC

N3337

struct B { long double d; }; struct D : virtual B { char c; }

3

4

5

6

7

When D is the type of a complete object, it will have a subobject of type B, so it must be aligned appropriately for a long double. If D appears as a subobject of another object that also has B as a virtual base class, the B subobject might be part of a diﬀerent subobject, reducing the alignment requirements on the D subobject. — end example ] The result of the alignof operator reﬂects the alignment requirement of the type in the complete-object case. An extended alignment is represented by an alignment greater than alignof(std::max_align_t). It is implementation-deﬁned whether any extended alignments are supported and the contexts in which they are supported (7.6.2). A type having an extended alignment requirement is an over-aligned type. [ Note: every over-aligned type is or contains a class type to which extended alignment applies (possibly through a non-static data member). — end note ] Alignments are represented as values of the type std::size_t. Valid alignments include only those values returned by an alignof expression for the fundamental types plus an additional implementation-deﬁned set of values, which may be empty. Every alignment value shall be a non-negative integral power of two. Alignments have an order from weaker to stronger or stricter alignments. Stricter alignments have larger alignment values. An address that satisﬁes an alignment requirement also satisﬁes any weaker valid alignment requirement. The alignment requirement of a complete type can be queried using an alignof expression (5.3.6). Furthermore, the types char, signed char, and unsigned char shall have the weakest alignment requirement. [ Note: This enables the character types to be used as the underlying type for an aligned memory area (7.6.2). — end note ] Comparing alignments is meaningful and provides the obvious results: — Two alignments are equal when their numeric values are equal. — Two alignments are diﬀerent when their numeric values are not equal. — When an alignment is larger than another it represents a stricter alignment.

8

9

[ Note: The runtime pointer alignment function (20.6.5) can be used to obtain an aligned pointer within a buﬀer; the aligned-storage templates in the library (20.9.7.6) can be used to obtain aligned storage. — end note ] If a request for a speciﬁc extended alignment in a speciﬁc context is not supported by an implementation, the program is ill-formed. Additionally, a request for runtime allocation of dynamic storage for which the requested alignment cannot be honored shall be treated as an allocation failure.

§ 3.11

76

c ISO/IEC

N3337

4
1

Standard conversions

[conv]

Standard conversions are implicit conversions with built-in meaning. Clause 4 enumerates the full set of such conversions. A standard conversion sequence is a sequence of standard conversions in the following order: — Zero or one conversion from the following set: lvalue-to-rvalue conversion, array-to-pointer conversion, and function-to-pointer conversion. — Zero or one conversion from the following set: integral promotions, ﬂoating point promotion, integral conversions, ﬂoating point conversions, ﬂoating-integral conversions, pointer conversions, pointer to member conversions, and boolean conversions. — Zero or one qualiﬁcation conversion. [ Note: A standard conversion sequence can be empty, i.e., it can consist of no conversions. — end note ] A standard conversion sequence will be applied to an expression if necessary to convert it to a required destination type. [ Note: expressions with a given type will be implicitly converted to other types in several contexts: — When used as operands of operators. The operator’s requirements for its operands dictate the destination type (Clause 5). — When used in the condition of an if statement or iteration statement (6.4, 6.5). The destination type is bool. — When used in the expression of a switch statement. The destination type is integral (6.4). — When used as the source expression for an initialization (which includes use as an argument in a function call and use as the expression in a return statement). The type of the entity being initialized is (generally) the destination type. See 8.5, 8.5.3. — end note ] An expression e can be implicitly converted to a type T if and only if the declaration T t=e; is well-formed, for some invented temporary variable t (8.5). Certain language constructs require that an expression be converted to a Boolean value. An expression e appearing in such a context is said to be contextually converted to bool and is well-formed if and only if the declaration bool t(e); is well-formed, for some invented temporary variable t (8.5). The eﬀect of either implicit conversion is the same as performing the declaration and initialization and then using the temporary variable as the result of the conversion. The result is an lvalue if T is an lvalue reference type or an rvalue reference to function type (8.3.2), an xvalue if T is an rvalue reference to object type, and a prvalue otherwise. The expression e is used as a glvalue if and only if the initialization uses it as a glvalue. [ Note: For user-deﬁned types, user-deﬁned conversions are considered as well; see 12.3. In general, an implicit conversion sequence (13.3.3.1) consists of a standard conversion sequence followed by a user-deﬁned conversion followed by another standard conversion sequence. — end note ] [ Note: There are some contexts where certain conversions are suppressed. For example, the lvalue-torvalue conversion is not done on the operand of the unary & operator. Speciﬁc exceptions are given in the descriptions of those operators and contexts. — end note ]

2

3

4

5

Standard conversions

77

c ISO/IEC

N3337

4.1
1

Lvalue-to-rvalue conversion
53

[conv.lval]

2

3

A glvalue (3.10) of a non-function, non-array type T can be converted to a prvalue. If T is an incomplete type, a program that necessitates this conversion is ill-formed. If the object to which the glvalue refers is not an object of type T and is not an object of a type derived from T, or if the object is uninitialized, a program that necessitates this conversion has undeﬁned behavior. If T is a non-class type, the type of the prvalue is the cv-unqualiﬁed version of T. Otherwise, the type of the prvalue is T.54 When an lvalue-to-rvalue conversion occurs in an unevaluated operand or a subexpression thereof (Clause 5) the value contained in the referenced object is not accessed. Otherwise, if the glvalue has a class type, the conversion copy-initializes a temporary of type T from the glvalue and the result of the conversion is a prvalue for the temporary. Otherwise, if the glvalue has (possibly cv-qualiﬁed) type std::nullptr_t, the prvalue result is a null pointer constant (4.10). Otherwise, the value contained in the object indicated by the glvalue is the prvalue result. [ Note: See also 3.10. — end note ]

4.2
1

Array-to-pointer conversion

[conv.array]

An lvalue or rvalue of type “array of N T” or “array of unknown bound of T” can be converted to a prvalue of type “pointer to T”. The result is a pointer to the ﬁrst element of the array.

4.3
1

Function-to-pointer conversion

[conv.func]

2

An lvalue of function type T can be converted to a prvalue of type “pointer to T.” The result is a pointer to the function.55 [ Note: See 13.4 for additional rules for the case where the function is overloaded. — end note ]

4.4
1

Qualiﬁcation conversions

[conv.qual]

2

3

4

A prvalue of type “pointer to cv1 T” can be converted to a prvalue of type “pointer to cv2 T” if “cv2 T” is more cv-qualiﬁed than “cv1 T”. A prvalue of type “pointer to member of X of type cv1 T” can be converted to a prvalue of type “pointer to member of X of type cv2 T” if “cv2 T” is more cv-qualiﬁed than “cv1 T”. [ Note: Function types (including those used in pointer to member function types) are never cv-qualiﬁed (8.3.5). — end note ] A conversion can add cv-qualiﬁers at levels other than the ﬁrst in multi-level pointers, subject to the following rules:56 Two pointer types T1 and T2 are similar if there exists a type T and integer n > 0 such that: T1 is cv 1,0 pointer to cv 1,1 pointer to · · · cv 1,n−1 pointer to cv 1,n T and T2 is cv 2,0 pointer to cv 2,1 pointer to · · · cv 2,n−1 pointer to cv 2,n T where each cv i,j is const, volatile, const volatile, or nothing. The n-tuple of cv-qualiﬁers after the ﬁrst in a pointer type, e.g., cv 1,1 , cv 1,2 , · · · , cv 1,n in the pointer type T1 , is called the cv-qualiﬁcation signature of the pointer type. An expression of type T1 can be converted to type T2 if and only if the following conditions are satisﬁed: — the pointer types are similar. — for every j > 0, if const is in cv 1,j then const is in cv 2,j , and similarly for volatile.
53) For historical reasons, this conversion is called the “lvalue-to-rvalue” conversion, even though that name does not accurately reﬂect the taxonomy of expressions described in 3.10. 54) In C++ class prvalues can have cv-qualiﬁed types (because they are objects). This diﬀers from ISO C, in which non-lvalues never have cv-qualiﬁed types. 55) This conversion never applies to non-static member functions because an lvalue that refers to a non-static member function cannot be obtained. 56) These rules ensure that const-safety is preserved by the conversion.

§ 4.4

78

c ISO/IEC

N3337

— if the cv 1,j and cv 2,j are diﬀerent, then const is in every cv 2,k for 0 < k < j. [ Note: if a program could assign a pointer of type T** to a pointer of type const T** (that is, if line #1 below were allowed), a program could inadvertently modify a const object (as it is done on line #2). For example, int main() { const char c = ’c’; char* pc; const char** pcc = &pc; *pcc = &c; *pc = ’C’; }
5

// #1: not allowed // #2: modiﬁes a const object

— end note ] A multi-level pointer to member type, or a multi-level mixed pointer and pointer to member type has the form: cv 0 P0 to cv 1 P1 to · · · cv n−1 Pn−1 to cv n T where Pi is either a pointer or pointer to member and where T is not a pointer type or pointer to member type. Two multi-level pointer to member types or two multi-level mixed pointer and pointer to member types T1 and T2 are similar if there exists a type T and integer n > 0 such that: T1 is cv 1,0 P0 to cv 1,1 P1 to · · · cv 1,n−1 Pn−1 to cv 1,n T and T2 is cv 2,0 P0 to cv 2,1 P1 to · · · cv 2,n−1 Pn−1 to cv 2,n T

6

7

For similar multi-level pointer to member types and similar multi-level mixed pointer and pointer to member types, the rules for adding cv-qualiﬁers are the same as those used for similar pointer types.

4.5
1

Integral promotions

[conv.prom]

2

3

4

A prvalue of an integer type other than bool, char16_t, char32_t, or wchar_t whose integer conversion rank (4.13) is less than the rank of int can be converted to a prvalue of type int if int can represent all the values of the source type; otherwise, the source prvalue can be converted to a prvalue of type unsigned int. A prvalue of type char16_t, char32_t, or wchar_t (3.9.1) can be converted to a prvalue of the ﬁrst of the following types that can represent all the values of its underlying type: int, unsigned int, long int, unsigned long int, long long int, or unsigned long long int. If none of the types in that list can represent all the values of its underlying type, a prvalue of type char16_t, char32_t, or wchar_t can be converted to a prvalue of its underlying type. A prvalue of an unscoped enumeration type whose underlying type is not ﬁxed (7.2) can be converted to a prvalue of the ﬁrst of the following types that can represent all the values of the enumeration (i.e., the values in the range bmin to bmax as described in 7.2): int, unsigned int, long int, unsigned long int, long long int, or unsigned long long int. If none of the types in that list can represent all the values of the enumeration, a prvalue of an unscoped enumeration type can be converted to a prvalue of the extended integer type with lowest integer conversion rank (4.13) greater than the rank of long long in which all the values of the enumeration can be represented. If there are two such extended types, the signed one is chosen. A prvalue of an unscoped enumeration type whose underlying type is ﬁxed (7.2) can be converted to a prvalue of its underlying type. Moreover, if integral promotion can be applied to its underlying type, a § 4.5 79

c ISO/IEC

N3337

5

6

7

prvalue of an unscoped enumeration type whose underlying type is ﬁxed can also be converted to a prvalue of the promoted underlying type. A prvalue for an integral bit-ﬁeld (9.6) can be converted to a prvalue of type int if int can represent all the values of the bit-ﬁeld; otherwise, it can be converted to unsigned int if unsigned int can represent all the values of the bit-ﬁeld. If the bit-ﬁeld is larger yet, no integral promotion applies to it. If the bit-ﬁeld has an enumerated type, it is treated as any other value of that type for promotion purposes. A prvalue of type bool can be converted to a prvalue of type int, with false becoming zero and true becoming one. These conversions are called integral promotions.

4.6
1 2

Floating point promotion

[conv.fpprom]

A prvalue of type float can be converted to a prvalue of type double. The value is unchanged. This conversion is called ﬂoating point promotion.

4.7
1

Integral conversions

[conv.integral]

2

3

4

5

A prvalue of an integer type can be converted to a prvalue of another integer type. A prvalue of an unscoped enumeration type can be converted to a prvalue of an integer type. If the destination type is unsigned, the resulting value is the least unsigned integer congruent to the source integer (modulo 2n where n is the number of bits used to represent the unsigned type). [ Note: In a two’s complement representation, this conversion is conceptual and there is no change in the bit pattern (if there is no truncation). — end note ] If the destination type is signed, the value is unchanged if it can be represented in the destination type (and bit-ﬁeld width); otherwise, the value is implementation-deﬁned. If the destination type is bool, see 4.12. If the source type is bool, the value false is converted to zero and the value true is converted to one. The conversions allowed as integral promotions are excluded from the set of integral conversions.

4.8
1

Floating point conversions

[conv.double]

2

A prvalue of ﬂoating point type can be converted to a prvalue of another ﬂoating point type. If the source value can be exactly represented in the destination type, the result of the conversion is that exact representation. If the source value is between two adjacent destination values, the result of the conversion is an implementation-deﬁned choice of either of those values. Otherwise, the behavior is undeﬁned. The conversions allowed as ﬂoating point promotions are excluded from the set of ﬂoating point conversions.

4.9
1

Floating-integral conversions

[conv.fpint]

2

A prvalue of a ﬂoating point type can be converted to a prvalue of an integer type. The conversion truncates; that is, the fractional part is discarded. The behavior is undeﬁned if the truncated value cannot be represented in the destination type. [ Note: If the destination type is bool, see 4.12. — end note ] A prvalue of an integer type or of an unscoped enumeration type can be converted to a prvalue of a ﬂoating point type. The result is exact if possible. If the value being converted is in the range of values that can be represented but the value cannot be represented exactly, it is an implementation-deﬁned choice of either the next lower or higher representable value. [ Note: Loss of precision occurs if the integral value cannot be represented exactly as a value of the ﬂoating type. — end note ] If the value being converted is outside the range of values that can be represented, the behavior is undeﬁned. If the source type is bool, the value false is converted to zero and the value true is converted to one.

4.10
1

Pointer conversions

[conv.ptr]

A null pointer constant is an integral constant expression (5.19) prvalue of integer type that evaluates to zero or a prvalue of type std::nullptr_t. A null pointer constant can be converted to a pointer type; the result is the null pointer value of that type and is distinguishable from every other value of object pointer or function pointer type. Such a conversion is called a null pointer conversion. Two null pointer values of the same type shall compare equal. The conversion of a null pointer constant to a pointer to cv-qualiﬁed type is a single conversion, and not the sequence of a pointer conversion followed by a qualiﬁcation conversion (4.4).

§ 4.10

80

c ISO/IEC

N3337

2

3

A null pointer constant of integral type can be converted to a prvalue of type std::nullptr_t. [ Note: The resulting prvalue is not a null pointer value. — end note ] A prvalue of type “pointer to cv T,” where T is an object type, can be converted to a prvalue of type “pointer to cv void”. The result of converting a “pointer to cv T” to a “pointer to cv void” points to the start of the storage location where the object of type T resides, as if the object is a most derived object (1.8) of type T (that is, not a base class subobject). The null pointer value is converted to the null pointer value of the destination type. A prvalue of type “pointer to cv D”, where D is a class type, can be converted to a prvalue of type “pointer to cv B”, where B is a base class (Clause 10) of D. If B is an inaccessible (Clause 11) or ambiguous (10.2) base class of D, a program that necessitates this conversion is ill-formed. The result of the conversion is a pointer to the base class subobject of the derived class object. The null pointer value is converted to the null pointer value of the destination type.

4.11
1

Pointer to member conversions

[conv.mem]

2

A null pointer constant (4.10) can be converted to a pointer to member type; the result is the null member pointer value of that type and is distinguishable from any pointer to member not created from a null pointer constant. Such a conversion is called a null member pointer conversion. Two null member pointer values of the same type shall compare equal. The conversion of a null pointer constant to a pointer to member of cv-qualiﬁed type is a single conversion, and not the sequence of a pointer to member conversion followed by a qualiﬁcation conversion (4.4). A prvalue of type “pointer to member of B of type cv T”, where B is a class type, can be converted to a prvalue of type “pointer to member of D of type cv T”, where D is a derived class (Clause 10) of B. If B is an inaccessible (Clause 11), ambiguous (10.2), or virtual (10.1) base class of D, or a base class of a virtual base class of D, a program that necessitates this conversion is ill-formed. The result of the conversion refers to the same member as the pointer to member before the conversion took place, but it refers to the base class member as if it were a member of the derived class. The result refers to the member in D’s instance of B. Since the result has type “pointer to member of D of type cv T”, it can be dereferenced with a D object. The result is the same as if the pointer to member of B were dereferenced with the B subobject of D. The null member pointer value is converted to the null member pointer value of the destination type.57

4.12
1

Boolean conversions

[conv.bool]

A prvalue of arithmetic, unscoped enumeration, pointer, or pointer to member type can be converted to a prvalue of type bool. A zero value, null pointer value, or null member pointer value is converted to false; any other value is converted to true. A prvalue of type std::nullptr_t can be converted to a prvalue of type bool; the resulting value is false.

4.13
1

Integer conversion rank

[conv.rank]

Every integer type has an integer conversion rank deﬁned as follows: — No two signed integer types other than char and signed char (if char is signed) shall have the same rank, even if they have the same representation. — The rank of a signed integer type shall be greater than the rank of any signed integer type with a smaller size. — The rank of long long int shall be greater than the rank of long int, which shall be greater than the rank of int, which shall be greater than the rank of short int, which shall be greater than the rank of signed char. — The rank of any unsigned integer type shall equal the rank of the corresponding signed integer type.
57) The rule for conversion of pointers to members (from pointer to member of base to pointer to member of derived) appears inverted compared to the rule for pointers to objects (from pointer to derived to pointer to base) (4.10, Clause 10). This inversion is necessary to ensure type safety. Note that a pointer to member is not an object pointer or a function pointer and the rules for conversions of such pointers do not apply to pointers to members. In particular, a pointer to member cannot be converted to a void*.

§ 4.13

81

c ISO/IEC

N3337

— The rank of any standard integer type shall be greater than the rank of any extended integer type with the same size. — The rank of char shall equal the rank of signed char and unsigned char. — The rank of bool shall be less than the rank of all other standard integer types. — The ranks of char16_t, char32_t, and wchar_t shall equal the ranks of their underlying types (3.9.1). — The rank of any extended signed integer type relative to another extended signed integer type with the same size is implementation-deﬁned, but still subject to the other rules for determining the integer conversion rank. — For all integer types T1, T2, and T3, if T1 has greater rank than T2 and T2 has greater rank than T3, then T1 shall have greater rank than T3. [ Note: The integer conversion rank is used in the deﬁnition of the integral promotions (4.5) and the usual arithmetic conversions (Clause 5). — end note ]

§ 4.13

82

c ISO/IEC

N3337

5
1 2

Expressions

[expr]

3

4

5

6

[ Note: Clause 5 deﬁnes the syntax, order of evaluation, and meaning of expressions.58 An expression is a sequence of operators and operands that speciﬁes a computation. An expression can result in a value and can cause side eﬀects. — end note ] [ Note: Operators can be overloaded, that is, given meaning when applied to expressions of class type (Clause 9) or enumeration type (7.2). Uses of overloaded operators are transformed into function calls as described in 13.5. Overloaded operators obey the rules for syntax speciﬁed in Clause 5, but the requirements of operand type, value category, and evaluation order are replaced by the rules for function call. Relations between operators, such as ++a meaning a+=1, are not guaranteed for overloaded operators (13.5), and are not guaranteed for operands of type bool. — end note ] Clause 5 deﬁnes the eﬀects of operators when applied to types for which they have not been overloaded. Operator overloading shall not modify the rules for the built-in operators, that is, for operators applied to types for which they are deﬁned by this Standard. However, these built-in operators participate in overload resolution, and as part of that process user-deﬁned conversions will be considered where necessary to convert the operands to types appropriate for the built-in operator. If a built-in operator is selected, such conversions will be applied to the operands before the operation is considered further according to the rules in Clause 5; see 13.3.1.2, 13.6. If during the evaluation of an expression, the result is not mathematically deﬁned or not in the range of representable values for its type, the behavior is undeﬁned. [ Note: most existing implementations of C++ ignore integer overﬂows. Treatment of division by zero, forming a remainder using a zero divisor, and all ﬂoating point exceptions vary among machines, and is usually adjustable by a library function. — end note ] If an expression initially has the type “reference to T” (8.3.2, 8.5.3), the type is adjusted to T prior to any further analysis. The expression designates the object or function denoted by the reference, and the expression is an lvalue or an xvalue, depending on the expression. [ Note: An expression is an xvalue if it is: — the result of calling a function, whether implicitly or explicitly, whose return type is an rvalue reference to object type, — a cast to an rvalue reference to object type, — a class member access expression designating a non-static data member of non-reference type in which the object expression is an xvalue, or — a .* pointer-to-member expression in which the ﬁrst operand is an xvalue and the second operand is a pointer to data member. In general, the eﬀect of this rule is that named rvalue references are treated as lvalues and unnamed rvalue references to objects are treated as xvalues; rvalue references to functions are treated as lvalues whether named or not. — end note ] [ Example: struct A { int m; }; A&& operator+(A, A); A&& f();
58) The precedence of operators is not directly speciﬁed, but it can be derived from the syntax.

Expressions

83

c ISO/IEC

N3337

A a; A&& ar = static_cast(a);

7

8

9

The expressions f(), f().m, static_cast(a), and a + a are xvalues. The expression ar is an lvalue. — end example ] In some contexts, unevaluated operands appear (5.2.8, 5.3.3, 5.3.7, 7.1.6.2). An unevaluated operand is not evaluated. [ Note: In an unevaluated operand, a non-static class member may be named (5.1) and naming of objects or functions does not, by itself, require that a deﬁnition be provided (3.2). — end note ] Whenever a glvalue expression appears as an operand of an operator that expects a prvalue for that operand, the lvalue-to-rvalue (4.1), array-to-pointer (4.2), or function-to-pointer (4.3) standard conversions are applied to convert the expression to a prvalue. [ Note: because cv-qualiﬁers are removed from the type of an expression of non-class type when the expression is converted to a prvalue, an lvalue expression of type const int can, for example, be used where a prvalue expression of type int is required. — end note ] Many binary operators that expect operands of arithmetic or enumeration type cause conversions and yield result types in a similar way. The purpose is to yield a common type, which is also the type of the result. This pattern is called the usual arithmetic conversions, which are deﬁned as follows: — If either operand is of scoped enumeration type (7.2), no conversions are performed; if the other operand does not have the same type, the expression is ill-formed. — If either operand is of type long double, the other shall be converted to long double. — Otherwise, if either operand is double, the other shall be converted to double. — Otherwise, if either operand is float, the other shall be converted to float. — Otherwise, the integral promotions (4.5) shall be performed on both operands.59 Then the following rules shall be applied to the promoted operands: — If both operands have the same type, no further conversion is needed. — Otherwise, if both operands have signed integer types or both have unsigned integer types, the operand with the type of lesser integer conversion rank shall be converted to the type of the operand with greater rank. — Otherwise, if the operand that has unsigned integer type has rank greater than or equal to the rank of the type of the other operand, the operand with signed integer type shall be converted to the type of the operand with unsigned integer type. — Otherwise, if the type of the operand with signed integer type can represent all of the values of the type of the operand with unsigned integer type, the operand with unsigned integer type shall be converted to the type of the operand with signed integer type. — Otherwise, both operands shall be converted to the unsigned integer type corresponding to the type of the operand with signed integer type.

10

In some contexts, an expression only appears for its side eﬀects. Such an expression is called a discarded-value expression. The expression is evaluated and its value is discarded. The array-to-pointer (4.2) and functionto-pointer (4.3) standard conversions are not applied. The lvalue-to-rvalue conversion (4.1) is applied only if the expression is an lvalue of volatile-qualiﬁed type and it has one of the following forms: — id-expression (5.1.1), — subscripting (5.2.1),
59) As a consequence, operands of type bool, char16_t, char32_t, wchar_t, or an enumerated type are converted to some integral type.

Expressions

84

c ISO/IEC

N3337

— class member access (5.2.5), — indirection (5.3.1), — pointer-to-member operation (5.5), — conditional expression (5.16) where both the second and the third operands are one of the above, or — comma expression (5.18) where the right operand is one of the above.
11

The values of the ﬂoating operands and the results of ﬂoating expressions may be represented in greater precision and range than that required by the type; the types are not changed thereby.60

5.1 5.1.1

Primary expressions General primary-expression: literal this ( expression ) id-expression lambda-expression id-expression: unqualiﬁed-id qualiﬁed-id unqualiﬁed-id: identiﬁer operator-function-id conversion-function-id literal-operator-id ~ class-name ~ decltype-speciﬁer template-id

[expr.prim] [expr.prim.general]

1

2

3

A literal is a primary expression. Its type depends on its form (2.14). A string literal is an lvalue; all other literals are prvalues. The keyword this names a pointer to the object for which a non-static member function (9.3.2) is invoked or a non-static data member’s initializer (9.2) is evaluated. If a declaration declares a member function or member function template of a class X, the expression this is a prvalue of type “pointer to cv-qualiﬁer-seq X” between the optional cv-qualifer-seq and the end of the function-deﬁnition, member-declarator, or declarator. It shall not appear before the optional cv-qualiﬁer-seq and it shall not appear within the declaration of a static member function (although its type and value category are deﬁned within a static member function as they are within a non-static member function). [ Note: this is because declaration matching does not occur until the complete declarator is known. — end note ] Unlike the object expression in other contexts, *this is not required to be of complete type for purposes of class member access (5.2.5) outside the member function body. [ Note: only class members declared prior to the declaration are visible. — end note ] [ Example: struct A { char g(); template auto f(T t) -> decltype(t + g()) { return t + g(); } }; template auto A::f(int t) -> decltype(t + g());
60) The cast and assignment operators must still perform their speciﬁc conversions as described in 5.4, 5.2.9 and 5.17.

§ 5.1.1

85

c ISO/IEC

N3337

4

5

— end example ] Otherwise, if a member-declarator declares a non-static data member (9.2) of a class X, the expression this is a prvalue of type “pointer to X” within the optional brace-or-equal-initializer. It shall not appear elsewhere in the member-declarator. The expression this shall not appear in any other context. [ Example: class Outer { int a[sizeof(*this)]; unsigned int sz = sizeof(*this); void f() { int b[sizeof(*this)]; struct Inner { int c[sizeof(*this)]; }; } }; // error: not inside a member function // OK: in brace-or-equal-initializer

// OK

// error: not inside a member function of Inner

6

7

8

— end example ] A parenthesized expression is a primary expression whose type and value are identical to those of the enclosed expression. The presence of parentheses does not aﬀect whether the expression is an lvalue. The parenthesized expression can be used in exactly the same contexts as those where the enclosed expression can be used, and with the same meaning, except as otherwise indicated. An id-expression is a restricted form of a primary-expression. [ Note: an id-expression can appear after . and -> operators (5.2.5). — end note ] An identiﬁer is an id-expression provided it has been suitably declared (Clause 7). [ Note: for operatorfunction-ids, see 13.5; for conversion-function-ids, see 12.3.2; for literal-operator-ids, see 13.5.8; for templateids, see 14.2. A class-name or decltype-speciﬁer preﬁxed by ~ denotes a destructor; see 12.4. Within the deﬁnition of a non-static member function, an identiﬁer that names a non-static member is transformed to a class member access expression (9.3.1). — end note ] The type of the expression is the type of the identiﬁer. The result is the entity denoted by the identiﬁer. The result is an lvalue if the entity is a function, variable, or data member and a prvalue otherwise.

§ 5.1.1

86

c ISO/IEC

N3337

qualiﬁed-id: nested-name-speciﬁer templateopt unqualiﬁed-id :: identiﬁer :: operator-function-id :: literal-operator-id :: template-id nested-name-speciﬁer: ::opt type-name :: ::opt namespace-name :: decltype-speciﬁer :: nested-name-speciﬁer identiﬁer :: nested-name-speciﬁer templateopt simple-template-id ::

9

10

11

12

A nested-name-speciﬁer that denotes a class, optionally followed by the keyword template (14.2), and then followed by the name of a member of either that class (9.2) or one of its base classes (Clause 10), is a qualiﬁed-id; 3.4.3.1 describes name lookup for class members that appear in qualiﬁed-ids. The result is the member. The type of the result is the type of the member. The result is an lvalue if the member is a static member function or a data member and a prvalue otherwise. [ Note: a class member can be referred to using a qualiﬁed-id at any point in its potential scope (3.3.7). — end note ] Where class-name :: class-name is used, and the two class-names refer to the same class, this notation names the constructor (12.1). Where class-name ::~ class-name is used, the two class-names shall refer to the same class; this notation names the destructor (12.4). The form ~ decltype-speciﬁer also denotes the destructor, but it shall not be used as the unqualiﬁed-id in a qualiﬁed-id. [ Note: a typedef-name that names a class is a class-name (9.1). — end note ] A ::, or a nested-name-speciﬁer that names a namespace (7.3), in either case followed by the name of a member of that namespace (or the name of a member of a namespace made visible by a using-directive) is a qualiﬁed-id; 3.4.3.2 describes name lookup for namespace members that appear in qualiﬁed-ids. The result is the member. The type of the result is the type of the member. The result is an lvalue if the member is a function or a variable and a prvalue otherwise. A nested-name-speciﬁer that denotes an enumeration (7.2), followed by the name of an enumerator of that enumeration, is a qualiﬁed-id that refers to the enumerator. The result is the enumerator. The type of the result is the type of the enumeration. The result is a prvalue. In a qualiﬁed-id, if the unqualiﬁed-id is a conversion-function-id, its conversion-type-id shall denote the same type in both the context in which the entire qualiﬁed-id occurs and in the context of the class denoted by the nested-name-speciﬁer. An id-expression that denotes a non-static data member or non-static member function of a class can only be used: — as part of a class member access (5.2.5) in which the object expression refers to the member’s class61 or a class derived from that class, or — to form a pointer to member (5.3.1), or — in a mem-initializer for a constructor for that class or for a class derived from that class (12.6.2), or — in a brace-or-equal-initializer for a non-static data member of that class or of a class derived from that class (12.6.2), or — if that id-expression denotes a non-static data member and it appears in an unevaluated operand. [ Example: struct S { int m;
61) This also applies when the object expression is an implicit (*this) (9.3.1).

§ 5.1.1

87

c ISO/IEC

N3337

}; int i = sizeof(S::m); int j = sizeof(S::m + 42);

// OK // OK

— end example ]

5.1.2
1

Lambda expressions

[expr.prim.lambda]

Lambda expressions provide a concise way to create simple function objects. [ Example:
#include #include void abssort(float *x, unsigned N) { std::sort(x, x + N, [](float a, float b) { return std::abs(a) < std::abs(b); }); }

— end example ] lambda-expression: lambda-introducer lambda-declaratoropt compound-statement lambda-introducer: [ lambda-captureopt ] lambda-capture: capture-default capture-list capture-default , capture-list capture-default: & = capture-list: capture ...opt capture-list , capture ...opt capture: identiﬁer & identiﬁer this lambda-declarator: ( parameter-declaration-clause ) mutableopt exception-speciﬁcationopt attribute-speciﬁer-seqopt trailing-return-typeopt
2

3

The evaluation of a lambda-expression results in a prvalue temporary (12.2). This temporary is called the closure object. A lambda-expression shall not appear in an unevaluated operand (Clause 5). [ Note: A closure object behaves like a function object (20.8). — end note ] The type of the lambda-expression (which is also the type of the closure object) is a unique, unnamed nonunion class type — called the closure type — whose properties are described below. This class type is not an aggregate (8.5.1). The closure type is declared in the smallest block scope, class scope, or namespace scope that contains the corresponding lambda-expression. [ Note: This determines the set of namespaces and classes associated with the closure type (3.4.2). The parameter types of a lambda-declarator do not aﬀect these associated namespaces and classes. — end note ] An implementation may deﬁne the closure type diﬀerently from what is described below provided this does not alter the observable behavior of the program other than by changing: — the size and/or alignment of the closure type, — whether the closure type is trivially copyable (Clause 9), § 5.1.2 88

c ISO/IEC

N3337

— whether the closure type is a standard-layout class (Clause 9), or — whether the closure type is a POD class (Clause 9).
4

An implementation shall not add members of rvalue reference type to the closure type. If a lambda-expression does not include a lambda-declarator, it is as if the lambda-declarator were (). If a lambda-expression does not include a trailing-return-type, it is as if the trailing-return-type denotes the following type: — if the compound-statement is of the form
{ attribute-speciﬁer-seqopt return expression ; }

the type of the returned expression after lvalue-to-rvalue conversion (4.1), array-to-pointer conversion (4.2), and function-to-pointer conversion (4.3); — otherwise, void. [ Example: auto x1 = [](int i){ return i; }; // OK: return type is int auto x2 = []{ return { 1, 2 }; }; // error: the return type is void (a // braced-init-list is not an expression)
5

6

7

— end example ] The closure type for a lambda-expression has a public inline function call operator (13.5.4) whose parameters and return type are described by the lambda-expression’s parameter-declaration-clause and trailingreturn-type respectively. This function call operator is declared const (9.3.1) if and only if the lambdaexpression’s parameter-declaration-clause is not followed by mutable. It is neither virtual nor declared volatile. Default arguments (8.3.6) shall not be speciﬁed in the parameter-declaration-clause of a lambdadeclarator. Any exception-speciﬁcation speciﬁed on a lambda-expression applies to the corresponding function call operator. An attribute-speciﬁer-seq in a lambda-declarator appertains to the type of the corresponding function call operator. [ Note: Names referenced in the lambda-declarator are looked up in the context in which the lambda-expression appears. — end note ] The closure type for a lambda-expression with no lambda-capture has a public non-virtual non-explicit const conversion function to pointer to function having the same parameter and return types as the closure type’s function call operator. The value returned by this conversion function shall be the address of a function that, when invoked, has the same eﬀect as invoking the closure type’s function call operator. The lambda-expression’s compound-statement yields the function-body (8.4) of the function call operator, but for purposes of name lookup (3.4), determining the type and value of this (9.3.2) and transforming idexpressions referring to non-static class members into class member access expressions using (*this) (9.3.1), the compound-statement is considered in the context of the lambda-expression. [ Example: struct S1 { int x, y; int operator()(int); void f() { [=]()->int { return operator()(this->x + y); // equivalent to S1::operator()(this->x + (*this).y) // this has type S1* }; } };

8

— end example ] If a lambda-capture includes a capture-default that is &, the identiﬁers in the lambda-capture shall not be preceded by &. If a lambda-capture includes a capture-default that is =, the lambda-capture shall not contain § 5.1.2 89

c ISO/IEC

N3337

this and each identiﬁer it contains shall be preceded by &. An identiﬁer or this shall not appear more than once in a lambda-capture. [ Example: struct S2 { void f(int i); }; void S2::f(int i) { [&, i]{ }; // OK [&, &i]{ }; // error: i preceded by & when & is the default [=, this]{ }; // error: this when = is the default [i, i]{ }; // error: i repeated }
9

10

11

12

— end example ] A lambda-expression whose smallest enclosing scope is a block scope (3.3.3) is a local lambda expression; any other lambda-expression shall not have a capture-list in its lambda-introducer. The reaching scope of a local lambda expression is the set of enclosing scopes up to and including the innermost enclosing function and its parameters. [ Note: This reaching scope includes any intervening lambda-expressions. — end note ] The identiﬁers in a capture-list are looked up using the usual rules for unqualiﬁed name lookup (3.4.1); each such lookup shall ﬁnd a variable with automatic storage duration declared in the reaching scope of the local lambda expression. An entity (i.e. a variable or this) is said to be explicitly captured if it appears in the lambda-expression’s capture-list. If a lambda-expression has an associated capture-default and its compound-statement odr-uses (3.2) this or a variable with automatic storage duration and the odr-used entity is not explicitly captured, then the odr-used entity is said to be implicitly captured; such entities shall be declared within the reaching scope of the lambda expression. [ Note: The implicit capture of an entity by a nested lambda-expression can cause its implicit capture by the containing lambda-expression (see below). Implicit odr-uses of this can result in implicit capture. — end note ] An entity is captured if it is captured explicitly or implicitly. An entity captured by a lambda-expression is odr-used (3.2) in the scope containing the lambda-expression. If this is captured by a local lambda expression, its nearest enclosing function shall be a non-static member function. If a lambda-expression odr-uses (3.2) this or a variable with automatic storage duration from its reaching scope, that entity shall be captured by the lambda-expression. If a lambda-expression captures an entity and that entity is not deﬁned or captured in the immediately enclosing lambda expression or function, the program is ill-formed. [ Example: void f1(int i) { int const N = 20; auto m1 = [=]{ int const M = 30; auto m2 = [i]{ int x[N][M]; x[0][0] = i; }; }; struct s1 { int f; void work(int n) { int m = n*n; int j = 40; auto m3 = [this,m] { auto m4 = [&,j] { int x = n; x += m;

// OK: N and M are not odr-used // OK: i is explicitly captured by m2 // and implicitly captured by m1

// // // // //

error: j not captured by m3 error: n implicitly captured by m4 but not captured by m3 OK: m implicitly captured by m4 and explicitly captured by m3

§ 5.1.2

90

c ISO/IEC

N3337

x += i; x += f; }; }; } }; }
13

// error: i is outside of the reaching scope // OK: this captured implicitly by m4 // and explicitly by m3

— end example ] A lambda-expression appearing in a default argument shall not implicitly or explicitly capture any entity. [ Example: void f2() { int i = 1; void g1(int void g2(int void g3(int void g4(int void g5(int }

= = = = =

([i]{ return i; })()); ([i]{ return 0; })()); ([=]{ return i; })()); ([=]{ return 0; })()); ([]{ return sizeof i; })());

// // // // //

ill-formed ill-formed ill-formed OK OK

14

15

16

— end example ] An entity is captured by copy if it is implicitly captured and the capture-default is = or if it is explicitly captured with a capture that does not include an &. For each entity captured by copy, an unnamed nonstatic data member is declared in the closure type. The declaration order of these members is unspeciﬁed. The type of such a data member is the type of the corresponding captured entity if the entity is not a reference to an object, or the referenced type otherwise. [ Note: If the captured entity is a reference to a function, the corresponding data member is also a reference to a function. — end note ] An entity is captured by reference if it is implicitly or explicitly captured but not captured by copy. It is unspeciﬁed whether additional unnamed non-static data members are declared in the closure type for entities captured by reference. If a lambda-expression m2 captures an entity and that entity is captured by an immediately enclosing lambdaexpression m1, then m2’s capture is transformed as follows: — if m1 captures the entity by copy, m2 captures the corresponding non-static data member of m1’s closure type; — if m1 captures the entity by reference, m2 captures the same entity captured by m1. [ Example: the nested lambda expressions and invocations below will output 123234. int a = 1, b = 1, c = 1; auto m1 = [a, &b, &c]() mutable { auto m2 = [a, b, &c]() mutable { std::cout ( expression ) typeid ( expression ) typeid ( type-id ) expression-list: initializer-list pseudo-destructor-name: nested-name-speciﬁeropt type-name :: ~ type-name nested-name-speciﬁer template simple-template-id :: ~ type-name nested-name-speciﬁeropt ~ type-name ~ decltype-speciﬁer [ Note: The > token following the type-id in a dynamic_cast, static_cast, reinterpret_cast, or const_-

2

cast may be the product of replacing a >> token by two consecutive > tokens (14.2). — end note ]

5.2.1
1

Subscripting

[expr.sub]

2

A postﬁx expression followed by an expression in square brackets is a postﬁx expression. One of the expressions shall have the type “pointer to T” and the other shall have unscoped enumeration or integral type. The result is an lvalue of type “T.” The type “T” shall be a completely-deﬁned object type.62 The expression E1[E2] is identical (by deﬁnition) to *((E1)+(E2)) [ Note: see 5.3 and 5.7 for details of * and + and 8.3.4 for details of arrays. — end note ] A braced-init-list shall not be used with the built-in subscript operator.

5.2.2
1

Function call
63

[expr.call]

There are two kinds of function call: ordinary function call and member function (9.3) call. A function call is a postﬁx expression followed by parentheses containing a possibly empty, comma-separated list of expressions which constitute the arguments to the function. For an ordinary function call, the postﬁx expression shall be either an lvalue that refers to a function (in which case the function-to-pointer standard conversion (4.3) is suppressed on the postﬁx expression), or it shall have pointer to function type. Calling a
62) This is true even if the subscript operator is used in the following common idiom: &x[0]. 63) A static member function (9.4) is an ordinary function.

§ 5.2.2

93

c ISO/IEC

N3337

2

3

4

5

6

7

function through an expression whose function type has a language linkage that is diﬀerent from the language linkage of the function type of the called function’s deﬁnition is undeﬁned (7.5). For a member function call, the postﬁx expression shall be an implicit (9.3.1, 9.4) or explicit class member access (5.2.5) whose idexpression is a function member name, or a pointer-to-member expression (5.5) selecting a function member; the call is as a member of the class object referred to by the object expression. In the case of an implicit class member access, the implied object is the one pointed to by this. [ Note: a member function call of the form f() is interpreted as (*this).f() (see 9.3.1). — end note ] If a function or member function name is used, the name can be overloaded (Clause 13), in which case the appropriate function shall be selected according to the rules in 13.3. If the selected function is non-virtual, or if the id-expression in the class member access expression is a qualiﬁed-id, that function is called. Otherwise, its ﬁnal overrider (10.3) in the dynamic type of the object expression is called. [ Note: the dynamic type is the type of the object referred to by the current value of the object expression. 12.7 describes the behavior of virtual function calls when the object expression refers to an object under construction or destruction. — end note ] [ Note: If a function or member function name is used, and name lookup (3.4) does not ﬁnd a declaration of that name, the program is ill-formed. No function is implicitly declared by such a call. — end note ] If the postﬁx-expression designates a destructor (12.4), the type of the function call expression is void; otherwise, the type of the function call expression is the return type of the statically chosen function (i.e., ignoring the virtual keyword), even if the type of the function actually called is diﬀerent. This type shall be an object type, a reference type or the type void. When a function is called, each parameter (8.3.5) shall be initialized (8.5, 12.8, 12.1) with its corresponding argument. [ Note: Such initializations are indeterminately sequenced with respect to each other (1.9) — end note ] If the function is a non-static member function, the this parameter of the function (9.3.2) shall be initialized with a pointer to the object of the call, converted as if by an explicit type conversion (5.4). [ Note: There is no access or ambiguity checking on this conversion; the access checking and disambiguation are done as part of the (possibly implicit) class member access operator. See 10.2, 11.2, and 5.2.5. — end note ] When a function is called, the parameters that have object type shall have completely-deﬁned object type. [ Note: this still allows a parameter to be a pointer or reference to an incomplete class type. However, it prevents a passed-by-value parameter to have an incomplete class type. — end note ] During the initialization of a parameter, an implementation may avoid the construction of extra temporaries by combining the conversions on the associated argument and/or the construction of temporaries with the initialization of the parameter (see 12.2). The lifetime of a parameter ends when the function in which it is deﬁned returns. The initialization and destruction of each parameter occurs within the context of the calling function. [ Example: the access of the constructor, conversion functions or destructor is checked at the point of call in the calling function. If a constructor or destructor for a function parameter throws an exception, the search for a handler starts in the scope of the calling function; in particular, if the function called has a function-try-block (Clause 15) with a handler that could handle the exception, this handler is not considered. — end example ] The value of a function call is the value returned by the called function except in a virtual function call if the return type of the ﬁnal overrider is diﬀerent from the return type of the statically chosen function, the value returned from the ﬁnal overrider is converted to the return type of the statically chosen function. [ Note: a function can change the values of its non-const parameters, but these changes cannot aﬀect the values of the arguments except where a parameter is of a reference type (8.3.2); if the reference is to a const-qualiﬁed type, const_cast is required to be used to cast away the constness in order to modify the argument’s value. Where a parameter is of const reference type a temporary object is introduced if needed (7.1.6, 2.14, 2.14.5, 8.3.4, 12.2). In addition, it is possible to modify the values of nonconstant objects through pointer parameters. — end note ] A function can be declared to accept fewer arguments (by declaring default arguments (8.3.6)) or more arguments (by using the ellipsis, ..., or a function parameter pack (8.3.5)) than the number of parameters in the function deﬁnition (8.4). [ Note: this implies that, except where the ellipsis (...) or a function parameter pack is used, a parameter is available for each argument. — end note ] When there is no parameter for a given argument, the argument is passed in such a way that the receiving § 5.2.2 94

c ISO/IEC

N3337

8

9 10

11

function can obtain the value of the argument by invoking va_arg (18.10). [ Note: This paragraph does not apply to arguments passed to a function parameter pack. Function parameter packs are expanded during template instantiation (14.5.3), thus each such argument has a corresponding parameter when a function template specialization is actually called. — end note ] The lvalue-to-rvalue (4.1), array-to-pointer (4.2), and function-to-pointer (4.3) standard conversions are performed on the argument expression. An argument that has (possibly cv-qualiﬁed) type std::nullptr_t is converted to type void* (4.10). After these conversions, if the argument does not have arithmetic, enumeration, pointer, pointer to member, or class type, the program is ill-formed. Passing a potentially-evaluated argument of class type (Clause 9) having a nontrivial copy constructor, a non-trivial move constructor, or a non-trivial destructor, with no corresponding parameter, is conditionally-supported with implementation-deﬁned semantics. If the argument has integral or enumeration type that is subject to the integral promotions (4.5), or a ﬂoating point type that is subject to the ﬂoating point promotion (4.6), the value of the argument is converted to the promoted type before the call. These promotions are referred to as the default argument promotions. [ Note: The evaluations of the postﬁx expression and of the argument expressions are all unsequenced relative to one another. All side eﬀects of argument expression evaluations are sequenced before the function is entered (see 1.9). — end note ] Recursive calls are permitted, except to the function named main (3.6.1). A function call is an lvalue if the result type is an lvalue reference type or an rvalue reference to function type, an xvalue if the result type is an rvalue reference to object type, and a prvalue otherwise. If a function call is a prvalue of object type: — if the function call is either — the operand of a decltype-speciﬁer or — the right operand of a comma operator that is the operand of a decltype-speciﬁer, a temporary object is not introduced for the prvalue. The type of the prvalue may be incomplete. [ Note: as a result, storage is not allocated for the prvalue and it is not destroyed; thus, a class type is not instantiated as a result of being the type of a function call in this context. This is true regardless of whether the expression uses function call notation or operator notation (13.3.1.2). — end note ] [ Note: unlike the rule for a decltype-speciﬁer that considers whether an id-expression is parenthesized (7.1.6.2), parentheses have no special meaning in this context. — end note ] — otherwise, the type of the prvalue shall be complete.

5.2.3
1

Explicit type conversion (functional notation)

[expr.type.conv]

2

A simple-type-speciﬁer (7.1.6.2) or typename-speciﬁer (14.6) followed by a parenthesized expression-list constructs a value of the speciﬁed type given the expression list. If the expression list is a single expression, the type conversion expression is equivalent (in deﬁnedness, and if deﬁned in meaning) to the corresponding cast expression (5.4). If the type speciﬁed is a class type, the class type shall be complete. If the expression list speciﬁes more than a single value, the type shall be a class with a suitably declared constructor (8.5, 12.1), and the expression T(x1, x2, ...) is equivalent in eﬀect to the declaration T t(x1, x2, ...); for some invented temporary variable t, with the result being the value of t as a prvalue. The expression T(), where T is a simple-type-speciﬁer or typename-speciﬁer for a non-array complete object type or the (possibly cv-qualiﬁed) void type, creates a prvalue of the speciﬁed type,which is valueinitialized (8.5; no initialization is done for the void() case). [ Note: if T is a non-class type that is cv-qualiﬁed, the cv-qualiﬁers are ignored when determining the type of the resulting prvalue (3.10). — end note ]

§ 5.2.3

95

c ISO/IEC

N3337

3

Similarly, a simple-type-speciﬁer or typename-speciﬁer followed by a braced-init-list creates a temporary object of the speciﬁed type direct-list-initialized (8.5.4) with the speciﬁed braced-init-list, and its value is that temporary object as a prvalue.

5.2.4
1

Pseudo destructor call

[expr.pseudo]

2

The use of a pseudo-destructor-name after a dot . or arrow -> operator represents the destructor for the non-class type denoted by type-name or decltype-speciﬁer. The result shall only be used as the operand for the function call operator (), and the result of such a call has type void. The only eﬀect is the evaluation of the postﬁx-expression before the dot or arrow. The left-hand side of the dot operator shall be of scalar type. The left-hand side of the arrow operator shall be of pointer to scalar type. This scalar type is the object type. The cv-unqualiﬁed versions of the object type and of the type designated by the pseudo-destructor-name shall be the same type. Furthermore, the two type-names in a pseudo-destructor-name of the form nested-name-speciﬁeropt type-name :: ~ type-name

shall designate the same scalar type.

5.2.5
1

Class member access

[expr.ref]

2

3

4

A postﬁx expression followed by a dot . or an arrow ->, optionally followed by the keyword template (14.2), and then followed by an id-expression, is a postﬁx expression. The postﬁx expression before the dot or arrow is evaluated;64 the result of that evaluation, together with the id-expression, determines the result of the entire postﬁx expression. For the ﬁrst option (dot) the ﬁrst expression shall have complete class type. For the second option (arrow) the ﬁrst expression shall have pointer to complete class type. The expression E1->E2 is converted to the equivalent form (*(E1)).E2; the remainder of 5.2.5 will address only the ﬁrst option (dot).65 In either case, the id-expression shall name a member of the class or of one of its base classes. [ Note: because the name of a class is inserted in its class scope (Clause 9), the name of a class is also considered a nested member of that class. — end note ] [ Note: 3.4.5 describes how names are looked up after the . and -> operators. — end note ] Abbreviating postﬁx-expression.id-expression as E1.E2, E1 is called the object expression. The type and value category of E1.E2 are determined as follows. In the remainder of 5.2.5, cq represents either const or the absence of const and vq represents either volatile or the absence of volatile. cv represents an arbitrary set of cv-qualiﬁers, as deﬁned in 3.9.3. If E2 is declared to have type “reference to T,” then E1.E2 is an lvalue; the type of E1.E2 is T. Otherwise, one of the following rules applies. — If E2 is a static data member and the type of E2 is T, then E1.E2 is an lvalue; the expression designates the named member of the class. The type of E1.E2 is T. — If E2 is a non-static data member and the type of E1 is “cq1 vq1 X”, and the type of E2 is “cq2 vq2 T”, the expression designates the named member of the object designated by the ﬁrst expression. If E1 is an lvalue, then E1.E2 is an lvalue; if E1 is an xvalue, then E1.E2 is an xvalue; otherwise, it is a prvalue. Let the notation vq12 stand for the “union” of vq1 and vq2 ; that is, if vq1 or vq2 is volatile, then vq12 is volatile. Similarly, let the notation cq12 stand for the “union” of cq1 and cq2 ; that is, if cq1 or cq2 is const, then cq12 is const. If E2 is declared to be a mutable member, then the type of E1.E2 is “vq12 T”. If E2 is not declared to be a mutable member, then the type of E1.E2 is “cq12 vq12 T”. — If E2 is a (possibly overloaded) member function, function overload resolution (13.3) is used to determine whether E1.E2 refers to a static or a non-static member function. — If it refers to a static member function and the type of E2 is “function of parameter-type-list returning T”, then E1.E2 is an lvalue; the expression designates the static member function. The
64) If the class member access expression is evaluated, the subexpression evaluation happens even if the result is unnecessary to determine the value of the entire postﬁx expression, for example if the id-expression denotes a static member. 65) Note that (*(E1)) is an lvalue.

§ 5.2.5

96

c ISO/IEC

N3337

type of E1.E2 is the same type as that of E2, namely “function of parameter-type-list returning T”. — Otherwise, if E1.E2 refers to a non-static member function and the type of E2 is “function of parameter-type-list cv ref-qualiﬁeropt returning T”, then E1.E2 is a prvalue. The expression designates a non-static member function. The expression can be used only as the left-hand operand of a member function call (9.3). [ Note: Any redundant set of parentheses surrounding the expression is ignored (5.1). — end note ] The type of E1.E2 is “function of parameter-type-list cv returning T”. — If E2 is a nested type, the expression E1.E2 is ill-formed. — If E2 is a member enumerator and the type of E2 is T, the expression E1.E2 is a prvalue. The type of E1.E2 is T.
5

If E2 is a non-static data member or a non-static member function, the program is ill-formed if the class of which E2 is directly a member is an ambiguous base (10.2) of the naming class (11.2) of E2. [ Note: The program is also ill-formed if the naming class is an ambiguous base of the class type of the object expression; see 11.2. — end note ]

5.2.6
1

Increment and decrement

[expr.post.incr]

2

The value of a postﬁx ++ expression is the value of its operand. [ Note: the value obtained is a copy of the original value — end note ] The operand shall be a modiﬁable lvalue. The type of the operand shall be an arithmetic type or a pointer to a complete object type. The value of the operand object is modiﬁed by adding 1 to it, unless the object is of type bool, in which case it is set to true. [ Note: this use is deprecated, see Annex D. — end note ] The value computation of the ++ expression is sequenced before the modiﬁcation of the operand object. With respect to an indeterminately-sequenced function call, the operation of postﬁx ++ is a single evaluation. [ Note: Therefore, a function call shall not intervene between the lvalue-to-rvalue conversion and the side eﬀect associated with any single postﬁx ++ operator. — end note ] The result is a prvalue. The type of the result is the cv-unqualiﬁed version of the type of the operand. See also 5.7 and 5.17. The operand of postﬁx -- is decremented analogously to the postﬁx ++ operator, except that the operand shall not be of type bool. [ Note: For preﬁx increment and decrement, see 5.3.2. — end note ]

5.2.7
1

Dynamic cast

[expr.dynamic.cast]

2

3

4 5

The result of the expression dynamic_cast(v) is the result of converting the expression v to type T. T shall be a pointer or reference to a complete class type, or “pointer to cv void.” The dynamic_cast operator shall not cast away constness (5.2.11). If T is a pointer type, v shall be a prvalue of a pointer to complete class type, and the result is a prvalue of type T. If T is an lvalue reference type, v shall be an lvalue of a complete class type, and the result is an lvalue of the type referred to by T. If T is an rvalue reference type, v shall be an expression having a complete class type, and the result is an xvalue of the type referred to by T. If the type of v is the same as T, or it is the same as T except that the class object type in T is more cv-qualiﬁed than the class object type in v, the result is v (converted if necessary). If the value of v is a null pointer value in the pointer case, the result is the null pointer value of type T. If T is “pointer to cv1 B” and v has type “pointer to cv2 D” such that B is a base class of D, the result is a pointer to the unique B subobject of the D object pointed to by v. Similarly, if T is “reference to cv1 B” and v has type cv2 D such that B is a base class of D, the result is the unique B subobject of the D object referred to by v. 66 The result is an lvalue if T is an lvalue reference, or an xvalue if T is an rvalue reference. In both the pointer and reference cases, the program is ill-formed if cv2 has greater cv-qualiﬁcation than cv1 or if B is an inaccessible or ambiguous base class of D. [ Example:
66) The most derived object (1.8) pointed or referred to by v can contain other B objects as base classes, but these are ignored.

§ 5.2.7

97

c ISO/IEC

N3337

struct B { }; struct D : B { }; void foo(D* dp) { B* bp = dynamic_cast(dp); }
6 7

// equivalent to B* bp = dp;

8

— end example ] Otherwise, v shall be a pointer to or an lvalue of a polymorphic type (10.3). If T is “pointer to cv void,” then the result is a pointer to the most derived object pointed to by v. Otherwise, a run-time check is applied to see if the object pointed or referred to by v can be converted to the type pointed or referred to by T. If C is the class type to which T points or refers, the run-time check logically executes as follows: — If, in the most derived object pointed (referred) to by v, v points (refers) to a public base class subobject of a C object, and if only one object of type C is derived from the subobject pointed (referred) to by v the result points (refers) to that C object. — Otherwise, if v points (refers) to a public base class subobject of the most derived object, and the type of the most derived object has a base class, of type C, that is unambiguous and public, the result points (refers) to the C subobject of the most derived object. — Otherwise, the run-time check fails.

9

The value of a failed cast to pointer type is the null pointer value of the required result type. A failed cast to reference type throws std::bad_cast (18.7.2). [ Example: class A { virtual void f(); }; class B { virtual void g(); }; class D : public virtual A, private void g() { D d; B* bp = (B*)&d; A* ap = &d; D& dr = dynamic_cast(*bp); ap = dynamic_cast(bp); bp = dynamic_cast(ap); ap = dynamic_cast(&d); bp = dynamic_cast(&d); } class E : public D, public B { }; class F : public E, public D { }; void h() { F f; A* ap = &f; D* dp = dynamic_cast(ap); E* E* } ep = (E*)ap; ep1 = dynamic_cast(ap);

B { };

// // // // // // //

cast needed to break protection public derivation, no cast needed fails fails fails succeeds ill-formed (not a run-time check)

// // // // //

succeeds: ﬁnds unique A fails: yields 0 f has two D subobjects ill-formed: cast from virtual base succeeds

— end example ] [ Note: 12.7 describes the behavior of a dynamic_cast applied to an object under construction or destruction. — end note ]

§ 5.2.7

98

c ISO/IEC

N3337

5.2.8
1

Type identiﬁcation

[expr.typeid]

2

3

4

5

The result of a typeid expression is an lvalue of static type const std::type_info (18.7.1) and dynamic type const std::type_info or const name where name is an implementation-deﬁned class publicly derived from std :: type_info which preserves the behavior described in 18.7.1.67 The lifetime of the object referred to by the lvalue extends to the end of the program. Whether or not the destructor is called for the std::type_info object at the end of the program is unspeciﬁed. When typeid is applied to a glvalue expression whose type is a polymorphic class type (10.3), the result refers to a std::type_info object representing the type of the most derived object (1.8) (that is, the dynamic type) to which the glvalue refers. If the glvalue expression is obtained by applying the unary * operator to a pointer68 and the pointer is a null pointer value (4.10), the typeid expression throws the std::bad_typeid exception (18.7.3). When typeid is applied to an expression other than a glvalue of a polymorphic class type, the result refers to a std::type_info object representing the static type of the expression. Lvalue-to-rvalue (4.1), array-topointer (4.2), and function-to-pointer (4.3) conversions are not applied to the expression. If the type of the expression is a class type, the class shall be completely-deﬁned. The expression is an unevaluated operand (Clause 5). When typeid is applied to a type-id, the result refers to a std::type_info object representing the type of the type-id. If the type of the type-id is a reference to a possibly cv-qualiﬁed type, the result of the typeid expression refers to a std::type_info object representing the cv-unqualiﬁed referenced type. If the type of the type-id is a class type or a reference to a class type, the class shall be completely-deﬁned. The top-level cv-qualiﬁers of the glvalue expression or the type-id that is the operand of typeid are always ignored. [ Example: class D { /* ... D d1; const D d2; typeid(d1) typeid(D) typeid(D) typeid(D) == == == == */ };

typeid(d2); typeid(const D); typeid(d2); typeid(const D&);

// // // //

yields yields yields yields

true true true true

6 7

— end example ] If the header (18.7.1) is not included prior to a use of typeid, the program is ill-formed. [ Note: 12.7 describes the behavior of typeid applied to an object under construction or destruction. — end note ]

5.2.9
1

Static cast

[expr.static.cast]

2

The result of the expression static_cast(v) is the result of converting the expression v to type T. If T is an lvalue reference type or an rvalue reference to function type, the result is an lvalue; if T is an rvalue reference to object type, the result is an xvalue; otherwise, the result is a prvalue. The static_cast operator shall not cast away constness (5.2.11). An lvalue of type “cv1 B,” where B is a class type, can be cast to type “reference to cv2 D,” where D is a class derived (Clause 10) from B, if a valid standard conversion from “pointer to D” to “pointer to B” exists (4.10), cv2 is the same cv-qualiﬁcation as, or greater cv-qualiﬁcation than, cv1, and B is neither a virtual base class of D nor a base class of a virtual base class of D. The result has type “cv2 D.” An xvalue of type “cv1 B” may be cast to type “rvalue reference to cv2 D” with the same constraints as for an lvalue of type “cv1 B.” If the object of type “cv1 B” is actually a subobject of an object of type D, the result refers to the enclosing object of type D. Otherwise, the result of the cast is undeﬁned. [ Example: struct B { };
67) The recommended name for such a class is extended_type_info. 68) If p is an expression of pointer type, then *p, (*p), *(p), ((*p)), *((p)), and so on all meet this requirement.

§ 5.2.9

99

c ISO/IEC

N3337

struct D : public B { }; D d; B &br = d; static_cast(br);
3

// produces lvalue to the original d object

4

5

6

7

— end example ] A glvalue of type “cv1 T1” can be cast to type “rvalue reference to cv2 T2” if “cv2 T2” is reference-compatible with “cv1 T1” (8.5.3). The result refers to the object or the speciﬁed base class subobject thereof. If T2 is an inaccessible (Clause 11) or ambiguous (10.2) base class of T1, a program that necessitates such a cast is ill-formed. Otherwise, an expression e can be explicitly converted to a type T using a static_cast of the form static_cast(e) if the declaration T t(e); is well-formed, for some invented temporary variable t (8.5). The eﬀect of such an explicit conversion is the same as performing the declaration and initialization and then using the temporary variable as the result of the conversion. The expression e is used as a glvalue if and only if the initialization uses it as a glvalue. Otherwise, the static_cast shall perform one of the conversions listed below. No other conversion shall be performed explicitly using a static_cast. Any expression can be explicitly converted to type cv void, in which case it becomes a discarded-value expression (Clause 5). [ Note: however, if the value is in a temporary object (12.2), the destructor for that object is not executed until the usual time, and the value of the object is preserved for the purpose of executing the destructor. — end note ] The inverse of any standard conversion sequence (Clause 4) not containing an lvalue-to-rvalue (4.1), arrayto-pointer (4.2), function-to-pointer (4.3), null pointer (4.10), null member pointer (4.11), or boolean (4.12) conversion, can be performed explicitly using static_cast. A program is ill-formed if it uses static_cast to perform the inverse of an ill-formed standard conversion sequence. [ Example: struct B { }; struct D : private B { }; void f() { static_cast((B*)0); static_cast((int D::*)0); }

// Error: B is a private base of D. // Error: B is a private base of D.

8

9

10

11

— end example ] The lvalue-to-rvalue (4.1), array-to-pointer (4.2), and function-to-pointer (4.3) conversions are applied to the operand. Such a static_cast is subject to the restriction that the explicit conversion does not cast away constness (5.2.11), and the following additional rules for speciﬁc cases: A value of a scoped enumeration type (7.2) can be explicitly converted to an integral type. The value is unchanged if the original value can be represented by the speciﬁed type. Otherwise, the resulting value is unspeciﬁed. A value of a scoped enumeration type can also be explicitly converted to a ﬂoating-point type; the result is the same as that of converting from the original value to the ﬂoating-point type. A value of integral or enumeration type can be explicitly converted to an enumeration type. The value is unchanged if the original value is within the range of the enumeration values (7.2). Otherwise, the resulting value is unspeciﬁed (and might not be in that range). A value of ﬂoating-point type can also be converted to an enumeration type. The resulting value is the same as converting the original value to the underlying type of the enumeration (4.9), and subsequently to the enumeration type. A prvalue of type “pointer to cv1 B,” where B is a class type, can be converted to a prvalue of type “pointer to cv2 D,” where D is a class derived (Clause 10) from B, if a valid standard conversion from “pointer to D” to “pointer to B” exists (4.10), cv2 is the same cv-qualiﬁcation as, or greater cv-qualiﬁcation than, cv1, and B is neither a virtual base class of D nor a base class of a virtual base class of D. The null pointer value (4.10) is converted to the null pointer value of the destination type. If the prvalue of type “pointer to cv1 B” points

§ 5.2.9

100

c ISO/IEC

N3337

12

13

to a B that is actually a subobject of an object of type D, the resulting pointer points to the enclosing object of type D. Otherwise, the result of the cast is undeﬁned. A prvalue of type “pointer to member of D of type cv1 T” can be converted to a prvalue of type “pointer to member of B” of type cv2 T, where B is a base class (Clause 10) of D, if a valid standard conversion from “pointer to member of B of type T” to “pointer to member of D of type T” exists (4.11), and cv2 is the same cv-qualiﬁcation as, or greater cv-qualiﬁcation than, cv1.69 The null member pointer value (4.11) is converted to the null member pointer value of the destination type. If class B contains the original member, or is a base or derived class of the class containing the original member, the resulting pointer to member points to the original member. Otherwise, the result of the cast is undeﬁned. [ Note: although class B need not contain the original member, the dynamic type of the object on which the pointer to member is dereferenced must contain the original member; see 5.5. — end note ] A prvalue of type “pointer to cv1 void” can be converted to a prvalue of type “pointer to cv2 T,” where T is an object type and cv2 is the same cv-qualiﬁcation as, or greater cv-qualiﬁcation than, cv1. The null pointer value is converted to the null pointer value of the destination type. A value of type pointer to object converted to “pointer to cv void” and back, possibly with diﬀerent cv-qualiﬁcation, shall have its original value. [ Example:
T* p1 = new T; const T* p2 = static_cast(static_cast(p1)); bool b = p1 == p2; // b will have the value true.

— end example ]

5.2.10
1

Reinterpret cast

[expr.reinterpret.cast]

2

3

4

5

6

The result of the expression reinterpret_cast(v) is the result of converting the expression v to type T. If T is an lvalue reference type or an rvalue reference to function type, the result is an lvalue; if T is an rvalue reference to object type, the result is an xvalue; otherwise, the result is a prvalue and the lvalue-torvalue (4.1), array-to-pointer (4.2), and function-to-pointer (4.3) standard conversions are performed on the expression v. Conversions that can be performed explicitly using reinterpret_cast are listed below. No other conversion can be performed explicitly using reinterpret_cast. The reinterpret_cast operator shall not cast away constness (5.2.11). An expression of integral, enumeration, pointer, or pointer-to-member type can be explicitly converted to its own type; such a cast yields the value of its operand. [ Note: The mapping performed by reinterpret_cast might, or might not, produce a representation different from the original value. — end note ] A pointer can be explicitly converted to any integral type large enough to hold it. The mapping function is implementation-deﬁned. [ Note: It is intended to be unsurprising to those who know the addressing structure of the underlying machine. — end note ] A value of type std::nullptr_t can be converted to an integral type; the conversion has the same meaning and validity as a conversion of (void*)0 to the integral type. [ Note: A reinterpret_cast cannot be used to convert a value of any type to the type std::nullptr_t. — end note ] A value of integral type or enumeration type can be explicitly converted to a pointer. A pointer converted to an integer of suﬃcient size (if any such exists on the implementation) and back to the same pointer type will have its original value; mappings between pointers and integers are otherwise implementation-deﬁned. [ Note: Except as described in 3.7.4.3, the result of such a conversion will not be a safely-derived pointer value. — end note ] A function pointer can be explicitly converted to a function pointer of a diﬀerent type. The eﬀect of calling a function through a pointer to a function type (8.3.5) that is not the same as the type used in the deﬁnition of the function is undeﬁned. Except that converting a prvalue of type “pointer to T1” to the type “pointer to T2” (where T1 and T2 are function types) and back to its original type yields the original pointer value, the
69) Function types (including those used in pointer to member function types) are never cv-qualiﬁed; see 8.3.5.

§ 5.2.10

101

c ISO/IEC

N3337

7

8

9

10

result of such a pointer conversion is unspeciﬁed. [ Note: see also 4.10 for more details of pointer conversions. — end note ] An object pointer can be explicitly converted to an object pointer of a diﬀerent type.70 When a prvalue v of type “pointer to T1” is converted to the type “pointer to cv T2”, the result is static_cast(static_cast(v)) if both T1 and T2 are standard-layout types (3.9) and the alignment requirements of T2 are no stricter than those of T1, or if either type is void. Converting a prvalue of type “pointer to T1” to the type “pointer to T2” (where T1 and T2 are object types and where the alignment requirements of T2 are no stricter than those of T1) and back to its original type yields the original pointer value. The result of any other such pointer conversion is unspeciﬁed. Converting a function pointer to an object pointer type or vice versa is conditionally-supported. The meaning of such a conversion is implementation-deﬁned, except that if an implementation supports conversions in both directions, converting a prvalue of one type to the other type and back, possibly with diﬀerent cvqualiﬁcation, shall yield the original pointer value. The null pointer value (4.10) is converted to the null pointer value of the destination type. [ Note: A null pointer constant of type std::nullptr_t cannot be converted to a pointer type, and a null pointer constant of integral type is not necessarily converted to a null pointer value. — end note ] A prvalue of type “pointer to member of X of type T1” can be explicitly converted to a prvalue of a diﬀerent type “pointer to member of Y of type T2” if T1 and T2 are both function types or both object types.71 The null member pointer value (4.11) is converted to the null member pointer value of the destination type. The result of this conversion is unspeciﬁed, except in the following cases: — converting a prvalue of type “pointer to member function” to a diﬀerent pointer to member function type and back to its original type yields the original pointer to member value. — converting a prvalue of type “pointer to data member of X of type T1” to the type “pointer to data member of Y of type T2” (where the alignment requirements of T2 are no stricter than those of T1) and back to its original type yields the original pointer to member value.

11

An lvalue expression of type T1 can be cast to the type “reference to T2” if an expression of type “pointer to T1” can be explicitly converted to the type “pointer to T2” using a reinterpret_cast. That is, a reference cast reinterpret_cast(x) has the same eﬀect as the conversion *reinterpret_cast(&x) with the built-in & and * operators (and similarly for reinterpret_cast(x)). The result refers to the same object as the source lvalue, but with a diﬀerent type. The result is an lvalue for an lvalue reference type or an rvalue reference to function type and an xvalue for an rvalue reference to object type. No temporary is created, no copy is made, and constructors (12.1) or conversion functions (12.3) are not called.72

5.2.11
1

Const cast

[expr.const.cast]

2

3

The result of the expression const_cast(v) is of type T. If T is an lvalue reference to object type, the result is an lvalue; if T is an rvalue reference to object type, the result is an xvalue; otherwise, the result is a prvalue and the lvalue-to-rvalue (4.1), array-to-pointer (4.2), and function-to-pointer (4.3) standard conversions are performed on the expression v. Conversions that can be performed explicitly using const_cast are listed below. No other conversion shall be performed explicitly using const_cast. [ Note: Subject to the restrictions in this section, an expression may be cast to its own type using a const_cast operator. — end note ] For two pointer types T1 and T2 where T1 is cv 1,0 pointer to cv 1,1 pointer to · · · cv 1,n−1 pointer to cv 1,n T and
70) The types may have diﬀerent cv-qualiﬁers, subject to the overall restriction that a reinterpret_cast cannot cast away constness. 71) T1 and T2 may have diﬀerent cv-qualiﬁers, subject to the overall restriction that a reinterpret_cast cannot cast away constness. 72) This is sometimes referred to as a type pun.

§ 5.2.11

102

c ISO/IEC

N3337

T2 is cv 2,0 pointer to cv 2,1 pointer to · · · cv 2,n−1 pointer to cv 2,n T where T is any object type or the void type and where cv 1,k and cv 2,k may be diﬀerent cv-qualiﬁcations, a prvalue of type T1 may be explicitly converted to the type T2 using a const_cast. The result of a pointer const_cast refers to the original object. For two object types T1 and T2, if a pointer to T1 can be explicitly converted to the type “pointer to T2” using a const_cast, then the following conversions can also be made: — an lvalue of type T1 can be explicitly converted to an lvalue of type T2 using the cast const_cast; — a glvalue of type T1 can be explicitly converted to an xvalue of type T2 using the cast const_cast; and — if T1 is a class type, a prvalue of type T1 can be explicitly converted to an xvalue of type T2 using the cast const_cast. The result of a reference const_cast refers to the original object. For a const_cast involving pointers to data members, multi-level pointers to data members and multi-level mixed pointers and pointers to data members (4.4), the rules for const_cast are the same as those used for pointers; the “member” aspect of a pointer to member is ignored when determining where the cv-qualiﬁers are added or removed by the const_cast. The result of a pointer to data member const_cast refers to the same member as the original (uncast) pointer to data member. A null pointer value (4.10) is converted to the null pointer value of the destination type. The null member pointer value (4.11) is converted to the null member pointer value of the destination type. [ Note: Depending on the type of the object, a write operation through the pointer, lvalue or pointer to data member resulting from a const_cast that casts away a const-qualiﬁer73 may produce undeﬁned behavior (7.1.6.1). — end note ] The following rules deﬁne the process known as casting away constness. In these rules Tn and Xn represent types. For two pointer types: X1 is T1cv 1,1 * · · · cv 1,N * where T1 is not a pointer type X2 is T2cv 2,1 * · · · cv 2,M * where T2 is not a pointer type K is min(N, M ) casting from X1 to X2 casts away constness if, for a non-pointer type T there does not exist an implicit conversion (Clause 4) from: Tcv 1,(N −K+1) * cv 1,(N −K+2) * · · · cv 1,N * to Tcv 2,(M −K+1) * cv 2,(M −K+2) * · · · cv 2,M *
9

4

5

6

7

8

10

Casting from an lvalue of type T1 to an lvalue of type T2 using an lvalue reference cast or casting from an expression of type T1 to an xvalue of type T2 using an rvalue reference cast casts away constness if a cast from a prvalue of type “pointer to T1” to the type “pointer to T2” casts away constness. Casting from a prvalue of type “pointer to data member of X of type T1” to the type “pointer to data member of Y of type T2” casts away constness if a cast from a prvalue of type “pointer to T1” to the type “pointer to T2” casts away constness.
73) const_cast is not limited to conversions that cast away a const-qualiﬁer.

§ 5.2.11

103

c ISO/IEC

N3337

11

12

For multi-level pointer to members and multi-level mixed pointers and pointer to members (4.4), the “member” aspect of a pointer to member level is ignored when determining if a const cv-qualiﬁer has been cast away. [ Note: some conversions which involve only changes in cv-qualiﬁcation cannot be done using const_cast. For instance, conversions between pointers to functions are not covered because such conversions lead to values whose use causes undeﬁned behavior. For the same reasons, conversions between pointers to member functions, and in particular, the conversion from a pointer to a const member function to a pointer to a non-const member function, are not covered. — end note ]

5.3
1

Unary expressions unary-expression: postﬁx-expression ++ cast-expression -- cast-expression unary-operator cast-expression sizeof unary-expression sizeof ( type-id ) sizeof ... ( identiﬁer ) alignof ( type-id ) noexcept-expression new-expression delete-expression unary-operator: one of * & + - ! ~

[expr.unary]

Expressions with unary operators group right-to-left.

5.3.1
1

Unary operators

[expr.unary.op]

2 3

The unary * operator performs indirection: the expression to which it is applied shall be a pointer to an object type, or a pointer to a function type and the result is an lvalue referring to the object or function to which the expression points. If the type of the expression is “pointer to T,” the type of the result is “T.” [ Note: a pointer to an incomplete type (other than cv void) can be dereferenced. The lvalue thus obtained can be used in limited ways (to initialize a reference, for example); this lvalue must not be converted to a prvalue, see 4.1. — end note ] The result of each of the following unary operators is a prvalue. The result of the unary & operator is a pointer to its operand. The operand shall be an lvalue or a qualiﬁedid. If the operand is a qualiﬁed-id naming a non-static member m of some class C with type T, the result has type “pointer to member of class C of type T” and is a prvalue designating C::m. Otherwise, if the type of the expression is T, the result has type “pointer to T” and is a prvalue that is the address of the designated object (1.7) or a pointer to the designated function. [ Note: In particular, the address of an object of type “cv T” is “pointer to cv T”, with the same cv-qualiﬁcation. — end note ] [ Example: struct A { int i; }; struct B : A { }; ... &B::i ... // has type int A::*

4

— end example ] [ Note: a pointer to member formed from a mutable non-static data member (7.1.1) does not reﬂect the mutable speciﬁer associated with the non-static data member. — end note ] A pointer to member is only formed when an explicit & is used and its operand is a qualiﬁed-id not enclosed in parentheses. [ Note: that is, the expression &(qualified-id), where the qualiﬁed-id is enclosed in parentheses, does not form an expression of type “pointer to member.” Neither does qualified-id, because there is no implicit conversion from a qualiﬁed-id for a non-static member function to the type “pointer to member function” as there is from an lvalue of function type to the type “pointer to function” (4.3). Nor is &unqualified-id a pointer to member, even within the scope of the unqualiﬁed-id’s class. — end note ] § 5.3.1 104

c ISO/IEC

N3337

5

6

7

8

9

10

The address of an object of incomplete type can be taken, but if the complete type of that object is a class type that declares operator&() as a member function, then the behavior is undeﬁned (and no diagnostic is required). The operand of & shall not be a bit-ﬁeld. The address of an overloaded function (Clause 13) can be taken only in a context that uniquely determines which version of the overloaded function is referred to (see 13.4). [ Note: since the context might determine whether the operand is a static or non-static member function, the context can also aﬀect whether the expression has type “pointer to function” or “pointer to member function.” — end note ] The operand of the unary + operator shall have arithmetic, unscoped enumeration, or pointer type and the result is the value of the argument. Integral promotion is performed on integral or enumeration operands. The type of the result is the type of the promoted operand. The operand of the unary - operator shall have arithmetic or unscoped enumeration type and the result is the negation of its operand. Integral promotion is performed on integral or enumeration operands. The negative of an unsigned quantity is computed by subtracting its value from 2n , where n is the number of bits in the promoted operand. The type of the result is the type of the promoted operand. The operand of the logical negation operator ! is contextually converted to bool (Clause 4); its value is true if the converted operand is false and false otherwise. The type of the result is bool. The operand of ˜ shall have integral or unscoped enumeration type; the result is the one’s complement of its operand. Integral promotions are performed. The type of the result is the type of the promoted operand. There is an ambiguity in the unary-expression ˜X(), where X is a class-name or decltype-speciﬁer. The ambiguity is resolved in favor of treating ˜ as a unary complement rather than treating ˜X as referring to a destructor.

5.3.2
1

Increment and decrement

[expr.pre.incr]

2

The operand of preﬁx ++ is modiﬁed by adding 1, or set to true if it is bool (this use is deprecated). The operand shall be a modiﬁable lvalue. The type of the operand shall be an arithmetic type or a pointer to a completely-deﬁned object type. The result is the updated operand; it is an lvalue, and it is a bit-ﬁeld if the operand is a bit-ﬁeld. If x is not of type bool, the expression ++x is equivalent to x+=1 [ Note: See the discussions of addition (5.7) and assignment operators (5.17) for information on conversions. — end note ] The operand of preﬁx -- is modiﬁed by subtracting 1. The operand shall not be of type bool. The requirements on the operand of preﬁx -- and the properties of its result are otherwise the same as those of preﬁx ++. [ Note: For postﬁx increment and decrement, see 5.2.6. — end note ]

5.3.3
1

Sizeof

[expr.sizeof]

2

3

The sizeof operator yields the number of bytes in the object representation of its operand. The operand is either an expression, which is an unevaluated operand (Clause 5), or a parenthesized type-id. The sizeof operator shall not be applied to an expression that has function or incomplete type, to an enumeration type whose underlying type is not ﬁxed before all its enumerators have been declared, to the parenthesized name of such types, or to an lvalue that designates a bit-ﬁeld. sizeof(char), sizeof(signed char) and sizeof(unsigned char) are 1. The result of sizeof applied to any other fundamental type (3.9.1) is implementation-deﬁned. [ Note: in particular, sizeof(bool), sizeof(char16_t), sizeof(char32_t), and sizeof(wchar_t) are implementation-deﬁned.74 — end note ] [ Note: See 1.7 for the deﬁnition of byte and 3.9 for the deﬁnition of object representation. — end note ] When applied to a reference or a reference type, the result is the size of the referenced type. When applied to a class, the result is the number of bytes in an object of that class including any padding required for placing objects of that type in an array. The size of a most derived class shall be greater than zero (1.8). The result of applying sizeof to a base class subobject is the size of the base class type.75 When applied to an array, the result is the total number of bytes in the array. This implies that the size of an array of n elements is n times the size of an element. The sizeof operator can be applied to a pointer to a function, but shall not be applied directly to a function.
74) sizeof(bool) is not required to be 1. 75) The actual size of a base class subobject may be less than the result of applying sizeof to the subobject, due to virtual

base classes and less strict padding requirements on base class subobjects.

§ 5.3.3

105

c ISO/IEC

N3337

4

5

The lvalue-to-rvalue (4.1), array-to-pointer (4.2), and function-to-pointer (4.3) standard conversions are not applied to the operand of sizeof. The identiﬁer in a sizeof... expression shall name a parameter pack. The sizeof... operator yields the number of arguments provided for the parameter pack identiﬁer. A sizeof... expression is a pack expansion (14.5.3). [ Example: template struct count { static const std::size_t value = sizeof...(Types); };

6

— end example ] The result of sizeof and sizeof... is a constant of type std::size_t. [ Note: std::size_t is deﬁned in the standard header (18.2). — end note ]

5.3.4
1

New

[expr.new]

The new-expression attempts to create an object of the type-id (8.1) or new-type-id to which it is applied. The type of that object is the allocated type. This type shall be a complete object type, but not an abstract class type or array thereof (1.8, 3.9, 10.4). It is implementation-deﬁned whether over-aligned types are supported (3.11). [ Note: because references are not objects, references cannot be created by newexpressions. — end note ] [ Note: the type-id may be a cv-qualiﬁed type, in which case the object created by the new-expression has a cv-qualiﬁed type. — end note ] new-expression: ::opt new new-placementopt new-type-id new-initializeropt ::opt new new-placementopt ( type-id ) new-initializeropt new-placement: ( expression-list ) new-type-id: type-speciﬁer-seq new-declaratoropt new-declarator: ptr-operator new-declaratoropt noptr-new-declarator noptr-new-declarator: [ expression ] attribute-speciﬁer-seqopt noptr-new-declarator [ constant-expression ] attribute-speciﬁer-seqopt new-initializer: ( expression-listopt ) braced-init-list

2

Entities created by a new-expression have dynamic storage duration (3.7.4). [ Note: the lifetime of such an entity is not necessarily restricted to the scope in which it is created. — end note ] If the entity is a nonarray object, the new-expression returns a pointer to the object created. If it is an array, the new-expression returns a pointer to the initial element of the array. If the auto type-speciﬁer appears in the type-speciﬁer-seq of a new-type-id or type-id of a new-expression, the new-expression shall contain a new-initializer of the form
( assignment-expression )

The allocated type is deduced from the new-initializer as follows: Let e be the assignment-expression in the new-initializer and T be the new-type-id or type-id of the new-expression, then the allocated type is the type deduced for the variable x in the invented declaration (7.1.6.4):
T x(e);

[ Example: new auto(1); auto x = new auto(’a’); // allocated type is int // allocated type is char, x is of type char*

§ 5.3.4

106

c ISO/IEC

N3337

3

— end example ] The new-type-id in a new-expression is the longest possible sequence of new-declarators. [ Note: this prevents ambiguities between the declarator operators &, &&, *, and [] and their expression counterparts. — end note ] [ Example: new int * i; // syntax error: parsed as (new int*) i, not as (new int)*i

4

The * is the pointer declarator and not the multiplication operator. — end example ] [ Note: parentheses in a new-type-id of a new-expression can have surprising eﬀects. [ Example: new int(*[10])(); // error

is ill-formed because the binding is
(new int) (*[10])(); // error

Instead, the explicitly parenthesized version of the new operator can be used to create objects of compound types (3.9.2): new (int (*[10])());

5

6

7

8

9

10

allocates an array of 10 pointers to functions (taking no argument and returning int. — end example ] — end note ] When the allocated object is an array (that is, the noptr-new-declarator syntax is used or the new-type-id or type-id denotes an array type), the new-expression yields a pointer to the initial element (if any) of the array. [ Note: both new int and new int[10] have type int* and the type of new int[i][10] is int (*)[10] — end note ] The attribute-speciﬁer-seq in a noptr-new-declarator appertains to the associated array type. Every constant-expression in a noptr-new-declarator shall be an integral constant expression (5.19) and evaluate to a strictly positive value. The expression in a noptr-new-declarator shall be of integral type, unscoped enumeration type, or a class type for which a single non-explicit conversion function to integral or unscoped enumeration type exists (12.3). If the expression is of class type, the expression is converted by calling that conversion function, and the result of the conversion is used in place of the original expression. [ Example: given the deﬁnition int n = 42, new float[n][5] is well-formed (because n is the expression of a noptr-new-declarator), but new float[5][n] is ill-formed (because n is not a constant expression). — end example ] When the value of the expression in a noptr-new-declarator is zero, the allocation function is called to allocate an array with no elements. If the value of that expression is less than zero or such that the size of the allocated object would exceed the implementation-deﬁned limit, or if the new-initializer is a bracedinit-list for which the number of initializer-clauses exceeds the number of elements to initialize, no storage is obtained and the new-expression terminates by throwing an exception of a type that would match a handler (15.3) of type std::bad_array_new_length (18.6.2.2). A new-expression obtains storage for the object by calling an allocation function (3.7.4.1). If the newexpression terminates by throwing an exception, it may release storage by calling a deallocation function (3.7.4.2). If the allocated type is a non-array type, the allocation function’s name is operator new and the deallocation function’s name is operator delete. If the allocated type is an array type, the allocation function’s name is operator new[] and the deallocation function’s name is operator delete[]. [ Note: an implementation shall provide default deﬁnitions for the global allocation functions (3.7.4, 18.6.1.1, 18.6.1.2). A C++ program can provide alternative deﬁnitions of these functions (17.6.4.6) and/or class-speciﬁc versions (12.5). — end note ] If the new-expression begins with a unary :: operator, the allocation function’s name is looked up in the global scope. Otherwise, if the allocated type is a class type T or array thereof, the allocation function’s name is looked up in the scope of T. If this lookup fails to ﬁnd the name, or if the allocated type is not a class type, the allocation function’s name is looked up in the global scope. A new-expression passes the amount of space requested to the allocation function as the ﬁrst argument of type std::size_t. That argument shall be no less than the size of the object being created; it may be § 5.3.4 107

c ISO/IEC

N3337

11

12

greater than the size of the object being created only if the object is an array. For arrays of char and unsigned char, the diﬀerence between the result of the new-expression and the address returned by the allocation function shall be an integral multiple of the strictest fundamental alignment requirement (3.11) of any object type whose size is no greater than the size of the array being created. [ Note: Because allocation functions are assumed to return pointers to storage that is appropriately aligned for objects of any type with fundamental alignment, this constraint on array allocation overhead permits the common idiom of allocating character arrays into which objects of other types will later be placed. — end note ] The new-placement syntax is used to supply additional arguments to an allocation function. If used, overload resolution is performed on a function call created by assembling an argument list consisting of the amount of space requested (the ﬁrst argument) and the expressions in the new-placement part of the new-expression (the second and succeeding arguments). The ﬁrst of these arguments has type std::size_t and the remaining arguments have the corresponding types of the expressions in the new-placement. [ Example: — new T results in a call of operator new(sizeof(T)), — new(2,f) T results in a call of operator new(sizeof(T),2,f), — new T[5] results in a call of operator new[](sizeof(T)*5+x), and — new(2,f) T[5] results in a call of operator new[](sizeof(T)*5+y,2,f). Here, x and y are non-negative unspeciﬁed values representing array allocation overhead; the result of the new-expression will be oﬀset by this amount from the value returned by operator new[]. This overhead may be applied in all array new-expressions, including those referencing the library function operator new[](std::size_t, void*) and other placement allocation functions. The amount of overhead may vary from one invocation of new to another. — end example ] [ Note: unless an allocation function is declared with a non-throwing exception-speciﬁcation (15.4), it indicates failure to allocate storage by throwing a std::bad_alloc exception (Clause 15, 18.6.2.1); it returns a non-null pointer otherwise. If the allocation function is declared with a non-throwing exception-speciﬁcation, it returns null to indicate failure to allocate storage and a non-null pointer otherwise. — end note ] If the allocation function returns null, initialization shall not be done, the deallocation function shall not be called, and the value of the new-expression shall be null. [ Note: when the allocation function returns a value other than null, it must be a pointer to a block of storage in which space for the object has been reserved. The block of storage is assumed to be appropriately aligned and of the requested size. The address of the created object will not necessarily be the same as that of the block if the object is an array. — end note ] A new-expression that creates an object of type T initializes that object as follows: — If the new-initializer is omitted, the object is default-initialized (8.5); if no initialization is performed, the object has indeterminate value. — Otherwise, the new-initializer is interpreted according to the initialization rules of 8.5 for directinitialization.

13

14

15

16

17

The invocation of the allocation function is indeterminately sequenced with respect to the evaluations of expressions in the new-initializer. Initialization of the allocated object is sequenced before the value computation of the new-expression. It is unspeciﬁed whether expressions in the new-initializer are evaluated if the allocation function returns the null pointer or exits using an exception. If the new-expression creates an object or an array of objects of class type, access and ambiguity control are done for the allocation function, the deallocation function (12.5), and the constructor (12.1). If the new expression creates an array of objects of class type, access and ambiguity control are done for the destructor (12.4). § 5.3.4 108

c ISO/IEC

N3337

18

19

20

If any part of the object initialization described above76 terminates by throwing an exception and a suitable deallocation function can be found, the deallocation function is called to free the memory in which the object was being constructed, after which the exception continues to propagate in the context of the new-expression. If no unambiguous matching deallocation function can be found, propagating the exception does not cause the object’s memory to be freed. [ Note: This is appropriate when the called allocation function does not allocate memory; otherwise, it is likely to result in a memory leak. — end note ] If the new-expression begins with a unary :: operator, the deallocation function’s name is looked up in the global scope. Otherwise, if the allocated type is a class type T or an array thereof, the deallocation function’s name is looked up in the scope of T. If this lookup fails to ﬁnd the name, or if the allocated type is not a class type or array thereof, the deallocation function’s name is looked up in the global scope. A declaration of a placement deallocation function matches the declaration of a placement allocation function if it has the same number of parameters and, after parameter transformations (8.3.5), all parameter types except the ﬁrst are identical. Any non-placement deallocation function matches a non-placement allocation function. If the lookup ﬁnds a single matching deallocation function, that function will be called; otherwise, no deallocation function will be called. If the lookup ﬁnds the two-parameter form of a usual deallocation function (3.7.4.2) and that function, considered as a placement deallocation function, would have been selected as a match for the allocation function, the program is ill-formed. [ Example: struct S { // Placement allocation function: static void* operator new(std::size_t, std::size_t); // Usual (non-placement) deallocation function: static void operator delete(void*, std::size_t); }; S* p = new (0) S; // ill-formed: non-placement deallocation function matches // placement allocation function

21

— end example ] If a new-expression calls a deallocation function, it passes the value returned from the allocation function call as the ﬁrst argument of type void*. If a placement deallocation function is called, it is passed the same additional arguments as were passed to the placement allocation function, that is, the same arguments as those speciﬁed with the new-placement syntax. If the implementation is allowed to make a copy of any argument as part of the call to the allocation function, it is allowed to make a copy (of the same original value) as part of the call to the deallocation function or to reuse the copy made as part of the call to the allocation function. If the copy is elided in one place, it need not be elided in the other.

5.3.5
1

Delete delete-expression: ::opt delete cast-expression ::opt delete [ ] cast-expression

[expr.delete]

The delete-expression operator destroys a most derived object (1.8) or array created by a new-expression.

2

The ﬁrst alternative is for non-array objects, and the second is for arrays. Whenever the delete keyword is immediately followed by empty square brackets, it shall be interpreted as the second alternative.77 The operand shall have a pointer to object type, or a class type having a single non-explicit conversion function (12.3.2) to a pointer to object type. The result has type void.78 If the operand has a class type, the operand is converted to a pointer type by calling the above-mentioned conversion function, and the converted operand is used in place of the original operand for the remainder of
76) This may include evaluating a new-initializer and/or calling a constructor. 77) A lambda expression with a lambda-introducer that consists of empty square brackets can follow the delete keyword if

the lambda expression is enclosed in parentheses. 78) This implies that an object cannot be deleted using a pointer of type void* because void is not an object type.

§ 5.3.5

109

c ISO/IEC

N3337

3

4 5

6

7

8

9

10

this section. In the ﬁrst alternative (delete object), the value of the operand of delete may be a null pointer value, a pointer to a non-array object created by a previous new-expression, or a pointer to a subobject (1.8) representing a base class of such an object (Clause 10). If not, the behavior is undeﬁned. In the second alternative (delete array), the value of the operand of delete may be a null pointer value or a pointer value that resulted from a previous array new-expression.79 If not, the behavior is undeﬁned. [ Note: this means that the syntax of the delete-expression must match the type of the object allocated by new, not the syntax of the new-expression. — end note ] [ Note: a pointer to a const type can be the operand of a delete-expression; it is not necessary to cast away the constness (5.2.11) of the pointer expression before it is used as the operand of the delete-expression. — end note ] In the ﬁrst alternative (delete object), if the static type of the object to be deleted is diﬀerent from its dynamic type, the static type shall be a base class of the dynamic type of the object to be deleted and the static type shall have a virtual destructor or the behavior is undeﬁned. In the second alternative (delete array) if the dynamic type of the object to be deleted diﬀers from its static type, the behavior is undeﬁned. The cast-expression in a delete-expression shall be evaluated exactly once. If the object being deleted has incomplete class type at the point of deletion and the complete class has a non-trivial destructor or a deallocation function, the behavior is undeﬁned. If the value of the operand of the delete-expression is not a null pointer value, the delete-expression will invoke the destructor (if any) for the object or the elements of the array being deleted. In the case of an array, the elements will be destroyed in order of decreasing address (that is, in reverse order of the completion of their constructor; see 12.6.2). If the value of the operand of the delete-expression is not a null pointer value, the delete-expression will call a deallocation function (3.7.4.2). Otherwise, it is unspeciﬁed whether the deallocation function will be called. [ Note: The deallocation function is called regardless of whether the destructor for the object or some element of the array throws an exception. — end note ] [ Note: An implementation provides default deﬁnitions of the global deallocation functions operator delete() for non-arrays (18.6.1.1) and operator delete[]() for arrays (18.6.1.2). A C++ program can provide alternative deﬁnitions of these functions (17.6.4.6), and/or class-speciﬁc versions (12.5). — end note ] When the keyword delete in a delete-expression is preceded by the unary :: operator, the global deallocation function is used to deallocate the storage. Access and ambiguity control are done for both the deallocation function and the destructor (12.4, 12.5).

5.3.6
1

Alignof

[expr.alignof]

2 3

An alignof expression yields the alignment requirement of its operand type. The operand shall be a type-id representing a complete object type or an array thereof or a reference to a complete object type. The result is an integral constant of type std::size_t. When alignof is applied to a reference type, the result shall be the alignment of the referenced type. When alignof is applied to an array type, the result shall be the alignment of the element type.

5.3.7
1

noexcept operator

[expr.unary.noexcept]

The noexcept operator determines whether the evaluation of its operand, which is an unevaluated operand (Clause 5), can throw an exception (15.1). noexcept-expression: noexcept ( expression )

2 3

The result of the noexcept operator is a constant of type bool and is an rvalue. The result of the noexcept operator is false if in a potentially-evaluated context the expression would contain — a potentially evaluated call80 to a function, member function, function pointer, or member function pointer that does not have a non-throwing exception-speciﬁcation (15.4), unless the call is a constant expression (5.19),
79) For non-zero-length arrays, this is the same as a pointer to the ﬁrst element of the array created by that new-expression. Zero-length arrays do not have a ﬁrst element. 80) This includes implicit calls such as the call to an allocation function in a new-expression.

§ 5.3.7

110

c ISO/IEC

N3337

— a potentially evaluated throw-expression (15.1), — a potentially evaluated dynamic_cast expression dynamic_cast(v), where T is a reference type, that requires a run-time check (5.2.7), or — a potentially evaluated typeid expression (5.2.8) applied to a glvalue expression whose type is a polymorphic class type (10.3). Otherwise, the result is true.

5.4
1

Explicit type conversion (cast notation)

[expr.cast]

2

The result of the expression (T) cast-expression is of type T. The result is an lvalue if T is an lvalue reference type or an rvalue reference to function type and an xvalue if T is an rvalue reference to object type; otherwise the result is a prvalue. [ Note: if T is a non-class type that is cv-qualiﬁed, the cv-qualiﬁers are ignored when determining the type of the resulting prvalue; see 3.10. — end note ] An explicit type conversion can be expressed using functional notation (5.2.3), a type conversion operator (dynamic_cast, static_cast, reinterpret_cast, const_cast), or the cast notation. cast-expression: unary-expression ( type-id ) cast-expression

3 4

Any type conversion not mentioned below and not explicitly deﬁned by the user (12.3) is ill-formed. The conversions performed by — a const_cast (5.2.11), — a static_cast (5.2.9), — a static_cast followed by a const_cast, — a reinterpret_cast (5.2.10), or — a reinterpret_cast followed by a const_cast, can be performed using the cast notation of explicit type conversion. The same semantic restrictions and behaviors apply, with the exception that in performing a static_cast in the following situations the conversion is valid even if the base class is inaccessible: — a pointer to an object of derived class type or an lvalue or rvalue of derived class type may be explicitly converted to a pointer or reference to an unambiguous base class type, respectively; — a pointer to member of derived class type may be explicitly converted to a pointer to member of an unambiguous non-virtual base class type; — a pointer to an object of an unambiguous non-virtual base class type, a glvalue of an unambiguous non-virtual base class type, or a pointer to member of an unambiguous non-virtual base class type may be explicitly converted to a pointer, a reference, or a pointer to member of a derived class type, respectively. If a conversion can be interpreted in more than one of the ways listed above, the interpretation that appears ﬁrst in the list is used, even if a cast resulting from that interpretation is ill-formed. If a conversion can be interpreted in more than one way as a static_cast followed by a const_cast, the conversion is ill-formed. [ Example:

§ 5.4

111

c ISO/IEC

N3337

struct A { }; struct I1 : A { }; struct I2 : A { }; struct D : I1, I2 { }; A *foo( D *p ) { return (A*)( p ); // ill-formed static_cast interpretation }
5

— end example ] The operand of a cast using the cast notation can be a prvalue of type “pointer to incomplete class type”. The destination type of a cast using the cast notation can be “pointer to incomplete class type”. If both the operand and destination types are class types and one or both are incomplete, it is unspeciﬁed whether the static_cast or the reinterpret_cast interpretation is used, even if there is an inheritance relationship between the two classes. [ Note: For example, if the classes were deﬁned later in the translation unit, a multi-pass compiler would be permitted to interpret a cast between pointers to the classes as if the class types were complete at the point of the cast. — end note ]

5.5
1

Pointer-to-member operators pm-expression: cast-expression pm-expression .* cast-expression pm-expression ->* cast-expression

[expr.mptr.oper]

The pointer-to-member operators ->* and .* group left-to-right.

2

3

4

5

The binary operator .* binds its second operand, which shall be of type “pointer to member of T” (where T is a completely-deﬁned class type) to its ﬁrst operand, which shall be of class T or of a class of which T is an unambiguous and accessible base class. The result is an object or a function of the type speciﬁed by the second operand. The binary operator ->* binds its second operand, which shall be of type “pointer to member of T” (where T is a completely-deﬁned class type) to its ﬁrst operand, which shall be of type “pointer to T” or “pointer to a class of which T is an unambiguous and accessible base class.” The expression E1->*E2 is converted into the equivalent form (*(E1)).*E2. Abbreviating pm-expression.*cast-expression as E1.*E2, E1 is called the object expression. If the dynamic type of E1 does not contain the member to which E2 refers, the behavior is undeﬁned. The restrictions on cv-qualiﬁcation, and the manner in which the cv-qualiﬁers of the operands are combined to produce the cv-qualiﬁers of the result, are the same as the rules for E1.E2 given in 5.2.5. [ Note: it is not possible to use a pointer to member that refers to a mutable member to modify a const class object. For example, struct S { S() : i(0) { } mutable int i; }; void f() { const S cs; int S::* pm = &S::i; cs.*pm = 88; }

// pm refers to mutable member S::i // ill-formed: cs is a const object

6

— end note ] If the result of .* or ->* is a function, then that result can be used only as the operand for the function call operator (). [ Example:
(ptr_to_obj->*ptr_to_mfct)(10);

§ 5.5

112

c ISO/IEC

N3337

calls the member function denoted by ptr_to_mfct for the object pointed to by ptr_to_obj. — end example ] In a .* expression whose object expression is an rvalue, the program is ill-formed if the second operand is a pointer to member function with ref-qualiﬁer &. In a .* expression whose object expression is an lvalue, the program is ill-formed if the second operand is a pointer to member function with ref-qualiﬁer &&. The result of a .* expression whose second operand is a pointer to a data member is of the same value category (3.10) as its ﬁrst operand. The result of a .* expression whose second operand is a pointer to a member function is a prvalue. If the second operand is the null pointer to member value (4.11), the behavior is undeﬁned.

5.6
1

Multiplicative operators multiplicative-expression: pm-expression multiplicative-expression * pm-expression multiplicative-expression / pm-expression multiplicative-expression % pm-expression

[expr.mul]

The multiplicative operators *, /, and % group left-to-right.

2

3 4

The operands of * and / shall have arithmetic or unscoped enumeration type; the operands of % shall have integral or unscoped enumeration type. The usual arithmetic conversions are performed on the operands and determine the type of the result. The binary * operator indicates multiplication. The binary / operator yields the quotient, and the binary % operator yields the remainder from the division of the ﬁrst expression by the second. If the second operand of / or % is zero the behavior is undeﬁned. For integral operands the / operator yields the algebraic quotient with any fractional part discarded;81 if the quotient a/b is representable in the type of the result, (a/b)*b + a%b is equal to a.

5.7
1

Additive operators

[expr.add]

The additive operators + and - group left-to-right. The usual arithmetic conversions are performed for operands of arithmetic or enumeration type. additive-expression: multiplicative-expression additive-expression + multiplicative-expression additive-expression - multiplicative-expression

2

For addition, either both operands shall have arithmetic or unscoped enumeration type, or one operand shall be a pointer to a completely-deﬁned object type and the other shall have integral or unscoped enumeration type. For subtraction, one of the following shall hold: — both operands have arithmetic or unscoped enumeration type; or — both operands are pointers to cv-qualiﬁed or cv-unqualiﬁed versions of the same completely-deﬁned object type; or — the left operand is a pointer to a completely-deﬁned object type and the right operand has integral or unscoped enumeration type.

3

4

5

The result of the binary + operator is the sum of the operands. The result of the binary - operator is the diﬀerence resulting from the subtraction of the second operand from the ﬁrst. For the purposes of these operators, a pointer to a nonarray object behaves the same as a pointer to the ﬁrst element of an array of length one with the type of the object as its element type. When an expression that has integral type is added to or subtracted from a pointer, the result has the type of the pointer operand. If the pointer operand points to an element of an array object, and the array is large enough, the result points to an element oﬀset from the original element such that the diﬀerence of the subscripts of the resulting and original array elements equals the integral expression. In other words, if
81) This is often called truncation towards zero.

§ 5.7

113

c ISO/IEC

N3337

6

7

the expression P points to the i-th element of an array object, the expressions (P)+N (equivalently, N+(P)) and (P)-N (where N has the value n) point to, respectively, the i + n-th and i − n-th elements of the array object, provided they exist. Moreover, if the expression P points to the last element of an array object, the expression (P)+1 points one past the last element of the array object, and if the expression Q points one past the last element of an array object, the expression (Q)-1 points to the last element of the array object. If both the pointer operand and the result point to elements of the same array object, or one past the last element of the array object, the evaluation shall not produce an overﬂow; otherwise, the behavior is undeﬁned. When two pointers to elements of the same array object are subtracted, the result is the diﬀerence of the subscripts of the two array elements. The type of the result is an implementation-deﬁned signed integral type; this type shall be the same type that is deﬁned as std::ptrdiff_t in the header (18.2). As with any other arithmetic overﬂow, if the result does not ﬁt in the space provided, the behavior is undeﬁned. In other words, if the expressions P and Q point to, respectively, the i-th and j-th elements of an array object, the expression (P)-(Q) has the value i − j provided the value ﬁts in an object of type std::ptrdiff_t. Moreover, if the expression P points either to an element of an array object or one past the last element of an array object, and the expression Q points to the last element of the same array object, the expression ((Q)+1)-(P) has the same value as ((Q)-(P))+1 and as -((P)-((Q)+1)), and has the value zero if the expression P points one past the last element of the array object, even though the expression (Q)+1 does not point to an element of the array object. Unless both pointers point to elements of the same array object, or one past the last element of the array object, the behavior is undeﬁned.82 If the value 0 is added to or subtracted from a pointer value, the result compares equal to the original pointer value. If two pointers point to the same object or both point one past the end of the same array or both are null, and the two pointers are subtracted, the result compares equal to the value 0 converted to the type std::ptrdiff_t.

5.8
1

Shift operators shift-expression: additive-expression shift-expression > additive-expression

[expr.shift]

The shift operators > group left-to-right.

2

3

The operands shall be of integral or unscoped enumeration type and integral promotions are performed. The type of the result is that of the promoted left operand. The behavior is undeﬁned if the right operand is negative, or greater than or equal to the length in bits of the promoted left operand. The value of E1 > E2 is E1 right-shifted E2 bit positions. If E1 has an unsigned type or if E1 has a signed type and a non-negative value, the value of the result is the integral part of the quotient of E1/2E2 . If E1 has a signed type and a negative value, the resulting value is implementation-deﬁned.

5.9
1

Relational operators

[expr.rel]

The relational operators group left-to-right. [ Example: a decltype(i(h())); // forces completion of A and implicitly uses // A::˜A() for the temporary introduced by the // use of h(). (A temporary is not introduced // as a result of the use of i().) template auto f(T) // #2 -> void; auto g() -> void { f(42); // OK: calls #2. (#1 is not a viable candidate: type // deduction fails (14.8.2) because A::~A() // is implicitly used in its decltype-speciﬁer) } template auto q(T) -> decltype((h())); // does not force completion of A; A::˜A() is // not implicitly used within the context of this decltype-speciﬁer void r() { q(42); // Error: deduction against q succeeds, so overload resolution // selects the specialization “q(T) -> decltype((h())) [with T=int]”. // The return type is A, so a temporary is introduced and its

§ 7.1.6.2

147

c ISO/IEC

N3337

// destructor is used, so the program is ill-formed. }

— end example ] — end note ] 7.1.6.3 Elaborated type speciﬁers elaborated-type-speciﬁer: class-key attribute-speciﬁer-seqopt nested-name-speciﬁeropt identiﬁer class-key nested-name-speciﬁeropt templateopt simple-template-id enum nested-name-speciﬁeropt identiﬁer
1

[dcl.type.elab]

An attribute-speciﬁer-seq shall not appear in an elaborated-type-speciﬁer unless the latter is the sole constituent of a declaration. If an elaborated-type-speciﬁer is the sole constituent of a declaration, the declaration is ill-formed unless it is an explicit specialization (14.7.3), an explicit instantiation (14.7.2) or it has one of the following forms: class-key attribute-speciﬁer-seqopt identiﬁer ; friend class-key ::opt identiﬁer ; friend class-key ::opt simple-template-id ; friend class-key nested-name-speciﬁer identiﬁer ; friend class-key nested-name-speciﬁer templateopt simple-template-id ;

2

In the ﬁrst case, the attribute-speciﬁer-seq, if any, appertains to the class being declared; the attributes in the attribute-speciﬁer-seq are thereafter considered attributes of the class whenever it is named. 3.4.4 describes how name lookup proceeds for the identiﬁer in an elaborated-type-speciﬁer. If the identiﬁer resolves to a class-name or enum-name, the elaborated-type-speciﬁer introduces it into the declaration the same way a simple-type-speciﬁer introduces its type-name. If the identiﬁer resolves to a typedef-name or the simple-template-id resolves to an alias template specialization, the elaborated-type-speciﬁer is ill-formed. [ Note: This implies that, within a class template with a template type-parameter T, the declaration friend class T;

3

is ill-formed. However, the similar declaration friend T; is allowed (11.3). — end note ] The class-key or enum keyword present in the elaborated-type-speciﬁer shall agree in kind with the declaration to which the name in the elaborated-type-speciﬁer refers. This rule also applies to the form of elaborated-type-speciﬁer that declares a class-name or friend class since it can be construed as referring to the deﬁnition of the class. Thus, in any elaborated-type-speciﬁer, the enum keyword shall be used to refer to an enumeration (7.2), the union class-key shall be used to refer to a union (Clause 9), and either the class or struct class-key shall be used to refer to a class (Clause 9) declared using the class or struct class-key. [ Example: enum class E { a, b }; enum E x = E::a; // OK

— end example ] 7.1.6.4 auto speciﬁer
1

[dcl.spec.auto]

2

3

The auto type-speciﬁer signiﬁes that the type of a variable being declared shall be deduced from its initializer or that a function declarator shall include a trailing-return-type. The auto type-speciﬁer may appear with a function declarator with a trailing-return-type (8.3.5) in any context where such a declarator is valid. Otherwise, the type of the variable is deduced from its initializer. The name of the variable being declared shall not appear in the initializer expression. This use of auto is allowed when declaring variables in a block (6.3), in namespace scope (3.3.6), and in a for-init-statement (6.5.3). auto shall appear as one of the decl-speciﬁers in the decl-speciﬁer-seq and the decl-speciﬁer-seq shall be followed by one or more initdeclarators, each of which shall have a non-empty initializer. [ Example:

§ 7.1.6.4

148

c ISO/IEC

N3337

auto x = 5; const auto *v = &x, u = 6; static auto y = 0.0; auto int r;
4

// // // //

OK: x has type int OK: v has type const int*, u has type const int OK: y has type double error: auto is not a storage-class-speciﬁer

5 6

— end example ] The auto type-speciﬁer can also be used in declaring a variable in the condition of a selection statement (6.4) or an iteration statement (6.5), in the type-speciﬁer-seq in the new-type-id or type-id of a new-expression (5.3.4), in a for-range-declaration, and in declaring a static data member with a brace-or-equal-initializer that appears within the member-speciﬁcation of a class deﬁnition (9.4.2). A program that uses auto in a context not explicitly allowed in this section is ill-formed. Once the type of a declarator-id has been determined according to 8.3, the type of the declared variable using the declarator-id is determined from the type of its initializer using the rules for template argument deduction. Let T be the type that has been determined for a variable identiﬁer d. Obtain P from T by replacing the occurrences of auto with either a new invented type template parameter U or, if the initializer is a braced-init-list (8.5.4), with std::initializer_list. The type deduced for the variable d is then the deduced A determined using the rules of template argument deduction from a function call (14.8.2.1), where P is a function template parameter type and the initializer for d is the corresponding argument. If the deduction fails, the declaration is ill-formed. [ Example: auto x1 = { 1, 2 }; auto x2 = { 1, 2.0 }; // decltype(x1) is std::initializer_list // error: cannot deduce element type

7

— end example ] If the list of declarators contains more than one declarator, the type of each declared variable is determined as described above. If the type deduced for the template parameter U is not the same in each deduction, the program is ill-formed. [ Example: const auto &i = expr;

The type of i is the deduced type of the parameter u in the call f(expr) of the following invented function template: template void f(const U& u);

— end example ]

7.2
1

Enumeration declarations

[dcl.enum]

An enumeration is a distinct type (3.9.2) with named constants. Its name becomes an enum-name, within its scope. enum-name: identiﬁer enum-speciﬁer: enum-head { enumerator-listopt } enum-head { enumerator-list , } enum-head: enum-key attribute-speciﬁer-seqopt identiﬁeropt enum-baseopt enum-key attribute-speciﬁer-seqopt nested-name-speciﬁer identiﬁer enum-baseopt opaque-enum-declaration: enum-key attribute-speciﬁer-seqopt identiﬁer enum-baseopt ; enum-key: enum enum class enum struct

§ 7.2

149

c ISO/IEC

N3337

enum-base: : type-speciﬁer-seq enumerator-list: enumerator-deﬁnition enumerator-list , enumerator-deﬁnition enumerator-deﬁnition: enumerator enumerator = constant-expression enumerator: identiﬁer

2

The optional attribute-speciﬁer-seq in the enum-head and the opaque-enum-declaration appertains to the enumeration; the attributes in that attribute-speciﬁer-seq are thereafter considered attributes of the enumeration whenever it is named. The enumeration type declared with an enum-key of only enum is an unscoped enumeration, and its enumerators are unscoped enumerators. The enum-keys enum class and enum struct are semantically equivalent; an enumeration type declared with one of these is a scoped enumeration, and its enumerators are scoped enumerators. The optional identiﬁer shall not be omitted in the declaration of a scoped enumeration. The type-speciﬁer-seq of an enum-base shall name an integral type; any cv-qualiﬁcation is ignored. An opaqueenum-declaration declaring an unscoped enumeration shall not omit the enum-base. The identiﬁers in an enumerator-list are declared as constants, and can appear wherever constants are required. An enumeratordeﬁnition with = gives the associated enumerator the value indicated by the constant-expression. If the ﬁrst enumerator has no initializer, the value of the corresponding constant is zero. An enumerator-deﬁnition without an initializer gives the enumerator the value obtained by increasing the value of the previous enumerator by one. [ Example: enum { a, b, c=0 }; enum { d, e, f=e+2 };

3

4

5

deﬁnes a, c, and d to be zero, b and e to be 1, and f to be 3. — end example ] An opaque-enum-declaration is either a redeclaration of an enumeration in the current scope or a declaration of a new enumeration. [ Note: An enumeration declared by an opaque-enum-declaration has ﬁxed underlying type and is a complete type. The list of enumerators can be provided in a later redeclaration with an enumspeciﬁer. — end note ] A scoped enumeration shall not be later redeclared as unscoped or with a diﬀerent underlying type. An unscoped enumeration shall not be later redeclared as scoped and each redeclaration shall include an enum-base specifying the same underlying type as in the original declaration. If the enum-key is followed by a nested-name-speciﬁer, the enum-speciﬁer shall refer to an enumeration that was previously declared directly in the class or namespace to which the nested-name-speciﬁer refers (i.e., neither inherited nor introduced by a using-declaration), and the enum-speciﬁer shall appear in a namespace enclosing the previous declaration. Each enumeration deﬁnes a type that is diﬀerent from all other types. Each enumeration also has an underlying type. The underlying type can be explicitly speciﬁed using enum-base; if not explicitly speciﬁed, the underlying type of a scoped enumeration type is int. In these cases, the underlying type is said to be ﬁxed. Following the closing brace of an enum-speciﬁer, each enumerator has the type of its enumeration. If the underlying type is ﬁxed, the type of each enumerator prior to the closing brace is the underlying type and the constant-expression in the enumerator-deﬁnition shall be a converted constant expression of the underlying type (5.19); if the initializing value of an enumerator cannot be represented by the underlying type, the program is ill-formed. If the underlying type is not ﬁxed, the type of each enumerator is the type of its initializing value: — If an initializer is speciﬁed for an enumerator, the initializing value has the same type as the expression and the constant-expression shall be an integral constant expression (5.19).

§ 7.2

150

c ISO/IEC

N3337

— If no initializer is speciﬁed for the ﬁrst enumerator, the initializing value has an unspeciﬁed integral type. — Otherwise the type of the initializing value is the same as the type of the initializing value of the preceding enumerator unless the incremented value is not representable in that type, in which case the type is an unspeciﬁed integral type suﬃcient to contain the incremented value. If no such type exists, the program is ill-formed.
6

7

8 9

For an enumeration whose underlying type is not ﬁxed, the underlying type is an integral type that can represent all the enumerator values deﬁned in the enumeration. If no integral type can represent all the enumerator values, the enumeration is ill-formed. It is implementation-deﬁned which integral type is used as the underlying type except that the underlying type shall not be larger than int unless the value of an enumerator cannot ﬁt in an int or unsigned int. If the enumerator-list is empty, the underlying type is as if the enumeration had a single enumerator with value 0. For an enumeration whose underlying type is ﬁxed, the values of the enumeration are the values of the underlying type. Otherwise, for an enumeration where emin is the smallest enumerator and emax is the largest, the values of the enumeration are the values in the range bmin to bmax , deﬁned as follows: Let K be 1 for a two’s complement representation and 0 for a one’s complement or sign-magnitude representation. bmax is the smallest value greater than or equal to max(|emin | − K, |emax |) and equal to 2M − 1, where M is a non-negative integer. bmin is zero if emin is non-negative and −(bmax + K) otherwise. The size of the smallest bit-ﬁeld large enough to hold all the values of the enumeration type is max(M, 1) if bmin is zero and M + 1 otherwise. It is possible to deﬁne an enumeration that has values not deﬁned by any of its enumerators. If the enumerator-list is empty, the values of the enumeration are as if the enumeration had a single enumerator with value 0.93 Two enumeration types are layout-compatible if they have the same underlying type. The value of an enumerator or an object of an unscoped enumeration type is converted to an integer by integral promotion (4.5). [ Example: enum color { red, yellow, green=20, blue }; color col = red; color* cp = &col; if (*cp == blue) // ...

makes color a type describing various colors, and then declares col as an object of that type, and cp as a pointer to an object of that type. The possible values of an object of type color are red, yellow, green, blue; these values can be converted to the integral values 0, 1, 20, and 21. Since enumerations are distinct types, objects of type color can be assigned only values of type color. color c = 1; // error: type mismatch, // no conversion from int to color // OK: yellow converted to integral value 1 // integral promotion

int i = yellow;

Note that this implicit enum to int conversion is not provided for a scoped enumeration: enum class Col { red, yellow, green }; int x = Col::red; // error: no Col to int conversion Col y = Col::red; if (y) { } // error: no Col to bool conversion

— end example ]
93) This set of values is used to deﬁne promotion and conversion semantics for the enumeration type. It does not preclude an expression of enumeration type from having a value that falls outside this range.

§ 7.2

151

c ISO/IEC

N3337

10

Each enum-name and each unscoped enumerator is declared in the scope that immediately contains the enum-speciﬁer. Each scoped enumerator is declared in the scope of the enumeration. These names obey the scope rules deﬁned for all names in (3.3) and (3.4).[ Example: enum direction { left=’l’, right=’r’ }; void g() { direction d; d = left; d = direction::right; }

// OK // OK // OK

enum class altitude { high=’h’, low=’l’ }; void h() { altitude a; a = high; a = altitude::low; }

// OK // error: high not in scope // OK

— end example ] An enumerator declared in class scope can be referred to using the class member access operators (::, . (dot) and -> (arrow)), see 5.2.5. [ Example: struct X { enum direction { left=’l’, right=’r’ }; int f(int i) { return i==left ? 0 : i==right ? 1 : 2; } }; void g(X* p) { direction d; int i; i = p->f(left); i = p->f(X::right); i = p->f(p->left); // ... }

// error: direction not in scope // error: left not in scope // OK // OK

— end example ]

7.3
1

Namespaces

[basic.namespace]

2

A namespace is an optionally-named declarative region. The name of a namespace can be used to access entities declared in that namespace; that is, the members of the namespace. Unlike other declarative regions, the deﬁnition of a namespace can be split over several parts of one or more translation units. The outermost declarative region of a translation unit is a namespace; see 3.3.6.

7.3.1
1

Namespace deﬁnition namespace-name: original-namespace-name namespace-alias original-namespace-name: identiﬁer namespace-deﬁnition: named-namespace-deﬁnition unnamed-namespace-deﬁnition

[namespace.def]

The grammar for a namespace-deﬁnition is

§ 7.3.1

152

c ISO/IEC

N3337

named-namespace-deﬁnition: original-namespace-deﬁnition extension-namespace-deﬁnition original-namespace-deﬁnition: inlineopt namespace identiﬁer { namespace-body } extension-namespace-deﬁnition: inlineopt namespace original-namespace-name { namespace-body } unnamed-namespace-deﬁnition: inlineopt namespace { namespace-body } namespace-body: declaration-seqopt
2

3

4 5

The identiﬁer in an original-namespace-deﬁnition shall not have been previously deﬁned in the declarative region in which the original-namespace-deﬁnition appears. The identiﬁer in an original-namespace-deﬁnition is the name of the namespace. Subsequently in that declarative region, it is treated as an original-namespacename. The original-namespace-name in an extension-namespace-deﬁnition shall have previously been deﬁned in an original-namespace-deﬁnition in the same declarative region. Every namespace-deﬁnition shall appear in the global scope or in a namespace scope (3.3.6). Because a namespace-deﬁnition contains declarations in its namespace-body and a namespace-deﬁnition is itself a declaration, it follows that namespace-deﬁnitions can be nested. [ Example: namespace Outer { int i; namespace Inner { void f() { i++; } int i; void g() { i++; } } }

// Outer::i // Inner::i

6

— end example ] The enclosing namespaces of a declaration are those namespaces in which the declaration lexically appears, except for a redeclaration of a namespace member outside its original namespace (e.g., a deﬁnition as speciﬁed in 7.3.1.2). Such a redeclaration has the same enclosing namespaces as the original declaration. [ Example: namespace Q { namespace V { void f(); // enclosing namespaces are the global namespace, Q, and Q::V class C { void m(); }; } void V::f() { // enclosing namespaces are the global namespace, Q, and Q::V extern void h(); // ... so this declares Q::V::h } void V::C::m() { // enclosing namespaces are the global namespace, Q, and Q::V } }

7

8

— end example ] If the optional initial inline keyword appears in a namespace-deﬁnition for a particular namespace, that namespace is declared to be an inline namespace. The inline keyword may be used on an extensionnamespace-deﬁnition only if it was previously used on the original-namespace-deﬁnition for that namespace. Members of an inline namespace can be used in most respects as though they were members of the enclosing namespace. Speciﬁcally, the inline namespace and its enclosing namespace are both added to the set of § 7.3.1 153

c ISO/IEC

N3337

9

associated namespaces used in argument-dependent lookup (3.4.2) whenever one of them is, and a usingdirective (7.3.4) that names the inline namespace is implicitly inserted into the enclosing namespace as for an unnamed namespace (7.3.1.1). Furthermore, each member of the inline namespace can subsequently be explicitly instantiated (14.7.2) or explicitly specialized (14.7.3) as though it were a member of the enclosing namespace. Finally, looking up a name in the enclosing namespace via explicit qualiﬁcation (3.4.3.2) will include members of the inline namespace brought in by the using-directive even if there are declarations of that name in the enclosing namespace. These properties are transitive: if a namespace N contains an inline namespace M, which in turn contains an inline namespace O, then the members of O can be used as though they were members of M or N. The inline namespace set of N is the transitive closure of all inline namespaces in N. The enclosing namespace set of O is the set of namespaces consisting of the innermost non-inline namespace enclosing an inline namespace O, together with any intervening inline namespaces. 7.3.1.1 Unnamed namespaces [namespace.unnamed] An unnamed-namespace-deﬁnition behaves as if it were replaced by inlineopt namespace unique { /* empty body */ } using namespace unique ; namespace unique { namespace-body }

1

where inline appears if and only if it appears in the unnamed-namespace-deﬁnition, all occurrences of unique in a translation unit are replaced by the same identiﬁer, and this identiﬁer diﬀers from all other identiﬁers in the entire program.94 [ Example: namespace { int i; } void f() { i++; } namespace A { namespace { int i; int j; } void g() { i++; } } using namespace A; void h() { i++; A::i++; j++; } // unique ::i // unique ::i++

// A:: unique ::i // A:: unique ::j // A:: unique ::i++

// error: unique ::i or A:: unique ::i // A:: unique ::i // A:: unique ::j

— end example ] 7.3.1.2 Namespace member deﬁnitions
1

[namespace.memdef]

Members (including explicit specializations of templates (14.7.3)) of a namespace can be deﬁned within that namespace. [ Example: namespace X { void f() { /∗ ... ∗/ } }

2

— end example ] Members of a named namespace can also be deﬁned outside that namespace by explicit qualiﬁcation (3.4.3.2) of the name being deﬁned, provided that the entity being deﬁned was already declared in the namespace and the deﬁnition appears after the point of declaration in a namespace that encloses the declaration’s namespace. [ Example:
94) Although entities in an unnamed namespace might have external linkage, they are eﬀectively qualiﬁed by a name unique to their translation unit and therefore can never be seen from any other translation unit.

§ 7.3.1.2

154

c ISO/IEC

N3337

namespace Q { namespace V void f(); } void V::f() void V::g() namespace V void g(); } }

{

{ /∗ ... ∗/ } { /∗ ... ∗/ } {

// OK // error: g() is not yet a member of V

namespace R { void Q::V::g() { /∗ ... ∗/ } }
3

// error: R doesn’t enclose Q

— end example ] Every name ﬁrst declared in a namespace is a member of that namespace. If a friend declaration in a nonlocal class ﬁrst declares a class or function95 the friend class or function is a member of the innermost enclosing namespace. The name of the friend is not found by unqualiﬁed lookup (3.4.1) or by qualiﬁed lookup (3.4.3) until a matching declaration is provided in that namespace scope (either before or after the class deﬁnition granting friendship). If a friend function is called, its name may be found by the name lookup that considers functions from namespaces and classes associated with the types of the function arguments (3.4.2). If the name in a friend declaration is neither qualiﬁed nor a template-id and the declaration is a function or an elaborated-type-speciﬁer, the lookup to determine whether the entity has been previously declared shall not consider any scopes outside the innermost enclosing namespace. [ Note: The other forms of friend declarations cannot declare a new member of the innermost enclosing namespace and thus follow the usual lookup rules. — end note ] [ Example:
// Assume f and g have not yet been deﬁned. void h(int); template void f2(T); namespace A { class X { friend void f(X); // A::f(X) is a friend class Y { friend void g(); // A::g is a friend friend void h(int); // A::h is a friend // ::h not considered friend void f2(int); // ::f2(int) is a friend }; }; // A::f, A::g and A::h are not visible here X x; void g() { f(x); } // deﬁnition of A::g void f(X) { /* ... */} // deﬁnition of A::f void h(int) { /* ... */ } // deﬁnition of A::h // A::f, A::g and A::h are visible here and known to be friends } using A::x; void h() {
95) this implies that the name of the class or function is unqualiﬁed.

§ 7.3.1.2

155

c ISO/IEC

N3337

A::f(x); A::X::f(x); A::X::Y::g(); }

// error: f is not a member of A::X // error: g is not a member of A::X::Y

— end example ]

7.3.2
1

Namespace alias namespace-alias: identiﬁer namespace-alias-deﬁnition: namespace identiﬁer = qualiﬁed-namespace-speciﬁer ; qualiﬁed-namespace-speciﬁer: nested-name-speciﬁeropt namespace-name

[namespace.alias]

A namespace-alias-deﬁnition declares an alternate name for a namespace according to the following grammar:

2

3

The identiﬁer in a namespace-alias-deﬁnition is a synonym for the name of the namespace denoted by the qualiﬁed-namespace-speciﬁer and becomes a namespace-alias. [ Note: When looking up a namespace-name in a namespace-alias-deﬁnition, only namespace names are considered, see 3.4.6. — end note ] In a declarative region, a namespace-alias-deﬁnition can be used to redeﬁne a namespace-alias declared in that declarative region to refer only to the namespace to which it already refers. [ Example: the following declarations are well-formed: namespace namespace namespace namespace Company_with_very_long_name { /∗ ... ∗/ } CWVLN = Company_with_very_long_name; CWVLN = Company_with_very_long_name; CWVLN = CWVLN;

// OK: duplicate

4

— end example ] A namespace-name or namespace-alias shall not be declared as the name of any other entity in the same declarative region. A namespace-name deﬁned at global scope shall not be declared as the name of any other entity in any global scope of the program. No diagnostic is required for a violation of this rule by declarations in diﬀerent translation units.

7.3.3
1

The using declaration using-declaration: using typenameopt nested-name-speciﬁer unqualiﬁed-id ; using :: unqualiﬁed-id ;

[namespace.udecl]

A using-declaration introduces a name into the declarative region in which the using-declaration appears.

2

The member name speciﬁed in a using-declaration is declared in the declarative region in which the using-declaration appears. [ Note: Only the speciﬁed name is so declared; specifying an enumeration name in a using-declaration does not declare its enumerators in the using-declaration’s declarative region. — end note ] If a using-declaration names a constructor (3.4.3.1), it implicitly declares a set of constructors in the class in which the using-declaration appears (12.9); otherwise the name speciﬁed in a using-declaration is a synonym for the name of some entity declared elsewhere. Every using-declaration is a declaration and a member-declaration and so can be used in a class deﬁnition. [ Example: struct B { void f(char); void g(char); enum E { e }; union { int x; }; }; struct D : B { using B::f;

§ 7.3.3

156

c ISO/IEC

N3337

void f(int) { f(’c’); } void g(int) { g(’c’); } };
3

// calls B::f(char) // recursively calls D::g(int)

— end example ] In a using-declaration used as a member-declaration, the nested-name-speciﬁer shall name a base class of the class being deﬁned. If such a using-declaration names a constructor, the nested-name-speciﬁer shall name a direct base class of the class being deﬁned; otherwise it introduces the set of declarations found by member name lookup (10.2, 3.4.3.1). [ Example: class C { int g(); }; class D2 : public B { using B::f; using B::e; using B::x; using C::g; };

// // // //

OK: B is a base of D2 OK: e is an enumerator of base B OK: x is a union member of base B error: C isn’t a base of D2

4

5

— end example ] [ Note: Since destructors do not have names, a using-declaration cannot refer to a destructor for a base class. Since specializations of member templates for conversion functions are not found by name lookup, they are not considered when a using-declaration speciﬁes a conversion function (14.5.2). — end note ] If an assignment operator brought from a base class into a derived class scope has the signature of a copy/move assignment operator for the derived class (12.8), the using-declaration does not by itself suppress the implicit declaration of the derived class assignment operator; the copy/move assignment operator from the base class is hidden or overridden by the implicitly-declared copy/move assignment operator of the derived class, as described below. A using-declaration shall not name a template-id. [ Example: struct A { template void f(T); template struct X { }; }; struct B : A { using A::f; // ill-formed using A::X; // ill-formed };

6 7 8

— end example ] A using-declaration shall not name a namespace. A using-declaration shall not name a scoped enumerator. A using-declaration for a class member shall be a member-declaration. [ Example: struct X { int i; static int s; }; void f() { using X::i; using X::s; }

// // // //

error: X::i is a class member and this is not a member declaration. error: X::s is a class member and this is not a member declaration.

§ 7.3.3

157

c ISO/IEC

N3337

9

— end example ] Members declared by a using-declaration can be referred to by explicit qualiﬁcation just like other member names (3.4.3.2). In a using-declaration, a preﬁx :: refers to the global namespace. [ Example: void f(); namespace A { void g(); } namespace X { using ::f; using A::g; } void h() { X::f(); X::g(); }

// global f // A’s g

// calls ::f // calls A::g

10

— end example ] A using-declaration is a declaration and can therefore be used repeatedly where (and only where) multiple declarations are allowed. [ Example: namespace A { int i; } namespace A1 { using A::i; using A::i; } void f() { using A::i; using A::i; } struct B { int i; }; struct X : B { using B::i; using B::i; };

// OK: double declaration

// error: double declaration

// error: double member declaration

11

— end example ] The entity declared by a using-declaration shall be known in the context using it according to its deﬁnition at the point of the using-declaration. Deﬁnitions added to the namespace after the using-declaration are not considered when a use of the name is made. [ Example: namespace A { void f(int); }

§ 7.3.3

158

c ISO/IEC

N3337

using A::f; namespace A { void f(char); } void foo() { f(’a’); } void bar() { using A::f; f(’a’); }
12

// f is a synonym for A::f; // that is, for A::f(int).

// calls f(int), // even though f(char) exists.

// f is a synonym for A::f; // that is, for A::f(int) and A::f(char). // calls f(char)

13

— end example ] [ Note: Partial specializations of class templates are found by looking up the primary class template and then considering all partial specializations of that template. If a using-declaration names a class template, partial specializations introduced after the using-declaration are eﬀectively visible because the primary template is visible (14.5.5). — end note ] Since a using-declaration is a declaration, the restrictions on declarations of the same name in the same declarative region (3.3) also apply to using-declarations. [ Example: namespace A { int x; } namespace B { int i; struct g { }; struct x { }; void f(int); void f(double); void g(char); } void func() { int i; using B::i; void f(char); using B::f; f(3.5); using B::g; g(’a’); struct g g1; using B::x; using A::x; x = 99; struct x x1; }

// OK: hides struct g

// error: i declared twice // OK: each f is a function // calls B::f(double) // calls B::g(char) // g1 has class type B::g // OK: hides struct B::x // assigns to A::x // x1 has class type B::x

14

— end example ] If a function declaration in namespace scope or block scope has the same name and the same parameter types as a function introduced by a using-declaration, and the declarations do not declare the same function, the program is ill-formed. [ Note: Two using-declarations may introduce functions with the same name and § 7.3.3 159

c ISO/IEC

N3337

the same parameter types. If, for a call to an unqualiﬁed function name, function overload resolution selects the functions introduced by such using-declarations, the function call is ill-formed. [ Example: namespace B { void f(int); void f(double); } namespace C { void f(int); void f(double); void f(char); } void h() { using B::f; using C::f; f(’h’); f(1); void f(int); }
15

// // // // //

B::f(int) and B::f(double) C::f(int), C::f(double), and C::f(char) calls C::f(char) error: ambiguous: B::f(int) or C::f(int)? error: f(int) conﬂicts with C::f(int) and B::f(int)

— end example ] — end note ] When a using-declaration brings names from a base class into a derived class scope, member functions and member function templates in the derived class override and/or hide member functions and member function templates with the same name, parameter-type-list (8.3.5), cv-qualiﬁcation, and ref-qualiﬁer (if any) in a base class (rather than conﬂicting). [ Note: For using-declarations that name a constructor, see 12.9. — end note ] [ Example: struct B { virtual void f(int); virtual void f(char); void g(int); void h(int); }; struct D : B { using B::f; void f(int); using B::g; void g(char); using B::h; void h(int); }; void k(D* p) { p->f(1); p->f(’a’); p->g(1); p->g(’a’); }

// OK: D::f(int) overrides B::f(int);

// OK

// OK: D::h(int) hides B::h(int)

// // // //

calls calls calls calls

D::f(int) B::f(char) B::g(int) D::g(char)

16

— end example ] For the purpose of overload resolution, the functions which are introduced by a using-declaration into a derived class will be treated as though they were members of the derived class. In particular, the implicit § 7.3.3 160

c ISO/IEC

N3337

17

this parameter shall be treated as if it were a pointer to the derived class rather than to the base class. This has no eﬀect on the type of the function, and in all other respects the function remains a member of the base class. The access rules for inheriting constructors are speciﬁed in 12.9; otherwise all instances of the name mentioned in a using-declaration shall be accessible. In particular, if a derived class uses a using-declaration to access a member of a base class, the member name shall be accessible. If the name is that of an overloaded member function, then all functions named shall be accessible. The base class members mentioned by a using-declaration shall be visible in the scope of at least one of the direct base classes of the class where the using-declaration is speciﬁed. [ Note: Because a using-declaration designates a base class member (and not a member subobject or a member function of a base class subobject), a using-declaration cannot be used to resolve inherited member ambiguities. For example, struct A { int x(); }; struct B : A { }; struct C : A { using A::x; int x(int); }; struct D : B, C { using C::x; int x(double); }; int f(D* d) { return d->x(); }

// ambiguous: B::x or C::x

18

— end note ] The alias created by the using-declaration has the usual accessibility for a member-declaration. [ Note: A using-declaration that names a constructor does not create aliases; see 12.9 for the pertinent accessibility rules. — end note ] [ Example: class A { private: void f(char); public: void f(int); protected: void g(); }; class B : public A { using A::f; // error: A::f(char) is inaccessible public: using A::g; // B::g is a public synonym for A::g };

19

— end example ] If a using-declaration uses the keyword typename and speciﬁes a dependent name (14.6.2), the name introduced by the using-declaration is treated as a typedef-name (7.1.3).

7.3.4

Using directive

[namespace.udir]

using-directive: attribute-speciﬁer-seqopt using namespace nested-name-speciﬁeropt namespace-name ;

§ 7.3.4

161

c ISO/IEC

N3337

1

2

3

A using-directive shall not appear in class scope, but may appear in namespace scope or in block scope. [ Note: When looking up a namespace-name in a using-directive, only namespace names are considered, see 3.4.6. — end note ] The optional attribute-speciﬁer-seq appertains to the using-directive. A using-directive speciﬁes that the names in the nominated namespace can be used in the scope in which the using-directive appears after the using-directive. During unqualiﬁed name lookup (3.4.1), the names appear as if they were declared in the nearest enclosing namespace which contains both the using-directive and the nominated namespace. [ Note: In this context, “contains” means “contains directly or indirectly”. — end note ] A using-directive does not add any members to the declarative region in which it appears. [ Example: namespace A { int i; namespace B { namespace C { int i; } using namespace void f1() { i = 5; } } namespace D { using namespace using namespace void f2() { i = 5; } } void f3() { i = 5; } } void f4() { i = 5; }

A::B::C; // OK, C::i visible in B and hides A::i

B; C; // ambiguous, B::C::i or A::i?

// uses A::i

// ill-formed; neither i is visible

4

— end example ] For unqualiﬁed lookup (3.4.1), the using-directive is transitive: if a scope contains a using-directive that nominates a second namespace that itself contains using-directives, the eﬀect is as if the using-directives from the second namespace also appeared in the ﬁrst. [ Note: For qualiﬁed lookup, see 3.4.3.2. — end note ] [ Example: namespace M { int i; } namespace N { int i; using namespace M; } void f() { using namespace N; i = 7; // error: both M::i and N::i are visible }

§ 7.3.4

162

c ISO/IEC

N3337

For another example, namespace A { int i; } namespace B { int i; int j; namespace C { namespace D { using namespace A; int j; int k; int a = i; // B::i hides A::i } using namespace D; int k = 89; // no problem yet int l = k; // ambiguous: C::k or D::k int m = i; // B::i hides A::i int n = j; // D::j hides B::j } }
5

6

— end example ] If a namespace is extended by an extension-namespace-deﬁnition after a using-directive for that namespace is given, the additional members of the extended namespace and the members of namespaces nominated by using-directives in the extension-namespace-deﬁnition can be used after the extension-namespace-deﬁnition. If name lookup ﬁnds a declaration for a name in two diﬀerent namespaces, and the declarations do not declare the same entity and do not declare functions, the use of the name is ill-formed. [ Note: In particular, the name of a variable, function or enumerator does not hide the name of a class or enumeration declared in a diﬀerent namespace. For example, namespace A { class X { }; extern "C" int extern "C++" int } namespace B { void X(int); extern "C" int extern "C++" int } using namespace A; using namespace B; void f() { X(1); g(); h(); }

g(); h();

g(); h(int);

// error: name X found in two namespaces // okay: name g refers to the same entity // okay: overload resolution selects A::h

7

— end note ] During overload resolution, all functions from the transitive search are considered for argument matching. The set of declarations found by the transitive search is unordered. [ Note: In particular, the order in which namespaces were considered and the relationships among the namespaces implied by the using-directives do not cause preference to be given to any of the declarations found by the search. — end note ] An ambiguity § 7.3.4 163

c ISO/IEC

N3337

exists if the best match ﬁnds two functions with the same signature, even if one is in a namespace reachable through using-directives in the namespace of the other.96 [ Example: namespace D { int d1; void f(char); } using namespace D; int d1; namespace E { int e; void f(int); } namespace D { // namespace extension int d2; using namespace E; void f(int); } void f() { d1++; ::d1++; D::d1++; d2++; e++; f(1); f(’a’); } // OK: no conﬂict with D::d1

// // // // // // //

error: ambiguous ::d1 or D::d1? OK OK OK: D::d2 OK: E::e error: ambiguous: D::f(int) or E::f(int)? OK: D::f(char)

— end example ]

7.4
1

The asm declaration asm-deﬁnition: asm ( string-literal ) ;

[dcl.asm]

An asm declaration has the form The asm declaration is conditionally-supported; its meaning is implementation-deﬁned. [ Note: Typically it is used to pass information through the implementation to an assembler. — end note ]

7.5
1

Linkage speciﬁcations

[dcl.link]

2

All function types, function names with external linkage, and variable names with external linkage have a language linkage. [ Note: Some of the properties associated with an entity with language linkage are speciﬁc to each implementation and are not described here. For example, a particular language linkage may be associated with a particular form of representing names of objects and functions with external linkage, or with a particular calling convention, etc. — end note ] The default language linkage of all function types, function names, and variable names is C++ language linkage. Two function types with diﬀerent language linkages are distinct types even if they are otherwise identical. Linkage (3.5) between C++ and non-C++ code fragments can be achieved using a linkage-speciﬁcation: linkage-speciﬁcation: extern string-literal { declaration-seqopt } extern string-literal declaration
96) During name lookup in a class hierarchy, some ambiguities may be resolved by considering whether one member hides the other along some paths (10.2). There is no such disambiguation when considering the set of names found as a result of following using-directives.

§ 7.5

164

c ISO/IEC

N3337

3

The string-literal indicates the required language linkage. This International Standard speciﬁes the semantics for the string-literals "C" and "C++". Use of a string-literal other than "C" or "C++" is conditionallysupported, with implementation-deﬁned semantics. [ Note: Therefore, a linkage-speciﬁcation with a stringliteral that is unknown to the implementation requires a diagnostic. — end note ] [ Note: It is recommended that the spelling of the string-literal be taken from the document deﬁning that language. For example, Ada (not ADA) and Fortran or FORTRAN, depending on the vintage. — end note ] Every implementation shall provide for linkage to functions written in the C programming language, "C", and linkage to C++ functions, "C++". [ Example: complex sqrt(complex); extern "C" { double sqrt(double); } // C++ linkage by default // C linkage

4

— end example ] Linkage speciﬁcations nest. When linkage speciﬁcations nest, the innermost one determines the language linkage. A linkage speciﬁcation does not establish a scope. A linkage-speciﬁcation shall occur only in namespace scope (3.3). In a linkage-speciﬁcation, the speciﬁed language linkage applies to the function types of all function declarators, function names with external linkage, and variable names with external linkage declared within the linkage-speciﬁcation. [ Example: extern "C" void f1(void(*pf)(int)); // the name f1 and its function type have C language // linkage; pf is a pointer to a C function extern "C" typedef void FUNC(); FUNC f2; // the name f2 has C++ language linkage and the // function’s type has C language linkage extern "C" FUNC f3; // the name of function f3 and the function’s type // have C language linkage void (*pf2)(FUNC*); // the name of the variable pf2 has C++ linkage and // the type of pf2 is pointer to C++ function that // takes one parameter of type pointer to C function extern "C" { static void f4(); // the name of the function f4 has // internal linkage (not C language // linkage) and the function’s type // has C language linkage. } extern "C" void f5() { extern void f4();

// // // //

OK: Name linkage (internal) and function type linkage (C language linkage) gotten from previous declaration.

} extern void f4(); // // // // OK: Name linkage (internal) and function type linkage (C language linkage) gotten from previous declaration.

} void f6() { extern void f4();

// OK: Name linkage (internal) // and function type linkage (C // language linkage) gotten from

§ 7.5

165

c ISO/IEC

N3337

// previous declaration. }

— end example ] A C language linkage is ignored in determining the language linkage of the names of class members and the function type of class member functions. [ Example: extern "C" typedef void FUNC_c(); class C { void mf1(FUNC_c*); // the name of the function mf1 and the member // function’s type have C++ language linkage; the // parameter has type pointer to C function FUNC_c mf2; // the name of the function mf2 and the member // function’s type have C++ language linkage static FUNC_c* q; // the name of the data member q has C++ language // linkage and the data member’s type is pointer to // C function }; extern "C" { class X { void mf(); void mf2(void(*)());

// // // // //

the name of the function mf and the member function’s type have C++ language linkage the name of the function mf2 has C++ language linkage; the parameter has type pointer to C function

}; }
5

6

— end example ] If two declarations declare functions with the same name and parameter-type-list (8.3.5) to be members of the same namespace or declare objects with the same name to be members of the same namespace and the declarations give the names diﬀerent language linkages, the program is ill-formed; no diagnostic is required if the declarations appear in diﬀerent translation units. Except for functions with C++ linkage, a function declaration without a linkage speciﬁcation shall not precede the ﬁrst linkage speciﬁcation for that function. A function can be declared without a linkage speciﬁcation after an explicit linkage speciﬁcation has been seen; the linkage explicitly speciﬁed in the earlier declaration is not aﬀected by such a function declaration. At most one function with a particular name can have C language linkage. Two declarations for a function with C language linkage with the same function name (ignoring the namespace names that qualify it) that appear in diﬀerent namespace scopes refer to the same function. Two declarations for a variable with C language linkage with the same name (ignoring the namespace names that qualify it) that appear in diﬀerent namespace scopes refer to the same variable. An entity with C language linkage shall not be declared with the same name as an entity in global scope, unless both declarations denote the same entity; no diagnostic is required if the declarations appear in diﬀerent translation units. A variable with C language linkage shall not be declared with the same name as a function with C language linkage (ignoring the namespace names that qualify the respective names); no diagnostic is required if the declarations appear in diﬀerent translation units. [ Note: Only one deﬁnition for an entity with a given name with C language linkage may appear in the program (see 3.2); this implies that such an entity must not be deﬁned in more than one namespace scope. — end note ] [ Example: int x; namespace A { extern "C" int extern "C" int extern "C" int extern "C" int

f(); g() { return 1; } h(); x();

// ill-formed: same name as global-space object x

§ 7.5

166

c ISO/IEC

N3337

} namespace B { extern "C" int f(); extern "C" int g() { return 1; } } int A::f() { return 98; } extern "C" int h() { return 97; } //deﬁnition for the function f with C language linkage // deﬁnition for the function h with C language linkage // A::h and ::h refer to the same function

// A::f and B::f refer to the same function // ill-formed, the function g // with C language linkage has two deﬁnitions

7

— end example ] A declaration directly contained in a linkage-speciﬁcation is treated as if it contains the extern speciﬁer (7.1.1) for the purpose of determining the linkage of the declared name and whether it is a deﬁnition. Such a declaration shall not specify a storage class. [ Example: extern "C" double f(); static double f(); extern "C" int i; extern "C" { int i; } extern "C" static void g(); // error // declaration // deﬁnition // error

8

9

— end example ] [ Note: Because the language linkage is part of a function type, when a pointer to C function (for example) is dereferenced, the function to which it refers is considered a C function. — end note ] Linkage from C++ to objects deﬁned in other languages and to objects deﬁned in C++ from other languages is implementation-deﬁned and language-dependent. Only where the object layout strategies of two language implementations are similar enough can such linkage be achieved.

7.6 7.6.1
1

Attributes Attribute syntax and semantics

[dcl.attr] [dcl.attr.grammar]

Attributes specify additional information for various source constructs such as types, variables, names, blocks, or translation units. attribute-speciﬁer-seq: attribute-speciﬁer-seqopt attribute-speciﬁer attribute-speciﬁer: [ [ attribute-list ] ] alignment-speciﬁer alignment-speciﬁer: alignas ( type-id ...opt ) alignas ( alignment-expression ...opt ) attribute-list: attributeopt attribute-list , attributeopt attribute ... attribute-list , attribute ... attribute: attribute-token attribute-argument-clauseopt attribute-token: identiﬁer attribute-scoped-token

§ 7.6.1

167

c ISO/IEC

N3337

attribute-scoped-token: attribute-namespace :: identiﬁer attribute-namespace: identiﬁer attribute-argument-clause: ( balanced-token-seq ) balanced-token-seq: balanced-tokenopt balanced-token-seq balanced-token balanced-token: ( balanced-token-seq ) [ balanced-token-seq ] { balanced-token-seq } any token other than a parenthesis, a bracket, or a brace
2 3

4

5 6

[ Note: For each individual attribute, the form of the balanced-token-seq will be speciﬁed. — end note ] In an attribute-list, an ellipsis may appear only if that attribute’s speciﬁcation permits it. An attribute followed by an ellipsis is a pack expansion (14.5.3). An attribute-speciﬁer that contains no attributes has no eﬀect. The order in which the attribute-tokens appear in an attribute-list is not signiﬁcant. If a keyword (2.12) or an alternative token (2.6) that satisﬁes the syntactic requirements of an identiﬁer (2.11) is contained in an attribute-token, it is considered an identiﬁer. No name lookup (3.4) is performed on any of the identiﬁers contained in an attribute-token. The attribute-token determines additional requirements on the attribute-argument-clause (if any). The use of an attribute-scoped-token is conditionally-supported, with implementation-deﬁned behavior. [ Note: Each implementation should choose a distinctive name for the attribute-namespace in an attribute-scoped-token. — end note ] Each attribute-speciﬁer-seq is said to appertain to some entity or statement, identiﬁed by the syntactic context where it appears (Clause 6, Clause 7, Clause 8). If an attribute-speciﬁer-seq that appertains to some entity or statement contains an attribute that is not allowed to apply to that entity or statement, the program is ill-formed. If an attribute-speciﬁer-seq appertains to a friend declaration (11.3), that declaration shall be a deﬁnition. No attribute-speciﬁer-seq shall appertain to an explicit instantiation (14.7.2). For an attribute-token not speciﬁed in this International Standard, the behavior is implementation-deﬁned. Two consecutive left square bracket tokens shall appear only when introducing an attribute-speciﬁer. [ Note: If two consecutive left square brackets appear where an attribute-speciﬁer is not allowed, the program is ill formed even if the brackets match an alternative grammar production. — end note ] [ Example: int p[10]; void f() { int x = 42, y[5]; int(p[[x] { return x; }()]);

y[[] { return 2; }()] = 2; }

// // // // //

error: malformed attribute on a nested declarator-id and not a function-style cast of an element of p. error even though attributes are not allowed in this context.

— end example ]

7.6.2
1

Alignment speciﬁer

[dcl.align]

2

An alignment-speciﬁer may be applied to a variable or to a class data member, but it shall not be applied to a bit-ﬁeld, a function parameter, the formal parameter of a catch clause (15.3), or a variable declared with the register storage class speciﬁer. An alignment-speciﬁer may also be applied to the declaration of a class or enumeration type. An alignment-speciﬁer with an ellipsis is a pack expansion (14.5.3). When the alignment-speciﬁer is of the form alignas( assignment-expression ): — the assignment-expression shall be an integral constant expression

§ 7.6.2

168

c ISO/IEC

N3337

— if the constant expression evaluates to a fundamental alignment, the alignment requirement of the declared entity shall be the speciﬁed fundamental alignment — if the constant expression evaluates to an extended alignment and the implementation supports that alignment in the context of the declaration, the alignment of the declared entity shall be that alignment — if the constant expression evaluates to an extended alignment and the implementation does not support that alignment in the context of the declaration, the program is ill-formed — if the constant expression evaluates to zero, the alignment speciﬁer shall have no eﬀect — otherwise, the program is ill-formed.
3

4

5

6

When the alignment-speciﬁer is of the form alignas( type-id ), it shall have the same eﬀect as alignas( alignof(type-id )) (5.3.6). When multiple alignment-speciﬁers are speciﬁed for an entity, the alignment requirement shall be set to the strictest speciﬁed alignment. The combined eﬀect of all alignment-speciﬁers in a declaration shall not specify an alignment that is less strict than the alignment that would be required for the entity being declared if all alignment-speciﬁers were omitted (including those in other declarations). If the deﬁning declaration of an entity has an alignment-speciﬁer, any non-deﬁning declaration of that entity shall either specify equivalent alignment or have no alignment-speciﬁer. Conversely, if any declaration of an entity has an alignment-speciﬁer, every deﬁning declaration of that entity shall specify an equivalent alignment. No diagnostic is required if declarations of an entity have diﬀerent alignment-speciﬁers in diﬀerent translation units. [ Example:
// Translation unit #1: struct S { int x; } s, p = &s; // Translation unit #2: struct alignas(16) S; extern S* p;

// error: deﬁnition of S lacks alignment; no // diagnostic required

7

— end example ] [ Example: An aligned buﬀer with an alignment requirement of A and holding N elements of type T other than char, signed char, or unsigned char can be declared as: alignas(T) alignas(A) T buffer[N];

8

Specifying alignas(T) ensures that the ﬁnal requested alignment will not be weaker than alignof(T), and therefore the program will not be ill-formed. — end example ] [ Example: alignas(double) void f(); alignas(double) unsigned char c[sizeof(double)]; extern unsigned char c[sizeof(double)]; alignas(float) extern unsigned char c[sizeof(double)]; // error: alignment applied to function // array of characters, suitably aligned for a double // no alignas necessary // error: diﬀerent alignment in declaration

— end example ]

7.6.3
1

Noreturn attribute

[dcl.attr.noreturn]

The attribute-token noreturn speciﬁes that a function does not return. It shall appear at most once in each attribute-list and no attribute-argument-clause shall be present. The attribute may be applied to the declarator-id in a function declaration. The ﬁrst declaration of a function shall specify the noreturn § 7.6.3 169

c ISO/IEC

N3337

2

3

attribute if any declaration of that function speciﬁes the noreturn attribute. If a function is declared with the noreturn attribute in one translation unit and the same function is declared without the noreturn attribute in another translation unit, the program is ill-formed; no diagnostic required. If a function f is called where f was previously declared with the noreturn attribute and f eventually returns, the behavior is undeﬁned. [ Note: The function may terminate by throwing an exception. — end note ] [ Note: Implementations are encouraged to issue a warning if a function marked [[noreturn]] might return. — end note ] [ Example:
[[ noreturn ]] void f() { throw "error"; // OK } [[ noreturn ]] void q(int i) { // behavior is undeﬁned if called with an argument 0) throw "positive"; }

— end example ]

7.6.4
1

Carries dependency attribute

[dcl.attr.depend]

2

3

4

The attribute-token carries_dependency speciﬁes dependency propagation into and out of functions. It shall appear at most once in each attribute-list and no attribute-argument-clause shall be present. The attribute may be applied to the declarator-id of a parameter-declaration in a function declaration or lambda, in which case it speciﬁes that the initialization of the parameter carries a dependency to (1.10) each lvalueto-rvalue conversion (4.1) of that object. The attribute may also be applied to the declarator-id of a function declaration, in which case it speciﬁes that the return value, if any, carries a dependency to the evaluation of the function call expression. The ﬁrst declaration of a function shall specify the carries_dependency attribute for its declarator-id if any declaration of the function speciﬁes the carries_dependency attribute. Furthermore, the ﬁrst declaration of a function shall specify the carries_dependency attribute for a parameter if any declaration of that function speciﬁes the carries_dependency attribute for that parameter. If a function or one of its parameters is declared with the carries_dependency attribute in its ﬁrst declaration in one translation unit and the same function or one of its parameters is declared without the carries_dependency attribute in its ﬁrst declaration in another translation unit, the program is ill-formed; no diagnostic required. [ Note: The carries_dependency attribute does not change the meaning of the program, but may result in generation of more eﬃcient code. — end note ] [ Example:
/∗ Translation unit A. ∗/ struct foo { int* a; int* b; }; std::atomic foo_head[10]; int foo_array[10][10]; [[carries_dependency]] struct foo* f(int i) { return foo_head[i].load(memory_order_consume); } [[carries_dependency]] int g(int* x, int* y) { return kill_dependency(foo_array[*x][*y]); } /∗ Translation unit B. ∗/

§ 7.6.4

170

c ISO/IEC

N3337

[[carries_dependency]] struct foo* f(int i); [[carries_dependency]] int* g(int* x, int* y); int c = 3; void h(int i) { struct foo* p; p = f(i); do_something_with(g(&c, p->a)); do_something_with(g(p->a, &c)); }
5

6

The carries_dependency attribute on function f means that the return value carries a dependency out of f, so that the implementation need not constrain ordering upon return from f. Implementations of f and its caller may choose to preserve dependencies instead of emitting hardware memory ordering instructions (a.k.a. fences). Function g’s second argument has a carries_dependency attribute, but its ﬁrst argument does not. Therefore, function h’s ﬁrst call to g carries a dependency into g, but its second call does not. The implementation might need to insert a fence prior to the second call to g. — end example ]

§ 7.6.4

171

c ISO/IEC

N3337

8
1

Declarators init-declarator-list: init-declarator init-declarator-list , init-declarator init-declarator: declarator initializeropt

[dcl.decl]

A declarator declares a single variable, function, or type, within a declaration. The init-declarator-list appearing in a declaration is a comma-separated sequence of declarators, each of which can have an initializer.

2

3 4

The three components of a simple-declaration are the attributes (7.6), the speciﬁers (decl-speciﬁer-seq; 7.1) and the declarators (init-declarator-list). The speciﬁers indicate the type, storage class or other properties of the entities being declared. The declarators specify the names of these entities and (optionally) modify the type of the speciﬁers with operators such as * (pointer to) and () (function returning). Initial values can also be speciﬁed in a declarator; initializers are discussed in 8.5 and 12.6. Each init-declarator in a declaration is analyzed separately as if it was in a declaration by itself.97 Declarators have the syntax declarator: ptr-declarator noptr-declarator parameters-and-qualiﬁers trailing-return-type ptr-declarator: noptr-declarator ptr-operator ptr-declarator noptr-declarator: declarator-id attribute-speciﬁer-seqopt noptr-declarator parameters-and-qualiﬁers noptr-declarator [ constant-expressionopt ] attribute-speciﬁer-seqopt ( ptr-declarator ) parameters-and-qualiﬁers: ( parameter-declaration-clause ) attribute-speciﬁer-seqopt cv-qualiﬁer-seqopt ref-qualiﬁeropt exception-speciﬁcationopt trailing-return-type: -> trailing-type-speciﬁer-seq abstract-declaratoropt
97) A declaration with several declarators is usually equivalent to the corresponding sequence of declarations each with a single declarator. That is T D1, D2, ... Dn; is usually equivalent to T D1; T D2; ... T Dn; where T is a decl-speciﬁer-seq and each Di is an init-declarator. An exception occurs when a name introduced by one of the declarators hides a type name used by the decl-speciﬁers, so that when the same decl-speciﬁers are used in a subsequent declaration, they do not have the same meaning, as in struct S ... ; S S, T; // declare two instances of struct S which is not equivalent to struct S ... ; S S; S T; // error Another exception occurs when T is auto (7.1.6.4), for example: auto i = 1, j = 2.0; // error: deduced types for i and j do not match as opposed to auto i = 1; // OK: i deduced to have type int auto j = 2.0; // OK: j deduced to have type double

Declarators

172

c ISO/IEC

N3337

ptr-operator: * attribute-speciﬁer-seqopt cv-qualiﬁer-seqopt & attribute-speciﬁer-seqopt && attribute-speciﬁer-seqopt nested-name-speciﬁer * attribute-speciﬁer-seqopt cv-qualiﬁer-seqopt cv-qualiﬁer-seq: cv-qualiﬁer cv-qualiﬁer-seqopt cv-qualiﬁer: const volatile ref-qualiﬁer: & && declarator-id: ...opt id-expression nested-name-speciﬁeropt class-name

5

A class-name has special meaning in a declaration of the class of that name and when qualiﬁed by that name using the scope resolution operator :: (5.1, 12.1, 12.4). The optional attribute-speciﬁer-seq in a trailing-return-type appertains to the indicated return type. The type-id in a trailing-return-type includes the longest possible sequence of abstract-declarators. [ Note: This resolves the ambiguous binding of array and function declarators. [ Example: auto f()->int(*)[4]; // function returning a pointer to array[4] of int // not function returning array[4] of pointer to int

— end example ] — end note ]

8.1
1

Type names

[dcl.name]

To specify type conversions explicitly, and as an argument of sizeof, alignof, new, or typeid, the name of a type shall be speciﬁed. This can be done with a type-id, which is syntactically a declaration for a variable or function of that type that omits the name of the entity. type-id: type-speciﬁer-seq abstract-declaratoropt abstract-declarator: ptr-abstract-declarator noptr-abstract-declaratoropt parameters-and-qualiﬁers trailing-return-type abstract-pack-declarator ptr-abstract-declarator: noptr-abstract-declarator ptr-operator ptr-abstract-declaratoropt noptr-abstract-declarator: noptr-abstract-declaratoropt parameters-and-qualiﬁers noptr-abstract-declaratoropt [ constant-expressionopt ] attribute-speciﬁer-seqopt ( ptr-abstract-declarator ) abstract-pack-declarator: noptr-abstract-pack-declarator ptr-operator abstract-pack-declarator noptr-abstract-pack-declarator: noptr-abstract-pack-declarator parameters-and-qualiﬁers noptr-abstract-pack-declarator [ constant-expressionopt ] attribute-speciﬁer-seqopt ...

It is possible to identify uniquely the location in the abstract-declarator where the identiﬁer would appear if the construction were a declarator in a declaration. The named type is then the same as the type of the hypothetical identiﬁer. [ Example: § 8.1 173

c ISO/IEC

N3337

int int int int int int

* *[3] (*)[3] *() (*)(double)

// // // // // //

int int int int int int

i *pi *p[3] (*p3i)[3] *f() (*pf)(double)

2

name respectively the types “int,” “pointer to int,” “array of 3 pointers to int,” “pointer to array of 3 int,” “function of (no parameters) returning pointer to int,” and “pointer to a function of (double) returning int.” — end example ] A type can also be named (often more easily) by using a typedef (7.1.3).

8.2
1

Ambiguity resolution

[dcl.ambig.res]

The ambiguity arising from the similarity between a function-style cast and a declaration mentioned in 6.8 can also occur in the context of a declaration. In that context, the choice is between a function declaration with a redundant set of parentheses around a parameter name and an object declaration with a function-style cast as the initializer. Just as for the ambiguities mentioned in 6.8, the resolution is to consider any construct that could possibly be a declaration a declaration. [ Note: A declaration can be explicitly disambiguated by a nonfunction-style cast, by an = to indicate initialization or by removing the redundant parentheses around the parameter name. — end note ] [ Example: struct S { S(int); }; void foo(double a) { S w(int(a)); // S x(int()); // S y((int)a); // S z = int(a); // }

function declaration function declaration object declaration object declaration

2

3

— end example ] The ambiguity arising from the similarity between a function-style cast and a type-id can occur in diﬀerent contexts. The ambiguity appears as a choice between a function-style cast expression and a declaration of a type. The resolution is that any construct that could possibly be a type-id in its syntactic context shall be considered a type-id. [ Example:
#include char *p; void *operator new(std::size_t, int); void foo() { const int x = 63; new (int(*p)) int; // new-placement expression new (int(*[x])); // new type-id }

4

For another example, template struct S { T *p; }; S x; S y;

// type-id // expression (ill-formed)

5

For another example, § 8.2 174

c ISO/IEC

N3337

void foo() { sizeof(int(1)); sizeof(int()); }
6

// expression // type-id (ill-formed)

For another example, void foo() { (int(1)); (int())1; } // expression // type-id (ill-formed)

7

— end example ] Another ambiguity arises in a parameter-declaration-clause of a function declaration, or in a type-id that is the operand of a sizeof or typeid operator, when a type-name is nested in parentheses. In this case, the choice is between the declaration of a parameter of type pointer to function and the declaration of a parameter with redundant parentheses around the declarator-id. The resolution is to consider the type-name as a simple-type-speciﬁer rather than a declarator-id. [ Example: class C { }; void f(int(C)) { } // void f(int(*fp)(C c)) { } // not: void f(int C);

int g(C); void foo() { f(1); f(g); }

// error: cannot convert 1 to function pointer // OK

For another example, class C { }; void h(int *(C[10])); // void h(int *(*_fp)(C _parm[10])); // not: void h(int *C[10]);

— end example ]

8.3
1

Meaning of declarators

[dcl.meaning]

A list of declarators appears after an optional (Clause 7) decl-speciﬁer-seq (7.1). Each declarator contains exactly one declarator-id; it names the identiﬁer that is declared. An unqualiﬁed-id occurring in a declaratorid shall be a simple identiﬁer except for the declaration of some special functions (12.3, 12.4, 13.5) and for the declaration of template specializations or partial specializations (14.7). A declarator-id shall not be qualiﬁed except for the deﬁnition of a member function (9.3) or static data member (9.4) outside of its class, the deﬁnition or explicit instantiation of a function or variable member of a namespace outside of its namespace, or the deﬁnition of an explicit specialization outside of its namespace, or the declaration of a friend function that is a member of another class or namespace (11.3). When the declarator-id is qualiﬁed, the declaration shall refer to a previously declared member of the class or namespace to which the qualiﬁer refers (or, in the case of a namespace, of an element of the inline namespace set of that namespace (7.3.1)) or to a specialization thereof; the member shall not merely have been introduced by a using-declaration in the scope of the class or namespace nominated by the nested-name-speciﬁer of the declarator-id. The nested-name-speciﬁer of a qualiﬁed declarator-id shall not begin with a decltype-speciﬁer. [ Note: If the qualiﬁer is the global :: scope resolution operator, the declarator-id refers to a name declared in the global namespace scope. — end note ] The optional attribute-speciﬁer-seq following a declarator-id appertains to the entity that is declared.

§ 8.3

175

c ISO/IEC

N3337

2

3

A static, thread_local, extern, register, mutable, friend, inline, virtual, or typedef speciﬁer applies directly to each declarator-id in an init-declarator-list; the type speciﬁed for each declarator-id depends on both the decl-speciﬁer-seq and its declarator. Thus, a declaration of a particular identiﬁer has the form
T D

4

where T is of the form attribute-speciﬁer-seqopt decl-speciﬁer-seq and D is a declarator. Following is a recursive procedure for determining the type speciﬁed for the contained declarator-id by such a declaration. First, the decl-speciﬁer-seq determines a type. In a declaration
T D

the decl-speciﬁer-seq T determines the type T. [ Example: in the declaration int unsigned i;
5

6

the type speciﬁers int unsigned determine the type “unsigned int” (7.1.6.2). — end example ] In a declaration attribute-speciﬁer-seqopt T D where D is an unadorned identiﬁer the type of this identiﬁer is “T”. In a declaration T D where D has the form
( D1 )

the type of the contained declarator-id is the same as that of the contained declarator-id in the declaration
T D1

Parentheses do not alter the type of the embedded declarator-id, but they can alter the binding of complex declarators.

8.3.1
1

Pointers
* attribute-speciﬁer-seqopt cv-qualiﬁer-seqopt D1

[dcl.ptr]

In a declaration T D where D has the form and the type of the identiﬁer in the declaration T D1 is “derived-declarator-type-list T,” then the type of the identiﬁer of D is “derived-declarator-type-list cv-qualiﬁer-seq pointer to T.” The cv-qualiﬁers apply to the pointer and not to the object pointed to. Similarly, the optional attribute-speciﬁer-seq (7.6.1) appertains to the pointer and not to the object pointed to. [ Example: the declarations const int ci = 10, *pc = &ci, *const cpc = pc, **ppc; int i, *p, *const cp = &i;

2

declare ci, a constant integer; pc, a pointer to a constant integer; cpc, a constant pointer to a constant integer; ppc, a pointer to a pointer to a constant integer; i, an integer; p, a pointer to integer; and cp, a constant pointer to integer. The value of ci, cpc, and cp cannot be changed after initialization. The value of pc can be changed, and so can the object pointed to by cp. Examples of some correct operations are i = ci; *cp = ci; pc++; pc = cpc; pc = p; ppc = &pc;

Examples of ill-formed operations are ci = 1; ci++; *pc = 2; cp = &ci; // // // // error error error error

§ 8.3.1

176

c ISO/IEC

N3337

cpc++; p = pc; ppc = &p;

// error // error // error

Each is unacceptable because it would either change the value of an object declared const or allow it to be changed through a cv-unqualiﬁed pointer later, for example:
*ppc = &ci; *p = 5;
3 4

// OK, but would make p point to ci ... // ... because of previous error // clobber ci

— end example ] See also 5.17 and 8.5. [ Note: There are no pointers to references; see 8.3.2. Since the address of a bit-ﬁeld (9.6) cannot be taken, a pointer can never point to a bit-ﬁeld. — end note ]

8.3.2
1

References
& attribute-speciﬁer-seqopt D1 && attribute-speciﬁer-seqopt D1

[dcl.ref]

In a declaration T D where D has either of the forms and the type of the identiﬁer in the declaration T D1 is “derived-declarator-type-list T,” then the type of the identiﬁer of D is “derived-declarator-type-list reference to T.” The optional attribute-speciﬁer-seq appertains to the reference type. Cv-qualiﬁed references are ill-formed except when the cv-qualiﬁers are introduced through the use of a typedef (7.1.3) or of a template type argument (14.3), in which case the cv-qualiﬁers are ignored. [ Example: typedef int& A; const A aref = 3; // ill-formed; lvalue reference to non-const initialized with rvalue

2

3

The type of aref is “lvalue reference to int”, not “lvalue reference to const int”. — end example ] [ Note: A reference can be thought of as a name of an object. — end note ] A declarator that speciﬁes the type “reference to cv void” is ill-formed. A reference type that is declared using & is called an lvalue reference, and a reference type that is declared using && is called an rvalue reference. Lvalue references and rvalue references are distinct types. Except where explicitly noted, they are semantically equivalent and commonly referred to as references. [ Example: void f(double& a) { a += 3.14; } // ... double d = 0; f(d);

declares a to be a reference parameter of f so the call f(d) will add 3.14 to d. int v[20]; // ... int& g(int i) { return v[i]; } // ... g(3) = 7;

declares the function g() to return a reference to an integer so g(3)=7 will assign 7 to the fourth element of the array v. For another example, struct link { link* next; }; link* first;

§ 8.3.2

177

c ISO/IEC

N3337

void h(link*& p) { p->next = first; first = p; p = 0; }

// p is a reference to pointer

void k() { link* q = new link; h(q); }

4 5

6

declares p to be a reference to a pointer to link so h(q) will leave q with the value zero. See also 8.5.3. — end example ] It is unspeciﬁed whether or not a reference requires storage (3.7). There shall be no references to references, no arrays of references, and no pointers to references. The declaration of a reference shall contain an initializer (8.5.3) except when the declaration contains an explicit extern speciﬁer (7.1.1), is a class member (9.2) declaration within a class deﬁnition, or is the declaration of a parameter or a return type (8.3.5); see 3.1. A reference shall be initialized to refer to a valid object or function. [ Note: in particular, a null reference cannot exist in a well-deﬁned program, because the only way to create such a reference would be to bind it to the “object” obtained by dereferencing a null pointer, which causes undeﬁned behavior. As described in 9.6, a reference cannot be bound directly to a bit-ﬁeld. — end note ] If a typedef (7.1.3), a type template-parameter (14.3.1), or a decltype-speciﬁer (7.1.6.2) denotes a type TR that is a reference to a type T, an attempt to create the type “lvalue reference to cv TR” creates the type “lvalue reference to T”, while an attempt to create the type “rvalue reference to cv TR” creates the type TR. [ Example: int i; typedef int& LRI; typedef int&& RRI; LRI& r1 = i; const LRI& r2 = i; const LRI&& r3 = i; RRI& r4 = i; RRI&& r5 = 5; decltype(r2)& r6 = i; decltype(r2)&& r7 = i; // r1 has the type int& // r2 has the type int& // r3 has the type int& // r4 has the type int& // r5 has the type int&& // r6 has the type int& // r7 has the type int&

— end example ]

8.3.3
1

Pointers to members nested-name-speciﬁer * attribute-speciﬁer-seqopt cv-qualiﬁer-seqopt D1

[dcl.mptr]

In a declaration T D where D has the form and the nested-name-speciﬁer denotes a class, and the type of the identiﬁer in the declaration T D1 is “derived-declarator-type-list T”, then the type of the identiﬁer of D is “derived-declarator-type-list cv-qualiﬁerseq pointer to member of class nested-name-speciﬁer of type T”. The optional attribute-speciﬁer-seq (7.6.1) appertains to the pointer-to-member. [ Example: struct X { void f(int); int a; };

2

§ 8.3.3

178

c ISO/IEC

N3337

struct Y; int X::* pmi = &X::a; void (X::* pmf)(int) = &X::f; double X::* pmd; char Y::* pmc;

declares pmi, pmf, pmd and pmc to be a pointer to a member of X of type int, a pointer to a member of X of type void(int), a pointer to a member of X of type double and a pointer to a member of Y of type char respectively. The declaration of pmd is well-formed even though X has no members of type double. Similarly, the declaration of pmc is well-formed even though Y is an incomplete type. pmi and pmf can be used like this:
X obj; // ... obj.*pmi = 7; (obj.*pmf)(7);

// // // //

assign 7 to an integer member of obj call a function member of obj with the argument 7

3

— end example ] A pointer to member shall not point to a static member of a class (9.4), a member with reference type, or “cv void.” [ Note: See also 5.3 and 5.5. The type “pointer to member” is distinct from the type “pointer”, that is, a pointer to member is declared only by the pointer to member declarator syntax, and never by the pointer declarator syntax. There is no “reference-to-member” type in C++. — end note ]

8.3.4
1

Arrays
D1 [ constant-expressionopt ] attribute-speciﬁer-seqopt

[dcl.array]

In a declaration T D where D has the form and the type of the identiﬁer in the declaration T D1 is “derived-declarator-type-list T”, then the type of the identiﬁer of D is an array type; if the type of the identiﬁer of D contains the auto type-speciﬁer, the program is ill-formed. T is called the array element type; this type shall not be a reference type, the (possibly cv-qualiﬁed) type void, a function type or an abstract class type. If the constant-expression (5.19) is present, it shall be an integral constant expression and its value shall be greater than zero. The constant expression speciﬁes the bound of (number of elements in) the array. If the value of the constant expression is N, the array has N elements numbered 0 to N-1, and the type of the identiﬁer of D is “derived-declarator-type-list array of N T”. An object of array type contains a contiguously allocated non-empty set of N subobjects of type T. Except as noted below, if the constant expression is omitted, the type of the identiﬁer of D is “derived-declarator-typelist array of unknown bound of T”, an incomplete object type. The type “derived-declarator-type-list array of N T” is a diﬀerent type from the type “derived-declarator-type-list array of unknown bound of T”, see 3.9. Any type of the form “cv-qualiﬁer-seq array of N T” is adjusted to “array of N cv-qualiﬁer-seq T”, and similarly for “array of unknown bound of T”. The optional attribute-speciﬁer-seq appertains to the array. [ Example: typedef int A[5], AA[2][3]; typedef const A CA; typedef const AA CAA; // type is “array of 5 const int” // type is “array of 2 array of 3 const int”

2

3

— end example ] [ Note: An “array of N cv-qualiﬁer-seq T” has cv-qualiﬁed type; see 3.9.3. — end note ] An array can be constructed from one of the fundamental types (except void), from a pointer, from a pointer to member, from a class, from an enumeration type, or from another array. When several “array of” speciﬁcations are adjacent, a multidimensional array is created; only the ﬁrst of the constant expressions that specify the bounds of the arrays may be omitted. In addition to declarations in which an incomplete object type is allowed, an array bound may be omitted in some cases in the declaration of a function parameter (8.3.5). An array bound may also be omitted when the declarator is followed by an § 8.3.4 179

c ISO/IEC

N3337

4

initializer (8.5). In this case the bound is calculated from the number of initial elements (say, N) supplied (8.5.1), and the type of the identiﬁer of D is “array of N T.” Furthermore, if there is a preceding declaration of the entity in the same scope in which the bound was speciﬁed, an omitted array bound is taken to be the same as in that earlier declaration, and similarly for the deﬁnition of a static data member of a class. [ Example: float fa[17], *afp[17];

declares an array of float numbers and an array of pointers to float numbers. For another example, static int x3d[3][5][7];

declares a static three-dimensional array of integers, with rank 3×5×7. In complete detail, x3d is an array of three items; each item is an array of ﬁve arrays; each of the latter arrays is an array of seven integers. Any of the expressions x3d, x3d[i], x3d[i][j], x3d[i][j][k] can reasonably appear in an expression. Finally, extern int x[10]; struct S { static int y[10]; }; int x[]; int S::y[]; void f() { extern int x[]; int i = sizeof(x); }
5

// OK: bound is 10 // OK: bound is 10

// error: incomplete object type

6

7

8

— end example ] [ Note: conversions aﬀecting expressions of array type are described in 4.2. Objects of array types cannot be modiﬁed, see 3.10. — end note ] [ Note: Except where it has been declared for a class (13.5.5), the subscript operator [] is interpreted in such a way that E1[E2] is identical to *((E1)+(E2)). Because of the conversion rules that apply to +, if E1 is an array and E2 an integer, then E1[E2] refers to the E2-th member of E1. Therefore, despite its asymmetric appearance, subscripting is a commutative operation. A consistent rule is followed for multidimensional arrays. If E is an n-dimensional array of rank i×j ×. . .×k, then E appearing in an expression that is subject to the array-to-pointer conversion (4.2) is converted to a pointer to an (n − 1)-dimensional array with rank j × . . . × k. If the * operator, either explicitly or implicitly as a result of subscripting, is applied to this pointer, the result is the pointed-to (n − 1)-dimensional array, which itself is immediately converted into a pointer. [ Example: consider int x[3][5];

Here x is a 3 × 5 array of integers. When x appears in an expression, it is converted to a pointer to (the ﬁrst of three) ﬁve-membered arrays of integers. In the expression x[i] which is equivalent to *(x+i), x is ﬁrst converted to a pointer as described; then x+i is converted to the type of x, which involves multiplying i by the length of the object to which the pointer points, namely ﬁve integer objects. The results are added and indirection applied to yield an array (of ﬁve integers), which in turn is converted to a pointer to the ﬁrst of the integers. If there is another subscript the same argument applies again; this time the result is an integer. — end example ] — end note ]

§ 8.3.4

180

c ISO/IEC

N3337

9

[ Note: It follows from all this that arrays in C++ are stored row-wise (last subscript varies fastest) and that the ﬁrst subscript in the declaration helps determine the amount of storage consumed by an array but plays no other part in subscript calculations. — end note ]

8.3.5
1

Functions
D1 ( parameter-declaration-clause ) cv-qualiﬁer-seqopt ref-qualiﬁeropt exception-speciﬁcationopt attribute-speciﬁer-seqopt

[dcl.fct]

In a declaration T D where D has the form

2

and the type of the contained declarator-id in the declaration T D1 is “derived-declarator-type-list T”, the type of the declarator-id in D is “derived-declarator-type-list function of (parameter-declaration-clause ) cvqualiﬁer-seqopt ref-qualiﬁeropt returning T”. The optional attribute-speciﬁer-seq appertains to the function type. In a declaration T D where D has the form
D1 ( parameter-declaration-clause ) cv-qualiﬁer-seqopt ref-qualiﬁeropt exception-speciﬁcationopt attribute-speciﬁer-seqopt trailing-return-type

3

and the type of the contained declarator-id in the declaration T D1 is “derived-declarator-type-list T”, T shall be the single type-speciﬁer auto. The type of the declarator-id in D is “derived-declarator-type-list function of (parameter-declaration-clause) cv-qualiﬁer-seq opt ref-qualiﬁer opt returning trailing-return-type”. The optional attribute-speciﬁer-seq appertains to the function type. A type of either form is a function type.98 parameter-declaration-clause: parameter-declaration-listopt ...opt parameter-declaration-list , ... parameter-declaration-list: parameter-declaration parameter-declaration-list , parameter-declaration parameter-declaration: attribute-speciﬁer-seqopt decl-speciﬁer-seq declarator attribute-speciﬁer-seqopt decl-speciﬁer-seq declarator = initializer-clause attribute-speciﬁer-seqopt decl-speciﬁer-seq abstract-declaratoropt attribute-speciﬁer-seqopt decl-speciﬁer-seq abstract-declaratoropt = initializer-clause

4

The optional attribute-speciﬁer-seq in a parameter-declaration appertains to the parameter. The parameter-declaration-clause determines the arguments that can be speciﬁed, and their processing, when the function is called. [ Note: the parameter-declaration-clause is used to convert the arguments speciﬁed on the function call; see 5.2.2. — end note ] If the parameter-declaration-clause is empty, the function takes no arguments. The parameter list (void) is equivalent to the empty parameter list. Except for this special case, void shall not be a parameter type (though types derived from void, such as void*, can). If the parameter-declaration-clause terminates with an ellipsis or a function parameter pack (14.5.3), the number of arguments shall be equal to or greater than the number of parameters that do not have a default argument and are not function parameter packs. Where syntactically correct and where “...” is not part of an abstract-declarator, “, ...” is synonymous with “...”. [ Example: the declaration int printf(const char*, ...);

declares a function that can be called with varying numbers and types of arguments. printf("hello world"); printf("a=%d b=%d", a, b);

5

However, the ﬁrst argument must be of a type that can be converted to a const char* — end example ] [ Note: The standard header contains a mechanism for accessing arguments passed using the ellipsis (see 5.2.2 and 18.10). — end note ] A single name can be used for several diﬀerent functions in a single scope; this is function overloading (Clause 13). All declarations for a function shall agree exactly in both the return type and the parametertype-list. The type of a function is determined using the following rules. The type of each parameter
98) As indicated by syntax, cv-qualiﬁers are a signiﬁcant component in function return types.

§ 8.3.5

181

c ISO/IEC

N3337

6

(including function parameter packs) is determined from its own decl-speciﬁer-seq and declarator. After determining the type of each parameter, any parameter of type “array of T” or “function returning T” is adjusted to be “pointer to T” or “pointer to function returning T,” respectively. After producing the list of parameter types, any top-level cv-qualiﬁers modifying a parameter type are deleted when forming the function type. The resulting list of transformed parameter types and the presence or absence of the ellipsis or a function parameter pack is the function’s parameter-type-list. [ Note: This transformation does not aﬀect the types of the parameters. For example, int(*)(const int p, decltype(p)*) and int(*)(int, const int*) are identical types. — end note ] A cv-qualiﬁer-seq or a ref-qualiﬁer shall only be part of: — the function type for a non-static member function, — the function type to which a pointer to member refers, — the top-level function type of a function typedef declaration or alias-declaration, — the type-id in the default argument of a type-parameter (14.1), or — the type-id of a template-argument for a type-parameter (14.2). The eﬀect of a cv-qualiﬁer-seq in a function declarator is not the same as adding cv-qualiﬁcation on top of the function type. In the latter case, the cv-qualiﬁers are ignored. [ Note: a function type that has a cv-qualiﬁer-seq is not a cv-qualiﬁed type; there are no cv-qualiﬁed function types. — end note ] [ Example: typedef void F(); struct S { const F f; };

// OK: equivalent to: void f();

7

— end example ] The return type, the parameter-type-list, the ref-qualiﬁer, and the cv-qualiﬁer-seq, but not the default arguments (8.3.6) or the exception speciﬁcation (15.4), are part of the function type. [ Note: Function types are checked during the assignments and initializations of pointers to functions, references to functions, and pointers to member functions. — end note ] [ Example: the declaration int fseek(FILE*, long, int);

8

9

10

declares a function taking three arguments of the speciﬁed types, and returning int (7.1.6). — end example ] If the type of a parameter includes a type of the form “pointer to array of unknown bound of T” or “reference to array of unknown bound of T,” the program is ill-formed.99 Functions shall not have a return type of type array or function, although they may have a return type of type pointer or reference to such things. There shall be no arrays of functions, although there can be arrays of pointers to functions. Types shall not be deﬁned in return or parameter types. The type of a parameter or the return type for a function deﬁnition shall not be an incomplete class type (possibly cv-qualiﬁed) unless the function deﬁnition is nested within the member-speciﬁcation for that class (including deﬁnitions in nested classes deﬁned within the class). A typedef of function type may be used to declare a function but shall not be used to deﬁne a function (8.4). [ Example: typedef void F(); F fv; F fv { } void fv() { } // OK: equivalent to void fv(); // ill-formed // OK: deﬁnition of fv

99) This excludes parameters of type “ptr-arr-seq T2” where T2 is “pointer to array of unknown bound of T” and where ptrarr-seq means any sequence of “pointer to” and “array of” derived declarator types. This exclusion applies to the parameters

of the function, and if a parameter is a pointer to function or pointer to member function then to its parameters also, etc.

§ 8.3.5

182

c ISO/IEC

N3337

— end example ] A typedef of a function type whose declarator includes a cv-qualiﬁer-seq shall be used only to declare the function type for a non-static member function, to declare the function type to which a pointer to member refers, or to declare the top-level function type of another function typedef declaration. [ Example: typedef int FIC(int) const; FIC f; // ill-formed: does not declare a member function struct S { FIC f; // OK }; FIC S::*pm = &S::f; // OK
11

12

— end example ] An identiﬁer can optionally be provided as a parameter name; if present in a function deﬁnition (8.4), it names a parameter (sometimes called “formal argument”). [ Note: In particular, parameter names are also optional in function deﬁnitions and names used for a parameter in diﬀerent declarations and the deﬁnition of a function need not be the same. If a parameter name is present in a function declaration that is not a deﬁnition, it cannot be used outside of its function declarator because that is the extent of its potential scope (3.3.4). — end note ] [ Example: the declaration int i, *pi, f(), *fpi(int), (*pif)(const char*, const char*), (*fpif(int))(int);

declares an integer i, a pointer pi to an integer, a function f taking no arguments and returning an integer, a function fpi taking an integer argument and returning a pointer to an integer, a pointer pif to a function which takes two pointers to constant characters and returns an integer, a function fpif taking an integer argument and returning a pointer to a function that takes an integer argument and returns an integer. It is especially useful to compare fpi and pif. The binding of *fpi(int) is *(fpi(int)), so the declaration suggests, and the same construction in an expression requires, the calling of a function fpi, and then using indirection through the (pointer) result to yield an integer. In the declarator (*pif)(const char*, const char*), the extra parentheses are necessary to indicate that indirection through a pointer to a function yields a function, which is then called. — end example ] [ Note: Typedefs and trailing-return-types are sometimes convenient when the return type of a function is complex. For example, the function fpif above could have been declared typedef int IFUNC(int); IFUNC* fpif(int);

or auto fpif(int)->int(*)(int)

A trailing-return-type is most useful for a type that would be more complicated to specify before the declarator-id: template auto add(T t, U u) -> decltype(t + u);

rather than template decltype((*(T*)0) + (*(U*)0)) add(T t, U u);
13

— end note ] A declarator-id or abstract-declarator containing an ellipsis shall only be used in a parameter-declaration. Such a parameter-declaration is a parameter pack (14.5.3). When it is part of a parameter-declaration-clause, § 8.3.5 183

c ISO/IEC

N3337

the parameter pack is a function parameter pack (14.5.3). [ Note: Otherwise, the parameter-declaration is part of a template-parameter-list and the parameter pack is a template parameter pack; see 14.1. — end note ] A function parameter pack is a pack expansion (14.5.3). [ Example: template void f(T (* ...t)(int, int)); int add(int, int); float subtract(int, int); void g() { f(add, subtract); }
14

— end example ] There is a syntactic ambiguity when an ellipsis occurs at the end of a parameter-declaration-clause without a preceding comma. In this case, the ellipsis is parsed as part of the abstract-declarator if the type of the parameter names a template parameter pack that has not been expanded; otherwise, it is parsed as part of the parameter-declaration-clause.100

8.3.6
1

Default arguments

[dcl.fct.default]

2

If an initializer-clause is speciﬁed in a parameter-declaration this initializer-clause is used as a default argument. Default arguments will be used in calls where trailing arguments are missing. [ Example: the declaration void point(int = 3, int = 4);

declares a function that can be called with zero, one, or two arguments of type int. It can be called in any of these ways: point(1,2); 3

point(1);

point();

4

The last two calls are equivalent to point(1,4) and point(3,4), respectively. — end example ] A default argument shall be speciﬁed only in the parameter-declaration-clause of a function declaration or in a template-parameter (14.1); in the latter case, the initializer-clause shall be an assignment-expression. A default argument shall not be speciﬁed for a parameter pack. If it is speciﬁed in a parameter-declarationclause, it shall not occur within a declarator or abstract-declarator of a parameter-declaration.101 For non-template functions, default arguments can be added in later declarations of a function in the same scope. Declarations in diﬀerent scopes have completely distinct sets of default arguments. That is, declarations in inner scopes do not acquire default arguments from declarations in outer scopes, and vice versa. In a given function declaration, each parameter subsequent to a parameter with a default argument shall have a default argument supplied in this or a previous declaration or shall be a function parameter pack. A default argument shall not be redeﬁned by a later declaration (not even to the same value). [ Example: void g(int = 0, ...); void f(int, int); void f(int, int = 7); void h() { f(3); void f(int = 1, int); // OK, ellipsis is not a parameter so it can follow // a parameter with a default argument

// OK, calls f(3, 7) // error: does not use default // from surrounding scope

100) One can explicitly disambiguate the parse either by introducing a comma (so the ellipsis will be parsed as part of the parameter-declaration-clause) or by introducing a name for the parameter (so the ellipsis will be parsed as part of the declaratorid). 101) This means that default arguments cannot appear, for example, in declarations of pointers to functions, references to functions, or typedef declarations.

§ 8.3.6

184

c ISO/IEC

N3337

} void m() { void f(int, int); f(4); void f(int, int = 5); f(4); void f(int, int = 5); } void n() { f(6); }

// // // // // //

has no defaults error: wrong number of arguments OK OK, calls f(4, 5); error: cannot redeﬁne, even to same value

// OK, calls f(6, 7)

5

— end example ] For a given inline function deﬁned in diﬀerent translation units, the accumulated sets of default arguments at the end of the translation units shall be the same; see 3.2. If a friend declaration speciﬁes a default argument expression, that declaration shall be a deﬁnition and shall be the only declaration of the function or function template in the translation unit. A default argument is implicitly converted (Clause 4) to the parameter type. The default argument has the same semantic constraints as the initializer in a declaration of a variable of the parameter type, using the copy-initialization semantics (8.5). The names in the default argument are bound, and the semantic constraints are checked, at the point where the default argument appears. Name lookup and checking of semantic constraints for default arguments in function templates and in member functions of class templates are performed as described in 14.7.1. [ Example: in the following code, g will be called with the value f(2): int a = 1; int f(int); int g(int x = f(a)); void h() { a = 2; { int a = 3; g(); } }

// default argument: f(::a)

// g(f(::a))

6

— end example ] [ Note: In member function declarations, names in default arguments are looked up as described in 3.4.1. Access checking applies to names in default arguments as described in Clause 11. — end note ] Except for member functions of class templates, the default arguments in a member function deﬁnition that appears outside of the class deﬁnition are added to the set of default arguments provided by the member function declaration in the class deﬁnition. Default arguments for a member function of a class template shall be speciﬁed on the initial declaration of the member function within the class template. [ Example: class C { void f(int i = 3); void g(int i, int j = 99); }; void C::f(int i = 3) { } void C::g(int i = 88, int j) { } // // // // error: default argument already speciﬁed in class scope in this translation unit, C::g can be called with no argument

7

— end example ] Local variables shall not be used in a default argument. [ Example: § 8.3.6 185

c ISO/IEC

N3337

void f() { int i; extern void g(int x = i); // ... }
8

//error

— end example ] The keyword this shall not be used in a default argument of a member function. [ Example: class A { void f(A* p = this) { } }; // error

9

— end example ] Default arguments are evaluated each time the function is called. The order of evaluation of function arguments is unspeciﬁed. Consequently, parameters of a function shall not be used in a default argument, even if they are not evaluated. Parameters of a function declared before a default argument are in scope and can hide namespace and class member names. [ Example: int a; int f(int a, int b = a); typedef int I; int g(float I, int b = I(2)); int h(int a, int b = sizeof(a)); // error: parameter a // used as default argument // error: parameter I found // error, parameter a used // in default argument

— end example ] Similarly, a non-static member shall not be used in a default argument, even if it is not evaluated, unless it appears as the id-expression of a class member access expression (5.2.5) or unless it is used to form a pointer to member (5.3.1). [ Example: the declaration of X::mem1() in the following example is ill-formed because no object is supplied for the non-static member X::a used as an initializer. int b; class X { int a; int mem1(int i = a); int mem2(int i = b); static int b; };

// error: non-static member a // used as default argument // OK; use X::b

The declaration of X::mem2() is meaningful, however, since no object is needed to access the static member X::b. Classes, objects, and members are described in Clause 9. — end example ] A default argument is not part of the type of a function. [ Example: int f(int = 0); void h() { int j = f(1); int k = f(); } int (*p1)(int) = &f; int (*p2)() = &f;

// OK, means f(0)

// error: type mismatch

— end example ] When a declaration of a function is introduced by way of a using-declaration (7.3.3), any default argument information associated with the declaration is made known as well. If the function is

§ 8.3.6

186

c ISO/IEC

N3337

10

redeclared thereafter in the namespace with additional default arguments, the additional arguments are also known at any point following the redeclaration where the using-declaration is in scope. A virtual function call (10.3) uses the default arguments in the declaration of the virtual function determined by the static type of the pointer or reference denoting the object. An overriding function in a derived class does not acquire default arguments from the function it overrides. [ Example: struct A { virtual void f(int a = 7); }; struct B : public A { void f(int a); }; void m() { B* pb = new B; A* pa = pb; pa->f(); // OK, calls pa->B::f(7) pb->f(); // error: wrong number of arguments for B::f() }

— end example ]

8.4 8.4.1
1

Function deﬁnitions In general

[dcl.fct.def] [dcl.fct.def.general]

Function deﬁnitions have the form function-deﬁnition: attribute-speciﬁer-seqopt decl-speciﬁer-seqopt declarator virt-speciﬁer-seqopt function-body function-body: ctor-initializeropt compound-statement function-try-block = default ; = delete ;

2

Any informal reference to the body of a function should be interpreted as a reference to the non-terminal function-body. The optional attribute-speciﬁer-seq in a function-deﬁnition appertains to the function. A virt-speciﬁer-seq can be part of a function-deﬁnition only if it is a member-declaration (9.2). The declarator in a function-deﬁnition shall have the form
D1 ( parameter-declaration-clause ) cv-qualiﬁer-seqopt ref-qualiﬁeropt exception-speciﬁcationopt attribute-speciﬁer-seqopt trailing-return-typeopt

3

as described in 8.3.5. A function shall be deﬁned only in namespace or class scope. [ Example: a simple example of a complete function deﬁnition is int max(int a, int b, int c) { int m = (a > b) ? a : b; return (m > c) ? m : c; }

4 5

6

Here int is the decl-speciﬁer-seq; max(int a, int b, int c) is the declarator; { /* ... */ } is the function-body. — end example ] A ctor-initializer is used only in a constructor; see 12.1 and 12.6. A cv-qualiﬁer-seq or a ref-qualiﬁer (or both) can be part of a non-static member function declaration, non-static member function deﬁnition, or pointer to member function only (8.3.5); see 9.3.2. [ Note: Unused parameters need not be named. For example, void print(int a, int) { std::printf("a = %d\n",a); }

§ 8.4.1

187

c ISO/IEC

N3337

7

8

— end note ] In the function-body, a function-local predeﬁned variable denotes a block-scope object of static storage duration that is implicitly deﬁned (see 3.3.3). The function-local predeﬁned variable __func__ is deﬁned as if a deﬁnition of the form static const char __func__[] = "function-name ";

had been provided, where function-name is an implementation-deﬁned string. It is unspeciﬁed whether such a variable has an address distinct from that of any other object in the program.102 [ Example: struct S { S() : s(__func__) { } const char *s; }; void f(const char * s = __func__); // OK

// error: __func__ is undeclared

— end example ]

8.4.2
1

Explicitly-defaulted functions attribute-speciﬁer-seqopt decl-speciﬁer-seqopt declarator = default ;

[dcl.fct.def.default]

A function deﬁnition of the form: is called an explicitly-defaulted deﬁnition. A function that is explicitly defaulted shall — be a special member function, — have the same declared function type (except for possibly diﬀering ref-qualiﬁers and except that in the case of a copy constructor or copy assignment operator, the parameter type may be “reference to non-const T”, where T is the name of the member function’s class) as if it had been implicitly declared, and — not have default arguments.

2

An explicitly-defaulted function may be declared constexpr only if it would have been implicitly declared as constexpr, and may have an explicit exception-speciﬁcation only if it is compatible (15.4) with the exceptionspeciﬁcation on the implicit declaration. If a function is explicitly defaulted on its ﬁrst declaration, — it is implicitly considered to be constexpr if the implicit declaration would be, — it is implicitly considered to have the same exception-speciﬁcation as if it had been implicitly declared (15.4), and — in the case of a copy constructor, move constructor, copy assignment operator, or move assignment operator, it shall have the same parameter type as if it had been implicitly declared.

3

[ Example: struct S { constexpr S() = default; S(int a = 0) = default; void operator=(const S&) = default; ~S() throw(int) = default; private: int i; S(S&); }; S::S(S&) = default; // // // // ill-formed: ill-formed: ill-formed: ill-formed: implicit S() is not constexpr default argument non-matching return type exception speciﬁcation does not match

// OK: private copy constructor // OK: deﬁnes copy constructor

102) Implementations are permitted to provide additional predeﬁned variables with names that are reserved to the implementation (17.6.4.3.2). If a predeﬁned variable is not odr-used (3.2), its string value need not be present in the program image.

§ 8.4.2

188

c ISO/IEC

N3337

4

5

— end example ] Explicitly-defaulted functions and implicitly-declared functions are collectively called defaulted functions, and the implementation shall provide implicit deﬁnitions for them (12.1 12.4, 12.8), which might mean deﬁning them as deleted. A special member function is user-provided if it is user-declared and not explicitly defaulted or deleted on its ﬁrst declaration. A user-provided explicitly-defaulted function (i.e., explicitly defaulted after its ﬁrst declaration) is deﬁned at the point where it is explicitly defaulted; if such a function is implicitly deﬁned as deleted, the program is ill-formed. [ Note: Declaring a function as defaulted after its ﬁrst declaration can provide eﬃcient execution and concise deﬁnition while enabling a stable binary interface to an evolving code base. — end note ] [ Example: struct trivial { trivial() = default; trivial(const trivial&) = default; trivial(trivial&&) = default; trivial& operator=(const trivial&) = default; trivial& operator=(trivial&&) = default; ~trivial() = default; }; struct nontrivial1 { nontrivial1(); }; nontrivial1::nontrivial1() = default;

// not ﬁrst declaration

— end example ]

8.4.3
1

Deleted deﬁnitions attribute-speciﬁer-seqopt decl-speciﬁer-seqopt declarator = delete ;

[dcl.fct.def.delete]

A function deﬁnition of the form: is called a deleted deﬁnition. A function with a deleted deﬁnition is also called a deleted function. A program that refers to a deleted function implicitly or explicitly, other than to declare it, is ill-formed. [ Note: This includes calling the function implicitly or explicitly and forming a pointer or pointer-to-member to the function. It applies even for references in expressions that are not potentially-evaluated. If a function is overloaded, it is referenced only if the function is selected by overload resolution. — end note ] [ Example: One can enforce non-default initialization and non-integral initialization with struct onlydouble { onlydouble() = delete; // OK, but redundant onlydouble(std::intmax_t) = delete; onlydouble(double); };

2

3

— end example ] [ Example: One can prevent use of a class in certain new expressions by using deleted deﬁnitions of a user-declared operator new for that class. struct sometype { void *operator new(std::size_t) = delete; void *operator new[](std::size_t) = delete; }; sometype *p = new sometype; // error, deleted class operator new sometype *q = new sometype[3]; // error, deleted class operator new[]

— end example ]

§ 8.4.3

189

c ISO/IEC

N3337

[ Example: One can make a class uncopyable, i.e. move-only, by using deleted deﬁnitions of the copy constructor and copy assignment operator, and then providing defaulted deﬁnitions of the move constructor and move assignment operator. struct moveonly { moveonly() = default; moveonly(const moveonly&) = delete; moveonly(moveonly&&) = default; moveonly& operator=(const moveonly&) = delete; moveonly& operator=(moveonly&&) = default; ~moveonly() = default; }; moveonly *p; moveonly q(*p); // error, deleted copy constructor
4

— end example ] A deleted function is implicitly inline. [ Note: The one-deﬁnition rule (3.2) applies to deleted deﬁnitions. — end note ] A deleted deﬁnition of a function shall be the ﬁrst declaration of the function or, for an explicit specialization of a function template, the ﬁrst declaration of that specialization. [ Example: struct sometype { sometype(); }; sometype::sometype() = delete;

// ill-formed; not ﬁrst declaration

— end example ]

8.5
1

Initializers

[dcl.init]

A declarator can specify an initial value for the identiﬁer being declared. The identiﬁer designates a variable being initialized. The process of initialization described in the remainder of 8.5 applies also to initializations speciﬁed by other syntactic contexts, such as the initialization of function parameters with argument expressions (5.2.2) or the initialization of return values (6.6.3). initializer: brace-or-equal-initializer ( expression-list ) brace-or-equal-initializer: = initializer-clause braced-init-list initializer-clause: assignment-expression braced-init-list initializer-list: initializer-clause ...opt initializer-list , initializer-clause ...opt braced-init-list: { initializer-list ,opt } {}

2

Except for objects declared with the constexpr speciﬁer, for which see 7.1.5, an initializer in the deﬁnition of a variable can consist of arbitrary expressions involving literals and previously declared variables and functions, regardless of the variable’s storage duration. [ Example: int int int int f(int); a = 2; b = f(a); c(b);

— end example ] § 8.5 190

c ISO/IEC

N3337

3 4 5

[ Note: Default arguments are more restricted; see 8.3.6. The order of initialization of variables with static storage duration is described in 3.6 and 6.7. — end note ] To zero-initialize an object or reference of type T means: — if T is a scalar type (3.9), the object is set to the value 0 (zero), taken as an integral constant expression, converted to T;103 — if T is a (possibly cv-qualiﬁed) non-union class type, each non-static data member and each base-class subobject is zero-initialized and padding is initialized to zero bits; — if T is a (possibly cv-qualiﬁed) union type, the object’s ﬁrst non-static named data member is zeroinitialized and padding is initialized to zero bits; — if T is an array type, each element is zero-initialized; — if T is a reference type, no initialization is performed.

6

To default-initialize an object of type T means: — if T is a (possibly cv-qualiﬁed) class type (Clause 9), the default constructor for T is called (and the initialization is ill-formed if T has no accessible default constructor); — if T is an array type, each element is default-initialized; — otherwise, no initialization is performed. If a program calls for the default initialization of an object of a const-qualiﬁed type T, T shall be a class type with a user-provided default constructor. To value-initialize an object of type T means: — if T is a (possibly cv-qualiﬁed) class type (Clause 9) with a user-provided constructor (12.1), then the default constructor for T is called (and the initialization is ill-formed if T has no accessible default constructor); — if T is a (possibly cv-qualiﬁed) non-union class type without a user-provided constructor, then the object is zero-initialized and, if T’s implicitly-declared default constructor is non-trivial, that constructor is called. — if T is an array type, then each element is value-initialized; — otherwise, the object is zero-initialized. An object that is value-initialized is deemed to be constructed and thus subject to provisions of this International Standard applying to “constructed” objects, objects “for which the constructor has completed,” etc., even if no constructor is invoked for the object’s initialization. A program that calls for default-initialization or value-initialization of an entity of reference type is ill-formed. [ Note: Every object of static storage duration is zero-initialized at program startup before any other initialization takes place. In some cases, additional initialization is done later. — end note ] An object whose initializer is an empty set of parentheses, i.e., (), shall be value-initialized. [ Note: Since () is not permitted by the syntax for initializer,
X a();
103) As speciﬁed in 4.10, converting an integral constant expression whose value is 0 to a pointer type results in a null pointer value.

7

8 9

10

§ 8.5

191

c ISO/IEC

N3337

11

12

is not the declaration of an object of class X, but the declaration of a function taking no argument and returning an X. The form () is permitted in certain other initialization contexts (5.3.4, 5.2.3, 12.6.2). — end note ] If no initializer is speciﬁed for an object, the object is default-initialized; if no initialization is performed, an object with automatic or dynamic storage duration has indeterminate value. [ Note: Objects with static or thread storage duration are zero-initialized, see 3.6.2. — end note ] An initializer for a static member is in the scope of the member’s class. [ Example: int a; struct X { static int a; static int b; }; int X::a = 1; int X::b = a;

// X::b = X::a

13

14

— end example ] The form of initialization (using parentheses or =) is generally insigniﬁcant, but does matter when the initializer or the entity being initialized has a class type; see below. If the entity being initialized does not have class type, the expression-list in a parenthesized initializer shall be a single expression. The initialization that occurs in the form
T x = a;

15

as well as in argument passing, function return, throwing an exception (15.1), handling an exception (15.3), and aggregate member initialization (8.5.1) is called copy-initialization. [ Note: Copy-initialization may invoke a move (12.8). — end note ] The initialization that occurs in the forms
T x(a); T x{a};

16

as well as in new expressions (5.3.4), static_cast expressions (5.2.9), functional notation type conversions (5.2.3), and base and member initializers (12.6.2) is called direct-initialization. The semantics of initializers are as follows. The destination type is the type of the object or reference being initialized and the source type is the type of the initializer expression. If the initializer is not a single (possibly parenthesized) expression, the source type is not deﬁned. — If the initializer is a (non-parenthesized) braced-init-list, the object or reference is list-initialized (8.5.4). — If the destination type is a reference type, see 8.5.3. — If the destination type is an array of characters, an array of char16_t, an array of char32_t, or an array of wchar_t, and the initializer is a string literal, see 8.5.2. — If the initializer is (), the object is value-initialized. — Otherwise, if the destination type is an array, the program is ill-formed. — If the destination type is a (possibly cv-qualiﬁed) class type: — If the initialization is direct-initialization, or if it is copy-initialization where the cv-unqualiﬁed version of the source type is the same class as, or a derived class of, the class of the destination, constructors are considered. The applicable constructors are enumerated (13.3.1.3), and the best one is chosen through overload resolution (13.3). The constructor so selected is called to initialize § 8.5 192

c ISO/IEC

N3337

the object, with the initializer expression or expression-list as its argument(s). If no constructor applies, or the overload resolution is ambiguous, the initialization is ill-formed. — Otherwise (i.e., for the remaining copy-initialization cases), user-deﬁned conversion sequences that can convert from the source type to the destination type or (when a conversion function is used) to a derived class thereof are enumerated as described in 13.3.1.4, and the best one is chosen through overload resolution (13.3). If the conversion cannot be done or is ambiguous, the initialization is ill-formed. The function selected is called with the initializer expression as its argument; if the function is a constructor, the call initializes a temporary of the cv-unqualiﬁed version of the destination type. The temporary is a prvalue. The result of the call (which is the temporary for the constructor case) is then used to direct-initialize, according to the rules above, the object that is the destination of the copy-initialization. In certain cases, an implementation is permitted to eliminate the copying inherent in this direct-initialization by constructing the intermediate result directly into the object being initialized; see 12.2, 12.8. — Otherwise, if the source type is a (possibly cv-qualiﬁed) class type, conversion functions are considered. The applicable conversion functions are enumerated (13.3.1.5), and the best one is chosen through overload resolution (13.3). The user-deﬁned conversion so selected is called to convert the initializer expression into the object being initialized. If the conversion cannot be done or is ambiguous, the initialization is ill-formed. — Otherwise, the initial value of the object being initialized is the (possibly converted) value of the initializer expression. Standard conversions (Clause 4) will be used, if necessary, to convert the initializer expression to the cv-unqualiﬁed version of the destination type; no user-deﬁned conversions are considered. If the conversion cannot be done, the initialization is ill-formed. [ Note: An expression of type “cv1 T” can initialize an object of type “cv2 T” independently of the cv-qualiﬁers cv1 and cv2. int a; const int b = a; int c = b;

— end note ]
17

An initializer-clause followed by an ellipsis is a pack expansion (14.5.3).

8.5.1
1

Aggregates

[dcl.init.aggr]

2

An aggregate is an array or a class (Clause 9) with no user-provided constructors (12.1), no brace-or-equalinitializers for non-static data members (9.2), no private or protected non-static data members (Clause 11), no base classes (Clause 10), and no virtual functions (10.3). When an aggregate is initialized by an initializer list, as speciﬁed in 8.5.4, the elements of the initializer list are taken as initializers for the members of the aggregate, in increasing subscript or member order. Each member is copy-initialized from the corresponding initializer-clause. If the initializer-clause is an expression and a narrowing conversion (8.5.4) is required to convert the expression, the program is ill-formed. [ Note: If an initializer-clause is itself an initializer list, the member is list-initialized, which will result in a recursive application of the rules in this section if the member is an aggregate. — end note ] [ Example: struct A { int x; struct B { int i; int j; } b; } a = { 1, { 2, 3 } };

§ 8.5.1

193

c ISO/IEC

N3337

3

4

initializes a.x with 1, a.b.i with 2, a.b.j with 3. — end example ] An aggregate that is a class can also be initialized with a single expression not enclosed in braces, as described in 8.5. An array of unknown size initialized with a brace-enclosed initializer-list containing n initializer-clauses, where n shall be greater than zero, is deﬁned as having n elements (8.3.4). [ Example: int x[] = { 1, 3, 5 };

5

declares and initializes x as a one-dimensional array that has three elements since no size was speciﬁed and there are three initializers. — end example ] An empty initializer list {} shall not be used as the initializer-clause for an array of unknown bound.104 Static data members and anonymous bit-ﬁelds are not considered members of the class for purposes of aggregate initialization. [ Example: struct A { int i; static int s; int j; int :17; int k; } a = { 1, 2, 3 };

6

Here, the second initializer 2 initializes a.j and not the static data member A::s, and the third initializer 3 initializes a.k and not the anonymous bit-ﬁeld before it. — end example ] An initializer-list is ill-formed if the number of initializer-clauses exceeds the number of members or elements to initialize. [ Example: char cv[4] = { ’a’, ’s’, ’d’, ’f’, 0 }; // error

7

is ill-formed. — end example ] If there are fewer initializer-clauses in the list than there are members in the aggregate, then each member not explicitly initialized shall be initialized from an empty initializer list (8.5.4). [ Example: struct S { int a; const char* b; int c; }; S ss = { 1, "asdf" };

8

initializes ss.a with 1, ss.b with "asdf", and ss.c with the value of an expression of the form int(), that is, 0. — end example ] If an aggregate class C contains a subaggregate member m that has no members for purposes of aggregate initialization, the initializer-clause for m shall not be omitted from an initializer-list for an object of type C unless the initializer-clauses for all members of C following m are also omitted. [ Example: struct S { } s; struct A { S s1; int i1; S s2; int i2; S s3; int i3; } a = { { }, // Required initialization 0, s, // Required initialization 0 }; // Initialization not required for A::s3 because A::i3 is also not initialized
104) The syntax provides for empty initializer-lists, but nonetheless C++ does not have zero length arrays.

§ 8.5.1

194

c ISO/IEC

N3337

9

10

— end example ] If an incomplete or empty initializer-list leaves a member of reference type uninitialized, the program is ill-formed. When initializing a multi-dimensional array, the initializer-clauses initialize the elements with the last (rightmost) index of the array varying the fastest (8.3.4). [ Example: int x[2][2] = { 3, 1, 4, 2 };

initializes x[0][0] to 3, x[0][1] to 1, x[1][0] to 4, and x[1][1] to 2. On the other hand, float y[4][3] = { { 1 }, { 2 }, { 3 }, { 4 } };

11

initializes the ﬁrst column of y (regarded as a two-dimensional array) and leaves the rest zero. — end example ] In a declaration of the form
T x = { a };

braces can be elided in an initializer-list as follows.105 If the initializer-list begins with a left brace, then the succeeding comma-separated list of initializer-clauses initializes the members of a subaggregate; it is erroneous for there to be more initializer-clauses than members. If, however, the initializer-list for a subaggregate does not begin with a left brace, then only enough initializer-clauses from the list are taken to initialize the members of the subaggregate; any remaining initializer-clauses are left to initialize the next member of the aggregate of which the current subaggregate is a member. [ Example: float y[4][3] = { { 1, 3, 5 }, { 2, 4, 6 }, { 3, 5, 7 }, };

is a completely-braced initialization: 1, 3, and 5 initialize the ﬁrst row of the array y[0], namely y[0][0], y[0][1], and y[0][2]. Likewise the next two lines initialize y[1] and y[2]. The initializer ends early and therefore y[3]s elements are initialized as if explicitly initialized with an expression of the form float(), that is, are initialized with 0.0. In the following example, braces in the initializer-list are elided; however the initializer-list has the same eﬀect as the completely-braced initializer-list of the above example, float y[4][3] = { 1, 3, 5, 2, 4, 6, 3, 5, 7 };

12

The initializer for y begins with a left brace, but the one for y[0] does not, therefore three elements from the list are used. Likewise the next three are taken successively for y[1] and y[2]. — end example ] All implicit type conversions (Clause 4) are considered when initializing the aggregate member with an assignment-expression. If the assignment-expression can initialize a member, the member is initialized. Otherwise, if the member is itself a subaggregate, brace elision is assumed and the assignment-expression is considered for the initialization of the ﬁrst member of the subaggregate. [ Note: As speciﬁed above, brace elision cannot apply to subaggregates with no members for purposes of aggregate initialization; an initializer-clause for the entire subobject is required. — end note ] [ Example: struct A { int i; operator int();
105) Braces cannot be elided in other uses of list-initialization.

§ 8.5.1

195

c ISO/IEC

N3337

}; struct B { A a1, a2; int z; }; A a; B b = { 4, a, a };

13

14

15

Braces are elided around the initializer-clause for b.a1.i. b.a1.i is initialized with 4, b.a2 is initialized with a, b.z is initialized with whatever a.operator int() returns. — end example ] [ Note: An aggregate array or an aggregate class may contain members of a class type with a user-provided constructor (12.1). Initialization of these aggregate objects is described in 12.6.1. — end note ] [ Note: Whether the initialization of aggregates with static storage duration is static or dynamic is speciﬁed in 3.6.2 and 6.7. — end note ] When a union is initialized with a brace-enclosed initializer, the braces shall only contain an initializer-clause for the ﬁrst non-static data member of the union. [ Example: union u a = u b = u c = u d = u e = u { int a; const char* b; }; { 1 }; a; 1; // error { 0, "asdf" }; // error { "asdf" }; // error

16

— end example ] [ Note: As described above, the braces around the initializer-clause for a union member can be omitted if the union is a member of another aggregate. — end note ]

8.5.2
1

Character arrays

[dcl.init.string]

A char array (whether plain char, signed char, or unsigned char), char16_t array, char32_t array, or wchar_t array can be initialized by a narrow character literal, char16_t string literal, char32_t string literal, or wide string literal, respectively, or by an appropriately-typed string literal enclosed in braces. Successive characters of the value of the string literal initialize the elements of the array. [ Example: char msg[] = "Syntax error on line %s\n";

2

shows a character array whose members are initialized with a string-literal. Note that because ’\n’ is a single character and because a trailing ’\0’ is appended, sizeof(msg) is 25. — end example ] There shall not be more initializers than there are array elements. [ Example: char cv[4] = "asdf"; // error

3

is ill-formed since there is no space for the implied trailing ’\0’. — end example ] If there are fewer initializers than there are array elements, each element not explicitly initialized shall be zero-initialized (8.5).

8.5.3
1

References

[dcl.init.ref]

A variable declared to be a T& or T&&, that is, “reference to type T” (8.3.2), shall be initialized by an object, or function, of type T or by an object that can be converted into a T. [ Example: int g(int); void f() { int i; int& r = i; r = 1; int* p = &r; int& rr = r; int (&rg)(int) = g;

// // // // //

r refers to i the value of i becomes 1 p points to i rr refers to what r refers to, that is, to i rg refers to the function g

§ 8.5.3

196

c ISO/IEC

N3337

rg(i); int a[3]; int (&ra)[3] = a; ra[1] = i; }
2

// calls function g // ra refers to the array a // modiﬁes a[1]

3

— end example ] A reference cannot be changed to refer to another object after initialization. Note that initialization of a reference is treated very diﬀerently from assignment to it. Argument passing (5.2.2) and function value return (6.6.3) are initializations. The initializer can be omitted for a reference only in a parameter declaration (8.3.5), in the declaration of a function return type, in the declaration of a class member within its class deﬁnition (9.2), and where the extern speciﬁer is explicitly used. [ Example: int& r1; extern int& r2; // error: initializer missing // OK

4

5

— end example ] Given types “cv1 T1” and “cv2 T2,” “cv1 T1” is reference-related to “cv2 T2” if T1 is the same type as T2, or T1 is a base class of T2. “cv1 T1” is reference-compatible with “cv2 T2” if T1 is reference-related to T2 and cv1 is the same cv-qualiﬁcation as, or greater cv-qualiﬁcation than, cv2. For purposes of overload resolution, cases for which cv1 is greater cv-qualiﬁcation than cv2 are identiﬁed as reference-compatible with added qualiﬁcation (see 13.3.3.2). In all cases where the reference-related or reference-compatible relationship of two types is used to establish the validity of a reference binding, and T1 is a base class of T2, a program that necessitates such a binding is ill-formed if T1 is an inaccessible (Clause 11) or ambiguous (10.2) base class of T2. A reference to type “cv1 T1” is initialized by an expression of type “cv2 T2” as follows: — If the reference is an lvalue reference and the initializer expression — is an lvalue (but is not a bit-ﬁeld), and “cv1 T1” is reference-compatible with “cv2 T2,” or — has a class type (i.e., T2 is a class type), where T1 is not reference-related to T2, and can be implicitly converted to an lvalue of type “cv3 T3,” where “cv1 T1” is reference-compatible with “cv3 T3”106 (this conversion is selected by enumerating the applicable conversion functions (13.3.1.6) and choosing the best one through overload resolution (13.3)), then the reference is bound to the initializer expression lvalue in the ﬁrst case and to the lvalue result of the conversion in the second case (or, in either case, to the appropriate base class subobject of the object). [ Note: The usual lvalue-to-rvalue (4.1), array-to-pointer (4.2), and function-to-pointer (4.3) standard conversions are not needed, and therefore are suppressed, when such direct bindings to lvalues are done. — end note ] [ Example: double d = 2.0; double& rd = d; const double& rcd = d; // rd refers to d // rcd refers to d

struct A { }; struct B : A { operator int&(); } b; A& ra = b; // ra refers to A subobject in b const A& rca = b; // rca refers to A subobject in b int& ir = B(); // ir refers to the result of B::operator int&

— end example ]
106) This requires a conversion function (12.3.2) returning a reference type.

§ 8.5.3

197

c ISO/IEC

N3337

— Otherwise, the reference shall be an lvalue reference to a non-volatile const type (i.e., cv1 shall be const), or the reference shall be an rvalue reference. [ Example: double& rd2 = 2.0; int i = 2; double& rd3 = i; // error: not an lvalue and reference not const // error: type mismatch and reference not const

— end example ] — If the initializer expression — is an xvalue, class prvalue, array prvalue or function lvalue and “cv1 T1” is referencecompatible with “cv2 T2”, or — has a class type (i.e., T2 is a class type), where T1 is not reference-related to T2, and can be implicitly converted to an xvalue, class prvalue, or function lvalue of type “cv3 T3”, where “cv1 T1” is reference-compatible with “cv3 T3”, then the reference is bound to the value of the initializer expression in the ﬁrst case and to the result of the conversion in the second case (or, in either case, to an appropriate base class subobject). In the second case, if the reference is an rvalue reference and the second standard conversion sequence of the user-deﬁned conversion sequence includes an lvalue-to-rvalue conversion, the program is ill-formed. [ Example: struct A { }; struct B : A { } b; extern B f(); const A& rca2 = f(); A&& rra = f(); struct X { operator B(); operator int&(); } x; const A& r = x; int i2 = 42; int&& rri = static_cast(i2); B&& rrb = x; int&& rri2 = X();

// bound to the A subobject of the B rvalue. // same as above

// bound to the A subobject of the result of the conversion // // // // bound directly to i2 bound directly to the result of operator B error: lvalue-to-rvalue conversion applied to the result of operator int&

— end example ] — Otherwise, a temporary of type “cv1 T1” is created and initialized from the initializer expression using the rules for a non-reference copy-initialization (8.5). The reference is then bound to the temporary. If T1 is reference-related to T2, cv1 shall be the same cv-qualiﬁcation as, or greater cv-qualiﬁcation than, cv2. If T1 is reference-related to T2 and the reference is an rvalue reference, the initializer expression shall not be an lvalue. [ Example: const double& rcd2 = 2; double&& rrd = 2; const volatile int cvi = 1; const int& r2 = cvi; double d2 = 1.0; double&& rrd2 = d2; int i3 = 2; double&& rrd3 = i3; // rcd2 refers to temporary with value 2.0 // rrd refers to temporary with value 2.0 // error: type qualiﬁers dropped // error: copying lvalue of related type // rrd3 refers to temporary with value 2.0

— end example ] § 8.5.3 198

c ISO/IEC

N3337

6

In all cases except the last (i.e., creating and initializing a temporary from the initializer expression), the reference is said to bind directly to the initializer expression. [ Note: 12.2 describes the lifetime of temporaries bound to references. — end note ]

8.5.4
1

List-initialization

[dcl.init.list]

List-initialization is initialization of an object or reference from a braced-init-list. Such an initializer is called an initializer list, and the comma-separated initializer-clauses of the list are called the elements of the initializer list. An initializer list may be empty. List-initialization can occur in direct-initialization or copyinitialization contexts; list-initialization in a direct-initialization context is called direct-list-initialization and list-initialization in a copy-initialization context is called copy-list-initialization. [ Note: List-initialization can be used — as the initializer in a variable deﬁnition (8.5) — as the initializer in a new expression (5.3.4) — in a return statement (6.6.3) — as a function argument (5.2.2) — as a subscript (5.2.1) — as an argument to a constructor invocation (8.5, 5.2.3) — as an initializer for a non-static data member (9.2) — in a mem-initializer (12.6.2) — on the right-hand side of an assignment (5.17) [ Example: int a = {1}; std::complex z{1,2}; new std::vector{"once", "upon", "a", "time"}; // 4 string elements f( {"Nicholas","Annemarie"} ); // pass list of two elements return { "Norah" }; // return list of one element int* e {}; // initialization to zero / null pointer x = double{1}; // explicitly construct a double std::map anim = { {"bear",4}, {"cassowary",2}, {"tiger",7} };

2

3

— end example ] — end note ] A constructor is an initializer-list constructor if its ﬁrst parameter is of type std::initializer_list or reference to possibly cv-qualiﬁed std::initializer_list for some type E, and either there are no other parameters or else all other parameters have default arguments (8.3.6). [ Note: Initializer-list constructors are favored over other constructors in list-initialization (13.3.1.7). — end note ] The template std::initializer_list is not predeﬁned; if the header is not included prior to a use of std::initializer_list — even an implicit use in which the type is not named (7.1.6.4) — the program is ill-formed. List-initialization of an object or reference of type T is deﬁned as follows: — If the initializer list has no elements and T is a class type with a default constructor, the object is value-initialized. — Otherwise, if T is an aggregate, aggregate initialization is performed (8.5.1). [ Example: § 8.5.4 199

c ISO/IEC

N3337

double ad[] = { 1, 2.0 }; int ai[] = { 1, 2.0 }; struct S2 { int m1; double m2, m3; }; S2 s21 = { 1, 2, 3.0 }; S2 s22 { 1.0, 2, 3 }; S2 s23 { };

// OK // error: narrowing

// OK // error: narrowing // OK: default to 0,0,0

— end example ] — Otherwise, if T is a specialization of std::initializer_list, an initializer_list object is constructed as described below and used to initialize the object according to the rules for initialization of an object from a class of the same type (8.5). — Otherwise, if T is a class type, constructors are considered. The applicable constructors are enumerated and the best one is chosen through overload resolution (13.3, 13.3.1.7). If a narrowing conversion (see below) is required to convert any of the arguments, the program is ill-formed. [ Example: struct S { S(std::initializer_list); S(std::initializer_list); S(); // ... }; S s1 = { 1.0, 2.0, 3.0 }; S s2 = { 1, 2, 3 }; S s3 = { }; // #1 // #2 // #3

// invoke #1 // invoke #2 // invoke #3

— end example ] [ Example: struct Map { Map(std::initializer_list); }; Map ship = {{"Sophie",14}, {"Surprise",28}};

— end example ] [ Example: struct S { // no initializer-list constructors S(int, double, double); S(); // ... }; S s1 = { 1, 2, 3.0 }; S s2 { 1.0, 2, 3 }; S s3 { };

// #1 // #2

// OK: invoke #1 // error: narrowing // OK: invoke #2

— end example ]

§ 8.5.4

200

c ISO/IEC

N3337

— Otherwise, if T is a reference type, a prvalue temporary of the type referenced by T is list-initialized, and the reference is bound to that temporary. [ Note: As usual, the binding will fail and the program is ill-formed if the reference type is an lvalue reference to a non-const type. — end note ] [ Example: struct S { S(std::initializer_list); S(const std::string&); // ... }; const S& r1 = { 1, 2, 3.0 }; const S& r2 { "Spinach" }; S& r3 = { 1, 2, 3 }; const int& i1 = { 1 }; const int& i2 = { 1.1 }; const int (&iar)[2] = { 1, 2 }; // #1 // #2

// // // // // //

OK: invoke #1 OK: invoke #2 error: initializer is not an lvalue OK error: narrowing OK: iar is bound to temporary array

— end example ] — Otherwise, if the initializer list has a single element, the object or reference is initialized from that element; if a narrowing conversion (see below) is required to convert the element to T, the program is ill-formed. [ Example: int x1 {2}; int x2 {2.0}; // OK // error: narrowing

— end example ] — Otherwise, if the initializer list has no elements, the object is value-initialized. [ Example: int** pp {}; // initialized to null pointer

— end example ] — Otherwise, the program is ill-formed. [ Example: struct A { int i; int j; }; A a1 { 1, 2 }; A a2 { 1.2 }; struct B { B(std::initializer_list); }; B b1 { 1, 2 }; B b2 { 1, 2.0 }; struct C { C(int i, double j); }; C c1 = { 1, 2.2 }; C c2 = { 1.1, 2 }; int j { 1 }; int k { }; // aggregate initialization // error: narrowing

// creates initializer_list and calls constructor // error: narrowing

// calls constructor with arguments (1, 2.2) // error: narrowing // initialize to 1 // initialize to 0

§ 8.5.4

201

c ISO/IEC

N3337

— end example ]
4

5

Within the initializer-list of a braced-init-list, the initializer-clauses, including any that result from pack expansions (14.5.3), are evaluated in the order in which they appear. That is, every value computation and side eﬀect associated with a given initializer-clause is sequenced before every value computation and side eﬀect associated with any initializer-clause that follows it in the comma-separated list of the initializer-list. [ Note: This evaluation ordering holds regardless of the semantics of the initialization; for example, it applies when the elements of the initializer-list are interpreted as arguments of a constructor call, even though ordinarily there are no sequencing constraints on the arguments of a call. — end note ] An object of type std::initializer_list is constructed from an initializer list as if the implementation allocated an array of N elements of type E, where N is the number of elements in the initializer list. Each element of that array is copy-initialized with the corresponding element of the initializer list, and the std::initializer_list object is constructed to refer to that array. If a narrowing conversion is required to initialize any of the elements, the program is ill-formed.[ Example: struct X { X(std::initializer_list v); }; X x{ 1,2,3 };

The initialization will be implemented in a way roughly equivalent to this: double __a[3] = {double{1}, double{2}, double{3}}; X x(std::initializer_list(__a, __a+3));

6

assuming that the implementation can construct an initializer_list object with a pair of pointers. — end example ] The lifetime of the array is the same as that of the initializer_list object. [ Example: typedef std::complex cmplx; std::vector v1 = { 1, 2, 3 }; void f() { std::vector v2{ 1, 2, 3 }; std::initializer_list i3 = { 1, 2, 3 }; }

7

For v1 and v2, the initializer_list object and array created for { 1, 2, 3 } have full-expression lifetime. For i3, the initializer_list object and array have automatic lifetime. — end example ] [ Note: The implementation is free to allocate the array in read-only memory if an explicit array with the same initializer could be so allocated. — end note ] A narrowing conversion is an implicit conversion — from a ﬂoating-point type to an integer type, or — from long double to double or float, or from double to float, except where the source is a constant expression and the actual value after conversion is within the range of values that can be represented (even if it cannot be represented exactly), or — from an integer type or unscoped enumeration type to a ﬂoating-point type, except where the source is a constant expression and the actual value after conversion will ﬁt into the target type and will produce the original value when converted back to the original type, or — from an integer type or unscoped enumeration type to an integer type that cannot represent all the values of the original type, except where the source is a constant expression and the actual value after conversion will ﬁt into the target type and will produce the original value when converted back to the original type. § 8.5.4 202

c ISO/IEC

N3337

[ Note: As indicated above, such conversions are not allowed at the top level in list-initializations. — end note ] [ Example: int x = 999; const int y = 999; const int z = 99; char c1 = x; char c2{x}; char c3{y}; char c4{z}; unsigned char uc1 = {5}; unsigned char uc2 = {-1}; unsigned int ui1 = {-1}; signed int si1 = { (unsigned int)-1 }; int ii = {2.0}; float f1 { x }; float f2 { 7 }; int f(int); int a[] = { 2, f(2), f(2.0) }; // x is not a constant expression

// // // // // // // // // // //

OK, though it might narrow (in this case, it does narrow) error: might narrow error: narrows (assuming char is 8 bits) OK: no narrowing needed OK: no narrowing needed error: narrows error: narrows error: narrows error: narrows error: might narrow OK: 7 can be exactly represented as a ﬂoat

// OK: the double-to-int conversion is not at the top level

— end example ]

§ 8.5.4

203

c ISO/IEC

N3337

9
1

Classes class-name: identiﬁer simple-template-id

[class]

A class is a type. Its name becomes a class-name (9.1) within its scope.

Class-speciﬁers and elaborated-type-speciﬁers (7.1.6.3) are used to make class-names. An object of a class consists of a (possibly empty) sequence of members and base class objects. class-speciﬁer: class-head { member-speciﬁcationopt } class-head: class-key attribute-speciﬁer-seqopt class-head-name class-virt-speciﬁeropt base-clauseopt class-key attribute-speciﬁer-seqopt base-clauseopt class-head-name: nested-name-speciﬁeropt class-name class-virt-speciﬁer: final class-key: class struct union

2

3

4

5

6

A class-speciﬁer whose class-head omits the class-head-name deﬁnes an unnamed class. [ Note: An unnamed class thus can’t be final. — end note ] A class-name is inserted into the scope in which it is declared immediately after the class-name is seen. The class-name is also inserted into the scope of the class itself; this is known as the injected-class-name. For purposes of access checking, the injected-class-name is treated as if it were a public member name. A class-speciﬁer is commonly referred to as a class deﬁnition. A class is considered deﬁned after the closing brace of its class-speciﬁer has been seen even though its member functions are in general not yet deﬁned. The optional attribute-speciﬁer-seq appertains to the class; the attributes in the attribute-speciﬁer-seq are thereafter considered attributes of the class whenever it is named. If a class is marked with the class-virt-speciﬁer final and it appears as a base-type-speciﬁer in a base-clause (Clause 10), the program is ill-formed. Complete objects and member subobjects of class type shall have nonzero size.107 [ Note: Class objects can be assigned, passed as arguments to functions, and returned by functions (except objects of classes for which copying or moving has been restricted; see 12.8). Other plausible operators, such as equality comparison, can be deﬁned by the user; see 13.5. — end note ] A union is a class deﬁned with the class-key union; it holds only one data member at a time (9.5). [ Note: Aggregates of class type are described in 8.5.1. — end note ] A trivially copyable class is a class that: — has no non-trivial copy constructors (12.8), — has no non-trivial move constructors (12.8), — has no non-trivial copy assignment operators (13.5.3, 12.8), — has no non-trivial move assignment operators (13.5.3, 12.8), and — has a trivial destructor (12.4).
107) Base class subobjects are not so constrained.

Classes

204

c ISO/IEC

N3337

7

A trivial class is a class that has a trivial default constructor (12.1) and is trivially copyable. [ Note: In particular, a trivially copyable or trivial class does not have virtual functions or virtual base classes. — end note ] A standard-layout class is a class that: — has no non-static data members of type non-standard-layout class (or array of such types) or reference, — has no virtual functions (10.3) and no virtual base classes (10.1), — has the same access control (Clause 11) for all non-static data members, — has no non-standard-layout base classes, — either has no non-static data members in the most derived class and at most one base class with non-static data members, or has no base classes with non-static data members, and — has no base classes of the same type as the ﬁrst non-static data member.108

8

9

10

A standard-layout struct is a standard-layout class deﬁned with the class-key struct or the class-key class. A standard-layout union is a standard-layout class deﬁned with the class-key union. [ Note: Standard-layout classes are useful for communicating with code written in other programming languages. Their layout is speciﬁed in 9.2. — end note ] A POD struct 109 is a non-union class that is both a trivial class and a standard-layout class, and has no non-static data members of type non-POD struct, non-POD union (or array of such types). Similarly, a POD union is a union that is both a trivial class and a standard layout class, and has no non-static data members of type non-POD struct, non-POD union (or array of such types). A POD class is a class that is either a POD struct or a POD union. [ Example: struct N { int i; int j; virtual ~N(); }; struct T { int i; private: int j; }; struct SL { int i; int j; ~SL(); }; struct POD { int i; int j; }; // neither trivial nor standard-layout

// trivial but not standard-layout

// standard-layout but not trivial

// both trivial and standard-layout

108) This ensures that two subobjects that have the same class type and that belong to the same most derived object are not allocated at the same address (5.10). 109) The acronym POD stands for “plain old data”.

Classes

205

c ISO/IEC

N3337

11

— end example ] If a class-head-name contains a nested-name-speciﬁer, the class-speciﬁer shall refer to a class that was previously declared directly in the class or namespace to which the nested-name-speciﬁer refers, or in an element of the inline namespace set (7.3.1) of that namespace (i.e., not merely inherited or introduced by a using-declaration), and the class-speciﬁer shall appear in a namespace enclosing the previous declaration. In such cases, the nested-name-speciﬁer of the class-head-name of the deﬁnition shall not begin with a decltype-speciﬁer.

9.1
1

Class names

[class.name]

A class deﬁnition introduces a new type. [ Example: struct X { int a; }; struct Y { int a; }; X a1; Y a2; int a3;

declares three variables of three diﬀerent types. This implies that a1 = a2; a1 = a3; // error: Y assigned to X // error: int assigned to X

are type mismatches, and that int f(X); int f(Y);

declare an overloaded (Clause 13) function f() and not simply a single function f() twice. For the same reason, struct S { int a; }; struct S { int a; };
2

// error, double deﬁnition

is ill-formed because it deﬁnes S twice. — end example ] A class declaration introduces the class name into the scope where it is declared and hides any class, variable, function, or other declaration of that name in an enclosing scope (3.3). If a class name is declared in a scope where a variable, function, or enumerator of the same name is also declared, then when both declarations are in scope, the class can be referred to only using an elaborated-type-speciﬁer (3.4.4). [ Example: struct stat { // ... }; stat gstat; // use plain stat to // deﬁne variable // redeclare stat as function

int stat(struct stat*); void f() { struct stat* ps; stat(ps); }

// struct preﬁx needed // to name struct stat // call stat()

— end example ] A declaration consisting solely of class-key identiﬁer; is either a redeclaration of the name in the current scope or a forward declaration of the identiﬁer as a class name. It introduces the class name into the current scope. [ Example:

§ 9.1

206

c ISO/IEC

N3337

struct s { int a; }; void g() { struct s; s* p; struct s { char* p; }; struct s; }

// // // // //

hide global struct s with a block-scope declaration refer to local struct s deﬁne local struct s redeclaration, has no eﬀect

— end example ] [ Note: Such declarations allow deﬁnition of classes that refer to each other. [ Example: class Vector; class Matrix { // ... friend Vector operator*(const Matrix&, const Vector&); }; class Vector { // ... friend Vector operator*(const Matrix&, const Vector&); };
3

Declaration of friends is described in 11.3, operator functions in 13.5. — end example ] — end note ] [ Note: An elaborated-type-speciﬁer (7.1.6.3) can also be used as a type-speciﬁer as part of a declaration. It diﬀers from a class declaration in that if a class of the elaborated name is in scope the elaborated name will refer to it. — end note ] [ Example: struct s { int a; }; void g(int s) { struct s* p = new struct s; p->a = s; }

// global s // parameter s

4

— end example ] [ Note: The declaration of a class name takes eﬀect immediately after the identiﬁer is seen in the class deﬁnition or elaborated-type-speciﬁer. For example, class A * A;

5

ﬁrst speciﬁes A to be the name of a class and then redeﬁnes it as the name of a pointer to an object of that class. This means that the elaborated form class A must be used to refer to the class. Such artistry with names can be confusing and is best avoided. — end note ] A typedef-name (7.1.3) that names a class type, or a cv-qualiﬁed version thereof, is also a class-name. If a typedef-name that names a cv-qualiﬁed class type is used where a class-name is required, the cv-qualiﬁers are ignored. A typedef-name shall not be used as the identiﬁer in a class-head.

9.2

Class members member-speciﬁcation: member-declaration member-speciﬁcationopt access-speciﬁer : member-speciﬁcationopt

[class.mem]

§ 9.2

207

c ISO/IEC

N3337

1

2

3

4

5

6

7

8

The member-speciﬁcation in a class deﬁnition declares the full set of members of the class; no member can be added elsewhere. Members of a class are data members, member functions (9.3), nested types, and enumerators. Data members and member functions are static or non-static; see 9.4. Nested types are classes (9.1, 9.7) and enumerations (7.2) deﬁned in the class, and arbitrary types declared as members by use of a typedef declaration (7.1.3). The enumerators of an unscoped enumeration (7.2) deﬁned in the class are members of the class. Except when used to declare friends (11.3) or to introduce the name of a member of a base class into a derived class (7.3.3), member-declarations declare members of the class, and each such member-declaration shall declare at least one member name of the class. A member shall not be declared twice in the member-speciﬁcation, except that a nested class or member class template can be declared and then later deﬁned, and except that an enumeration can be introduced with an opaque-enum-declaration and later redeclared with an enum-speciﬁer. A class is considered a completely-deﬁned object type (3.9) (or complete type) at the closing } of the class-speciﬁer. Within the class member-speciﬁcation, the class is regarded as complete within function bodies, default arguments, exception-speciﬁcations, and brace-or-equal-initializers for non-static data members (including such things in nested classes). Otherwise it is regarded as incomplete within its own class member-speciﬁcation. [ Note: A single name can denote several function members provided their types are suﬃciently diﬀerent (Clause 13). — end note ] A member can be initialized using a constructor; see 12.1. [ Note: See Clause 12 for a description of constructors and other special member functions. — end note ] A member can be initialized using a brace-or-equal-initializer. (For static data members, see 9.4.2; for non-static data members, see 12.6.2). A member shall not be declared with the extern or register storage-class-speciﬁer. Within a class deﬁnition, a member shall not be declared with the thread_local storage-class-speciﬁer unless also declared static. The decl-speciﬁer-seq may be omitted in constructor, destructor, and conversion function declarations only; when declaring another kind of member the decl-speciﬁer-seq shall contain a type-speciﬁer that is not a cvqualiﬁer. The member-declarator-list can be omitted only after a class-speciﬁer or an enum-speciﬁer or in a friend declaration (11.3). A pure-speciﬁer shall be used only in the declaration of a virtual function (10.3). The optional attribute-speciﬁer-seq in a member-declaration appertains to each of the entities declared by the member-declarators; it shall not appear if the optional member-declarator-list is omitted. § 9.2 208

member-declaration: attribute-speciﬁer-seqopt decl-speciﬁer-seqopt member-declarator-listopt ; function-deﬁnition ;opt using-declaration static_assert-declaration template-declaration alias-declaration member-declarator-list: member-declarator member-declarator-list , member-declarator member-declarator: declarator virt-speciﬁer-seqopt pure-speciﬁeropt declarator brace-or-equal-initializeropt identiﬁeropt attribute-speciﬁer-seqopt : constant-expression virt-speciﬁer-seq: virt-speciﬁer virt-speciﬁer-seq virt-speciﬁer virt-speciﬁer: override final pure-speciﬁer: = 0

c ISO/IEC

N3337

9

10

11

12

13

A virt-speciﬁer-seq shall contain at most one of each virt-speciﬁer. A virt-speciﬁer-seq shall appear only in the declaration of a virtual member function (10.3). Non-static (9.4) data members shall not have incomplete types. In particular, a class C shall not contain a non-static member of class C, but it can contain a pointer or reference to an object of class C. [ Note: See 5.1 for restrictions on the use of non-static data members and non-static member functions. — end note ] [ Note: The type of a non-static member function is an ordinary function type, and the type of a non-static data member is an ordinary object type. There are no special member function types or data member types. — end note ] [ Example: A simple example of a class deﬁnition is struct tnode { char tword[20]; int count; tnode *left; tnode *right; };

which contains an array of twenty characters, an integer, and two pointers to objects of the same type. Once this deﬁnition has been given, the declaration tnode s, *sp;

14

15

declares s to be a tnode and sp to be a pointer to a tnode. With these declarations, sp->count refers to the count member of the object to which sp points; s.left refers to the left subtree pointer of the object s; and s.right->tword[0] refers to the initial character of the tword member of the right subtree of s. — end example ] Nonstatic data members of a (non-union) class with the same access control (Clause 11) are allocated so that later members have higher addresses within a class object. The order of allocation of non-static data members with diﬀerent access control is unspeciﬁed (11). Implementation alignment requirements might cause two adjacent members not to be allocated immediately after each other; so might requirements for space for managing virtual functions (10.3) and virtual base classes (10.1). If T is the name of a class, then each of the following shall have a name diﬀerent from T: — every static data member of class T; — every member function of class T [ Note: This restriction does not apply to constructors, which do not have names (12.1) — end note ]; — every member of class T that is itself a type; — every enumerator of every member of class T that is an unscoped enumerated type; and — every member of every anonymous union that is a member of class T.

16

17

18

19

In addition, if class T has a user-declared constructor (12.1), every non-static data member of class T shall have a name diﬀerent from T. Two standard-layout struct (Clause 9) types are layout-compatible if they have the same number of non-static data members and corresponding non-static data members (in declaration order) have layout-compatible types (3.9). Two standard-layout union (Clause 9) types are layout-compatible if they have the same number of nonstatic data members and corresponding non-static data members (in any order) have layout-compatible types (3.9). If a standard-layout union contains two or more standard-layout structs that share a common initial sequence, and if the standard-layout union object currently contains one of these standard-layout structs, it is permitted to inspect the common initial part of any of them. Two standard-layout structs share a common initial § 9.2 209

c ISO/IEC

N3337

20

sequence if corresponding members have layout-compatible types and either neither member is a bit-ﬁeld or both are bit-ﬁelds with the same width for a sequence of one or more initial members. A pointer to a standard-layout struct object, suitably converted using a reinterpret_cast, points to its initial member (or if that member is a bit-ﬁeld, then to the unit in which it resides) and vice versa. [ Note: There might therefore be unnamed padding within a standard-layout struct object, but not at its beginning, as necessary to achieve appropriate alignment. — end note ]

9.3
1

Member functions

[class.mfct]

2

3

4

5

Functions declared in the deﬁnition of a class, excluding those declared with a friend speciﬁer (11.3), are called member functions of that class. A member function may be declared static in which case it is a static member function of its class (9.4); otherwise it is a non-static member function of its class (9.3.1, 9.3.2). A member function may be deﬁned (8.4) in its class deﬁnition, in which case it is an inline member function (7.1.2), or it may be deﬁned outside of its class deﬁnition if it has already been declared but not deﬁned in its class deﬁnition. A member function deﬁnition that appears outside of the class deﬁnition shall appear in a namespace scope enclosing the class deﬁnition. Except for member function deﬁnitions that appear outside of a class deﬁnition, and except for explicit specializations of member functions of class templates and member function templates (14.7) appearing outside of the class deﬁnition, a member function shall not be redeclared. An inline member function (whether static or non-static) may also be deﬁned outside of its class deﬁnition provided either its declaration in the class deﬁnition or its deﬁnition outside of the class deﬁnition declares the function as inline. [ Note: Member functions of a class in namespace scope have external linkage. Member functions of a local class (9.8) have no linkage. See 3.5. — end note ] There shall be at most one deﬁnition of a non-inline member function in a program; no diagnostic is required. There may be more than one inline member function deﬁnition in a program. See 3.2 and 7.1.2. If the deﬁnition of a member function is lexically outside its class deﬁnition, the member function name shall be qualiﬁed by its class name using the :: operator. [ Note: A name used in a member function deﬁnition (that is, in the parameter-declaration-clause including the default arguments (8.3.6) or in the member function body) is looked up as described in 3.4. — end note ] [ Example: struct X { typedef int T; static T count; void f(T); }; void X::f(T t = count) { }

6

7 8 9

The member function f of class X is deﬁned in global scope; the notation X::f speciﬁes that the function f is a member of class X and in the scope of class X. In the function deﬁnition, the parameter type T refers to the typedef member T declared in class X and the default argument count refers to the static data member count declared in class X. — end example ] A static local variable in a member function always refers to the same object, whether or not the member function is inline. Previously declared member functions may be mentioned in friend declarations. Member functions of a local class shall be deﬁned inline in their class deﬁnition, if they are deﬁned at all. [ Note: A member function can be declared (but not deﬁned) using a typedef for a function type. The resulting member function has exactly the same type as it would have if the function declarator were provided explicitly, see 8.3.5. For example, typedef void fv(void); typedef void fvc(void) const; struct S { fv memfunc1; // equivalent to: void memfunc1(void); void memfunc2();

§ 9.3

210

c ISO/IEC

N3337

fvc memfunc3; // equivalent to: void memfunc3(void) const; }; fv S::* pmfv1 = &S::memfunc1; fv S::* pmfv2 = &S::memfunc2; fvc S::* pmfv3 = &S::memfunc3;

Also see 14.3. — end note ]

9.3.1
1

Nonstatic member functions

[class.mfct.non-static]

2

3

A non-static member function may be called for an object of its class type, or for an object of a class derived (Clause 10) from its class type, using the class member access syntax (5.2.5, 13.3.1.1). A non-static member function may also be called directly using the function call syntax (5.2.2, 13.3.1.1) from within the body of a member function of its class or of a class derived from its class. If a non-static member function of a class X is called for an object that is not of type X, or of a type derived from X, the behavior is undeﬁned. When an id-expression (5.1) that is not part of a class member access syntax (5.2.5) and not used to form a pointer to member (5.3.1) is used in a member of class X in a context where this can be used (5.1.1), if name lookup (3.4) resolves the name in the id-expression to a non-static non-type member of some class C, and if either the id-expression is potentially evaluated or C is X or a base class of X, the id-expression is transformed into a class member access expression (5.2.5) using (*this) (9.3.2) as the postﬁx-expression to the left of the . operator. [ Note: If C is not X or a base class of X, the class member access expression is ill-formed. — end note ] Similarly during name lookup, when an unqualiﬁed-id (5.1) used in the deﬁnition of a member function for class X resolves to a static member, an enumerator or a nested type of class X or of a base class of X, the unqualiﬁed-id is transformed into a qualiﬁed-id (5.1) in which the nested-name-speciﬁer names the class of the member function. [ Example: struct tnode { char tword[20]; int count; tnode *left; tnode *right; void set(const char*, tnode* l, tnode* r); }; void tnode::set(const char* w, tnode* l, tnode* r) { count = strlen(w)+1; if (sizeof(tword)aa = 1; // OK

8

The assignment to plain aa is ill-formed since the member name is not visible outside the union, and even if it were visible, it is not associated with any particular object. — end example ] [ Note: Initialization of unions with no user-declared constructors is described in (8.5.1). — end note ] A union-like class is a union or a class that has an anonymous union as a direct member. A union-like class X has a set of variant members. If X is a union its variant members are the non-static data members; § 9.5 215

c ISO/IEC

N3337

otherwise, its variant members are the non-static data members of all anonymous unions that are members of X.

9.6
1

Bit-ﬁelds identiﬁeropt attribute-speciﬁer-seqopt : constant-expression

[class.bit]

A member-declarator of the form speciﬁes a bit-ﬁeld; its length is set oﬀ from the bit-ﬁeld name by a colon. The optional attributespeciﬁer-seq appertains to the entity being declared. The bit-ﬁeld attribute is not part of the type of the class member. The constant-expression shall be an integral constant expression with a value greater than or equal to zero. The value of the integral constant expression may be larger than the number of bits in the object representation (3.9) of the bit-ﬁeld’s type; in such cases the extra bits are used as padding bits and do not participate in the value representation (3.9) of the bit-ﬁeld. Allocation of bit-ﬁelds within a class object is implementation-deﬁned. Alignment of bit-ﬁelds is implementation-deﬁned. Bit-ﬁelds are packed into some addressable allocation unit. [ Note: Bit-ﬁelds straddle allocation units on some machines and not on others. Bit-ﬁelds are assigned right-to-left on some machines, left-to-right on others. — end note ] A declaration for a bit-ﬁeld that omits the identiﬁer declares an unnamed bit-ﬁeld. Unnamed bit-ﬁelds are not members and cannot be initialized. [ Note: An unnamed bit-ﬁeld is useful for padding to conform to externally-imposed layouts. — end note ] As a special case, an unnamed bit-ﬁeld with a width of zero speciﬁes alignment of the next bit-ﬁeld at an allocation unit boundary. Only when declaring an unnamed bit-ﬁeld may the value of the constant-expression be equal to zero. A bit-ﬁeld shall not be a static member. A bit-ﬁeld shall have integral or enumeration type (3.9.1). It is implementation-deﬁned whether a plain (neither explicitly signed nor unsigned) char, short, int, long, or long long bit-ﬁeld is signed or unsigned. A bool value can successfully be stored in a bit-ﬁeld of any nonzero size. The address-of operator & shall not be applied to a bit-ﬁeld, so there are no pointers to bitﬁelds. A non-const reference shall not be bound to a bit-ﬁeld (8.5.3). [ Note: If the initializer for a reference of type const T& is an lvalue that refers to a bit-ﬁeld, the reference is bound to a temporary initialized to hold the value of the bit-ﬁeld; the reference is not bound to the bit-ﬁeld directly. See 8.5.3. — end note ] If the value true or false is stored into a bit-ﬁeld of type bool of any size (including a one bit bit-ﬁeld), the original bool value and the value of the bit-ﬁeld shall compare equal. If the value of an enumerator is stored into a bit-ﬁeld of the same enumeration type and the number of bits in the bit-ﬁeld is large enough to hold all the values of that enumeration type (7.2), the original enumerator value and the value of the bit-ﬁeld shall compare equal. [ Example: enum BOOL { FALSE=0, TRUE=1 }; struct A { BOOL b:1; }; A a; void f() { a.b = TRUE; if (a.b == TRUE) { /∗ ... ∗/ } }

2

3

4

// yields true

— end example ]

9.7
1

Nested class declarations

[class.nest]

A class can be declared within another class. A class declared within another is called a nested class. The name of a nested class is local to its enclosing class. The nested class is in the scope of its enclosing class. [ Note: See 5.1 for restrictions on the use of non-static data members and non-static member functions. — end note ] [ Example: int x;

§ 9.7

216

c ISO/IEC

N3337

int y; struct enclose { int x; static int s; struct inner { void f(int i) { int a = sizeof(x); // x = i; // s = i; // ::x = i; // y = i; // } void g(enclose* p, int i) { p->x = i; // } }; }; inner* p = 0;
2

OK: operand of sizeof is an unevaluated operand error: assign to enclose::x OK: assign to enclose::s OK: assign to global x OK: assign to global y

OK: assign to enclose::x

// error: inner not in scope

— end example ] Member functions and static data members of a nested class can be deﬁned in a namespace scope enclosing the deﬁnition of their class. [ Example: struct enclose struct inner static int void f(int }; }; { { x; i);

int enclose::inner::x = 1; void enclose::inner::f(int i) { /∗ ... ∗/ }
3

— end example ] If class X is deﬁned in a namespace scope, a nested class Y may be declared in class X and later deﬁned in the deﬁnition of class X or be later deﬁned in a namespace scope enclosing the deﬁnition of class X. [ Example: class E { class I1; class I2; class I1 { }; }; class E::I2 { }; // forward declaration of nested class // deﬁnition of nested class // deﬁnition of nested class

4

— end example ] Like a member function, a friend function (11.3) deﬁned within a nested class is in the lexical scope of that class; it obeys the same rules for name binding as a static member function of that class (9.4), but it has no special access rights to members of an enclosing class.

9.8
1

Local class declarations

[class.local]

A class can be declared within a function deﬁnition; such a class is called a local class. The name of a local class is local to its enclosing scope. The local class is in the scope of the enclosing scope, and has the same

§ 9.8

217

c ISO/IEC

N3337

access to names outside the function as does the enclosing function. Declarations in a local class shall not odr-use (3.2) a variable with automatic storage duration from an enclosing scope. [ Example: int x; void f() { static int s ; int x; const int N = 5; extern int q(); struct local { int g() { return x; } int h() { return s; } int k() { return ::x; } int l() { return q(); } int m() { return N; } int *n() { return &N; } }; } local* p = 0;
2

// // // // // //

error: odr-use of automatic variable x OK OK OK OK: not an odr-use error: odr-use of automatic variable N

// error: local not in scope

3

4

— end example ] An enclosing function has no special access to members of the local class; it obeys the usual access rules (Clause 11). Member functions of a local class shall be deﬁned within their class deﬁnition, if they are deﬁned at all. If class X is a local class a nested class Y may be declared in class X and later deﬁned in the deﬁnition of class X or be later deﬁned in the same scope as the deﬁnition of class X. A class nested within a local class is a local class. A local class shall not have static data members.

9.9
1

Nested type names

[class.nested.type]

Type names obey exactly the same scope rules as other names. In particular, type names deﬁned within a class deﬁnition cannot be used outside their class without qualiﬁcation. [ Example: struct X { typedef int I; class Y { /∗ ... ∗/ }; I a; }; I b; Y c; X::Y d; X::I e; // // // // error error OK OK

— end example ]

§ 9.9

218

c ISO/IEC

N3337

10
1

Derived classes

[class.derived]

A list of base classes can be speciﬁed in a class deﬁnition using the notation: base-clause: : base-speciﬁer-list base-speciﬁer-list: base-speciﬁer ...opt base-speciﬁer-list , base-speciﬁer ...opt base-speciﬁer: attribute-speciﬁer-seqopt base-type-speciﬁer attribute-speciﬁer-seqopt virtual access-speciﬁeropt base-type-speciﬁer attribute-speciﬁer-seqopt access-speciﬁer virtualopt base-type-speciﬁer class-or-decltype: nested-name-speciﬁeropt class-name decltype-speciﬁer base-type-speciﬁer: class-or-decltype access-speciﬁer: private protected public

2

3

The optional attribute-speciﬁer-seq appertains to the base-speciﬁer. The type denoted by a base-type-speciﬁer shall be a class type that is not an incompletely deﬁned class (Clause 9); this class is called a direct base class for the class being deﬁned. During the lookup for a base class name, non-type names are ignored (3.3.10). If the name found is not a class-name, the program is ill-formed. A class B is a base class of a class D if it is a direct base class of D or a direct base class of one of D’s base classes. A class is an indirect base class of another if it is a base class but not a direct base class. A class is said to be (directly or indirectly) derived from its (direct or indirect) base classes. [ Note: See Clause 11 for the meaning of access-speciﬁer. — end note ] Unless redeclared in the derived class, members of a base class are also considered to be members of the derived class. The base class members are said to be inherited by the derived class. Inherited members can be referred to in expressions in the same manner as other members of the derived class, unless their names are hidden or ambiguous (10.2). [ Note: The scope resolution operator :: (5.1) can be used to refer to a direct or indirect base member explicitly. This allows access to a name that has been redeclared in the derived class. A derived class can itself serve as a base class subject to access control; see 11.2. A pointer to a derived class can be implicitly converted to a pointer to an accessible unambiguous base class (4.10). An lvalue of a derived class type can be bound to a reference to an accessible unambiguous base class (8.5.3). — end note ] The base-speciﬁer-list speciﬁes the type of the base class subobjects contained in an object of the derived class type. [ Example: struct Base { int a, b, c; }; struct Derived : Base { int b; }; struct Derived2 : Derived {

Derived classes

219

c ISO/IEC

N3337

int c; };

4 5

Here, an object of class Derived2 will have a subobject of class Derived which in turn will have a subobject of class Base. — end example ] A base-speciﬁer followed by an ellipsis is a pack expansion (14.5.3). The order in which the base class subobjects are allocated in the most derived object (1.8) is unspeciﬁed. [ Note: a derived class and its base class subobjects can be represented by a directed acyclic graph (DAG) where an arrow means “directly derived from.” A DAG of subobjects is often referred to as a “subobject lattice.”

Base Derived1 Derived2

Figure 2 — Directed acyclic graph
6 7

8

The arrows need not have a physical representation in memory. — end note ] [ Note: Initialization of objects representing base classes can be speciﬁed in constructors; see 12.6.2. — end note ] [ Note: A base class subobject might have a layout (3.7) diﬀerent from the layout of a most derived object of the same type. A base class subobject might have a polymorphic behavior (12.7) diﬀerent from the polymorphic behavior of a most derived object of the same type. A base class subobject may be of zero size (Clause 9); however, two subobjects that have the same class type and that belong to the same most derived object must not be allocated at the same address (5.10). — end note ]

10.1
1

Multiple base classes

[class.mi]

A class can be derived from any number of base classes. [ Note: The use of more than one direct base class is often called multiple inheritance. — end note ] [ Example: class class class class A B C D { { { : /∗ ... ∗/ }; /∗ ... ∗/ }; /∗ ... ∗/ }; public A, public B, public C { /∗ ... ∗/ };

2

3

— end example ] [ Note: The order of derivation is not signiﬁcant except as speciﬁed by the semantics of initialization by constructor (12.6.2), cleanup (12.4), and storage layout (9.2, 11.1). — end note ] A class shall not be speciﬁed as a direct base class of a derived class more than once. [ Note: A class can be an indirect base class more than once and can be a direct and an indirect base class. There are limited things that can be done with such a class. The non-static data members and member functions of the direct base class cannot be referred to in the scope of the derived class. However, the static members, enumerations and types can be unambiguously referred to. — end note ] [ Example: class X { /∗ ... ∗/ }; class Y : public X, public X { /∗ ... ∗/ }; // ill-formed

§ 10.1

220

c ISO/IEC

N3337

class class class class class
4

L A B C D

{ : : : :

public: int next; public L { /∗ ... ∗/ public L { /∗ ... ∗/ public A, public B public A, public L

/∗ ... ∗/ }; }; }; { void f(); /∗ ... ∗/ }; { void f(); /∗ ... ∗/ };

// well-formed // well-formed

— end example ] A base class speciﬁer that does not contain the keyword virtual, speciﬁes a non-virtual base class. A base class speciﬁer that contains the keyword virtual, speciﬁes a virtual base class. For each distinct occurrence of a non-virtual base class in the class lattice of the most derived class, the most derived object (1.8) shall contain a corresponding distinct base class subobject of that type. For each distinct base class that is speciﬁed virtual, the most derived object shall contain a single base class subobject of that type. [ Example: for an object of class type C, each distinct occurrence of a (non-virtual) base class L in the class lattice of C corresponds one-to-one with a distinct L subobject within the object of type C. Given the class C deﬁned above, an object of class C will have two subobjects of class L as shown below.

L A C

L B

Figure 3 — Non-virtual base
5

In such lattices, explicit qualiﬁcation can be used to specify which subobject is meant. The body of function C::f could refer to the member next of each L subobject: void C::f() { A::next = B::next; } // well-formed

6

Without the A:: or B:: qualiﬁers, the deﬁnition of C::f above would be ill-formed because of ambiguity (10.2). For another example, class class class class V A B C { : : : /∗ ... ∗/ }; virtual public V { /∗ ... ∗/ }; virtual public V { /∗ ... ∗/ }; public A, public B { /∗ ... ∗/ };

7

for an object c of class type C, a single subobject of type V is shared by every base subobject of c that has a virtual base class of type V. Given the class C deﬁned above, an object of class C will have one subobject of class V, as shown below. A class can have both virtual and non-virtual base classes of a given type. class class class class class B { /∗ ... ∗/ }; X : virtual public B { /∗ ... ∗/ }; Y : virtual public B { /∗ ... ∗/ }; Z : public B { /∗ ... ∗/ }; AA : public X, public Y, public Z { /∗ ... ∗/ };

For an object of class AA, all virtual occurrences of base class B in the class lattice of AA correspond to a single B subobject within the object of type AA, and every other occurrence of a (non-virtual) base class B in the class lattice of AA corresponds one-to-one with a distinct B subobject within the object of type AA. § 10.1 221

c ISO/IEC

N3337

V A C B

Figure 4 — Virtual base

B X AA Y

B Z

Figure 5 — Virtual and non-virtual base

Given the class AA deﬁned above, class AA has two subobjects of class B: Z’s B and the virtual B shared by X and Y, as shown below. — end example ]

10.2
1

Member name lookup

[class.member.lookup]

2 3

4

5

6

Member name lookup determines the meaning of a name (id-expression) in a class scope (3.3.7). Name lookup can result in an ambiguity, in which case the program is ill-formed. For an id-expression, name lookup begins in the class scope of this; for a qualiﬁed-id, name lookup begins in the scope of the nestedname-speciﬁer. Name lookup takes place before access control (3.4, Clause 11). The following steps deﬁne the result of name lookup for a member name f in a class scope C. The lookup set for f in C, called S(f, C), consists of two component sets: the declaration set, a set of members named f; and the subobject set, a set of subobjects where declarations of these members (possibly including using-declarations) were found. In the declaration set, using-declarations are replaced by the members they designate, and type declarations (including injected-class-names) are replaced by the types they designate. S(f, C) is calculated as follows: If C contains a declaration of the name f, the declaration set contains every declaration of f declared in C that satisﬁes the requirements of the language construct in which the lookup occurs. [ Note: Looking up a name in an elaborated-type-speciﬁer (3.4.4) or base-speciﬁer (Clause 10), for instance, ignores all nontype declarations, while looking up a name in a nested-name-speciﬁer (3.4.3) ignores function, variable, and enumerator declarations. As another example, looking up a name in a using-declaration (7.3.3) includes the declaration of a class or enumeration that would ordinarily be hidden by another declaration of that name in the same scope. — end note ] If the resulting declaration set is not empty, the subobject set contains C itself, and calculation is complete. Otherwise (i.e., C does not contain a declaration of f or the resulting declaration set is empty), S(f, C) is initially empty. If C has base classes, calculate the lookup set for f in each direct base class subobject Bi , and merge each such lookup set S(f, Bi ) in turn into S(f, C). The following steps deﬁne the result of merging lookup set S(f, Bi ) into the intermediate S(f, C):

§ 10.2

222

c ISO/IEC

N3337

— If each of the subobject members of S(f, Bi ) is a base class subobject of at least one of the subobject members of S(f, C), or if S(f, Bi ) is empty, S(f, C) is unchanged and the merge is complete. Conversely, if each of the subobject members of S(f, C) is a base class subobject of at least one of the subobject members of S(f, Bi ), or if S(f, C) is empty, the new S(f, C) is a copy of S(f, Bi ). — Otherwise, if the declaration sets of S(f, Bi ) and S(f, C) diﬀer, the merge is ambiguous: the new S(f, C) is a lookup set with an invalid declaration set and the union of the subobject sets. In subsequent merges, an invalid declaration set is considered diﬀerent from any other. — Otherwise, the new S(f, C) is a lookup set with the shared set of declarations and the union of the subobject sets.
7

The result of name lookup for f in C is the declaration set of S(f, C). If it is an invalid set, the program is ill-formed. [ Example: struct A { int x; }; struct B { float x; }; struct C: public A, public struct D: public virtual C struct E: public virtual C struct F: public D, public int main() { F f; f.x = 0; } // // { }; // }; // char x; }; // { }; // S(x,A) = { { A::x }, S(x,B) = { { B::x }, S(x,C) = { invalid, { S(x,D) = S(x,C) S(x,E) = { { E::x }, S(x,F) = S(x,E) { A}} { B}} A in C, B in C } } { E}}

B { { E

// OK, lookup ﬁnds E::x

8

S(x, F ) is unambiguous because the A and B base subobjects of D are also base subobjects of E, so S(x, D) is discarded in the ﬁrst merge step. — end example ] If the name of an overloaded function is unambiguously found, overloading resolution (13.3) also takes place before access control. Ambiguities can often be resolved by qualifying a name with its class name. [ Example: struct A { int f(); }; struct B { int f(); }; struct C : A, B { int f() { return A::f() + B::f(); } };

9

— end example ] [ Note: A static member, a nested type or an enumerator deﬁned in a base class T can unambiguously be found even if an object has more than one base class subobject of type T. Two base class subobjects share the non-static member subobjects of their common virtual base classes. — end note ] [ Example: struct V int v; }; struct A int a; static enum { {

{ int e }; s;

§ 10.2

223

c ISO/IEC

N3337

}; struct B : A, virtual V { }; struct C : A, virtual V { }; struct D : B, C { }; void f(D* pd) { pd->v++; pd->s++; int i = pd->e; pd->a++; }
10

// // // //

OK: only one v (virtual) OK: only one s (static) OK: only one e (enumerator) error, ambiguous: two as in D

— end example ] [ Note: When virtual base classes are used, a hidden declaration can be reached along a path through the subobject lattice that does not pass through the hiding declaration. This is not an ambiguity. The identical use with non-virtual base classes is an ambiguity; in that case there is no unique instance of the name that hides all the others. — end note ] [ Example: struct V { struct W { struct B : int f(); int g(); }; struct C : int f(); int x; }; int g(); int y; }; virtual V, W { int x; int y; virtual V, W { };

struct D : B, C { void glorp(); };

W B

V C D

W

Figure 6 — Name lookup
11

[ Note: The names declared in V and the left-hand instance of W are hidden by those in B, but the names declared in the right-hand instance of W are not hidden at all. — end note ] void D::glorp() { x++; f(); y++; g(); } // // // // OK: B::x hides V::x OK: B::f() hides V::f() error: B::y and C’s W::y error: B::g() and C’s W::g()

12

— end example ] An explicit or implicit conversion from a pointer to or an expression designating an object of a derived class to a pointer or reference to one of its base classes shall unambiguously refer to a unique object representing the base class. [ Example: struct V { };

§ 10.2

224

c ISO/IEC

N3337

struct struct struct struct

A B C D

{ : : :

}; A, virtual V { }; A, virtual V { }; B, C { };

void g() { D d; B* pb = &d; A* pa = &d; V* pv = &d; }
13

// error, ambiguous: C’s A or B’s A? // OK: only one V subobject

— end example ] [ Note: Even if the result of name lookup is unambiguous, use of a name found in multiple subobjects might still be ambiguous (4.11, 5.2.5, 11.2). — end note ] [ Example: struct B1 { void f(); static void f(int); int i; }; struct B2 { void f(double); }; struct I1: B1 { }; struct I2: B1 { }; struct D: I1, I2, B2 { using B1::f; using B2::f; void g() { f(); f(0); f(0.0); int B1::* mpB1 = &D::i; int D::* mpD = &D::i; } };

// // // // //

Ambiguous conversion of this Unambiguous (static) Unambiguous (only one B2) Unambiguous Ambiguous conversion

— end example ]

10.3
1

Virtual functions

[class.virtual]

2

Virtual functions support dynamic binding and object-oriented programming. A class that declares or inherits a virtual function is called a polymorphic class. If a virtual member function vf is declared in a class Base and in a class Derived, derived directly or indirectly from Base, a member function vf with the same name, parameter-type-list (8.3.5), cv-qualiﬁcation, and refqualiﬁer (or absence of same) as Base::vf is declared, then Derived::vf is also virtual (whether or not it is so declared) and it overrides 111 Base::vf. For convenience we say that any virtual function overrides itself. A virtual member function C::vf of a class object S is a ﬁnal overrider unless the most derived class (1.8) of which S is a base class subobject (if any) declares or inherits another member function that overrides vf. In a derived class, if a virtual member function of a base class subobject has more than one ﬁnal overrider the program is ill-formed. [ Example:
111) A function with the same name but a diﬀerent parameter list (Clause 13) as a virtual function is not necessarily virtual and does not override. The use of the virtual speciﬁer in the declaration of an overriding function is legal but redundant (has empty semantics). Access control (Clause 11) is not considered in determining overriding.

§ 10.3

225

c ISO/IEC

N3337

struct A { virtual void f(); }; struct B : virtual A { virtual void f(); }; struct C : B , virtual A { using A::f; }; void foo() { C c; c.f(); c.C::f(); }

// calls B::f, the ﬁnal overrider // calls A::f because of the using-declaration

— end example ] [ Example: struct struct struct struct A B C D { : : : virtual void f(); }; A { }; A { void f(); }; B, C { }; // OK: A::f and C::f are the ﬁnal overriders // for the B and C subobjects, respectively

3

— end example ] [ Note: A virtual member function does not have to be visible to be overridden, for example, struct B { virtual void f(); }; struct D : B { void f(int); }; struct D2 : D { void f(); };

4

the function f(int) in class D hides the virtual function f() in its base class B; D::f(int) is not a virtual function. However, f() declared in class D2 has the same name and the same parameter list as B::f(), and therefore is a virtual function that overrides the function B::f() even though B::f() is not visible in class D2. — end note ] If a virtual function f in some class B is marked with the virt-speciﬁer final and in a class D derived from B a function D::f overrides B::f, the program is ill-formed. [ Example: struct B { virtual void f() const final; }; struct D : B { void f() const; };

// error: D::f attempts to override final B::f

5

— end example ] If a virtual function is marked with the virt-speciﬁer override and does not override a member function of a base class, the program is ill-formed. [ Example:

§ 10.3

226

c ISO/IEC

N3337

struct B { virtual void f(int); }; struct D : B { virtual void f(long) override; virtual void f(int) override; };
6

// error: wrong signature overriding B::f // OK

7

— end example ] Even though destructors are not inherited, a destructor in a derived class overrides a base class destructor declared virtual; see 12.4 and 12.5. The return type of an overriding function shall be either identical to the return type of the overridden function or covariant with the classes of the functions. If a function D::f overrides a function B::f, the return types of the functions are covariant if they satisfy the following criteria: — both are pointers to classes, both are lvalue references to classes, or both are rvalue references to classes112 — the class in the return type of B::f is the same class as the class in the return type of D::f, or is an unambiguous and accessible direct or indirect base class of the class in the return type of D::f — both pointers or references have the same cv-qualiﬁcation and the class type in the return type of D::f has the same cv-qualiﬁcation as or less cv-qualiﬁcation than the class type in the return type of B::f.

8

If the return type of D::f diﬀers from the return type of B::f, the class type in the return type of D::f shall be complete at the point of declaration of D::f or shall be the class type D. When the overriding function is called as the ﬁnal overrider of the overridden function, its result is converted to the type returned by the (statically chosen) overridden function (5.2.2). [ Example: class B { }; class D : private B { friend class Derived; }; struct Base { virtual void vf1(); virtual void vf2(); virtual void vf3(); virtual B* vf4(); virtual B* vf5(); void f(); }; struct No_good : public Base { D* vf4(); // error: B (base class of D) inaccessible }; class A; struct Derived : public Base { void vf1(); // virtual and overrides Base::vf1() void vf2(int); // not virtual, hides Base::vf2() char vf3(); // error: invalid diﬀerence in return type only D* vf4(); // OK: returns pointer to derived class A* vf5(); // error: returns pointer to incomplete class void f(); };
112) Multi-level pointers to classes or references to multi-level pointers to classes are not allowed.

§ 10.3

227

c ISO/IEC

N3337

void g() { Derived d; Base* bp = &d; bp->vf1(); bp->vf2(); bp->f(); B* p = bp->vf4(); Derived* dp = &d; D* q = dp->vf4(); dp->vf2(); }
9

// // // // // // //

standard conversion: Derived* to Base* calls Derived::vf1() calls Base::vf2() calls Base::f() (not virtual) calls Derived::pf() and converts the result to B*

// calls Derived::pf() and does not // convert the result to B* // ill-formed: argument mismatch

10

11

12

— end example ] [ Note: The interpretation of the call of a virtual function depends on the type of the object for which it is called (the dynamic type), whereas the interpretation of a call of a non-virtual member function depends only on the type of the pointer or reference denoting that object (the static type) (5.2.2). — end note ] [ Note: The virtual speciﬁer implies membership, so a virtual function cannot be a nonmember (7.1.2) function. Nor can a virtual function be a static member, since a virtual function call relies on a speciﬁc object for determining which function to invoke. A virtual function declared in one class can be declared a friend in another class. — end note ] A virtual function declared in a class shall be deﬁned, or declared pure (10.4) in that class, or both; but no diagnostic is required (3.2). [ Example: here are some uses of virtual functions with multiple base classes: struct A { virtual void f(); }; struct B1 : A { void f(); }; struct B2 : A { void f(); }; struct D : B1, B2 { }; // D has two separate A subobjects // note non-virtual derivation

void foo() { D d; // A* ap = &d; // would be ill-formed: ambiguous B1* b1p = &d; A* ap = b1p; D* dp = &d; ap->f(); // calls D::B1::f dp->f(); // ill-formed: ambiguous }

13

In class D above there are two occurrences of class A and hence two occurrences of the virtual member function A::f. The ﬁnal overrider of B1::A::f is B1::f and the ﬁnal overrider of B2::A::f is B2::f. The following example shows a function that does not have a unique ﬁnal overrider: § 10.3 228

c ISO/IEC

N3337

struct A { virtual void f(); }; struct VB1 : virtual A { void f(); }; struct VB2 : virtual A { void f(); }; struct Error : VB1, VB2 { }; struct Okay : VB1, VB2 { void f(); }; // ill-formed // note virtual derivation

14

Both VB1::f and VB2::f override A::f but there is no overrider of both of them in class Error. This example is therefore ill-formed. Class Okay is well formed, however, because Okay::f is a ﬁnal overrider. The following example uses the well-formed classes from above. struct VB1a : virtual A { }; struct Da : VB1a, VB2 { }; void foe() { VB1a* vb1ap = new Da; vb1ap->f(); } // does not declare f

// calls VB2::f

15

— end example ] Explicit qualiﬁcation with the scope operator (5.1) suppresses the virtual call mechanism. [ Example: class B { public: virtual void f(); }; class D : public B { public: void f(); }; void D::f() { /∗ ... ∗/ B::f(); }

16

Here, the function call in D::f really does call B::f and not D::f. — end example ] A function with a deleted deﬁnition (8.4) shall not override a function that does not have a deleted deﬁnition. Likewise, a function that does not have a deleted deﬁnition shall not override a function with a deleted deﬁnition.

10.4
1

Abstract classes

[class.abstract]

2

The abstract class mechanism supports the notion of a general concept, such as a shape, of which only more concrete variants, such as circle and square, can actually be used. An abstract class can also be used to deﬁne an interface for which derived classes provide a variety of implementations. An abstract class is a class that can be used only as a base class of some other class; no objects of an abstract class can be created except as subobjects of a class derived from it. A class is abstract if it has at least one pure virtual function. [ Note: Such a function might be inherited: see below. — end note ] A virtual function is speciﬁed pure by using a pure-speciﬁer (9.2) in the function declaration in the class deﬁnition. A

§ 10.4

229

c ISO/IEC

N3337

pure virtual function need be deﬁned only if called with, or as if with (12.4), the qualiﬁed-id syntax (5.1). [ Example: class point { /∗ ... ∗/ }; class shape { // abstract class point center; public: point where() { return center; } void move(point p) { center=p; draw(); } virtual void rotate(int) = 0; // pure virtual virtual void draw() = 0; // pure virtual };

— end example ] [ Note: A function declaration cannot provide both a pure-speciﬁer and a deﬁnition — end note ] [ Example: struct C { virtual void f() = 0 { }; };
3

// ill-formed

— end example ] An abstract class shall not be used as a parameter type, as a function return type, or as the type of an explicit conversion. Pointers and references to an abstract class can be declared. [ Example: shape x; shape* p; shape f(); void g(shape); shape& h(shape&); // // // // // error: object of abstract class OK error error OK

4

— end example ] A class is abstract if it contains or inherits at least one pure virtual function for which the ﬁnal overrider is pure virtual. [ Example: class ab_circle : public shape { int radius; public: void rotate(int) { } // ab_circle::draw() is a pure virtual };

Since shape::draw() is a pure virtual function ab_circle::draw() is a pure virtual by default. The alternative declaration, class circle : public shape { int radius; public: void rotate(int) { } void draw(); };

// a deﬁnition is required somewhere

5

6

would make class circle nonabstract and a deﬁnition of circle::draw() must be provided. — end example ] [ Note: An abstract class can be derived from a class that is not abstract, and a pure virtual function may override a virtual function which is not pure. — end note ] Member functions can be called from a constructor (or destructor) of an abstract class; the eﬀect of making a virtual call (10.3) to a pure virtual function directly or indirectly for the object being created (or destroyed) from such a constructor (or destructor) is undeﬁned. § 10.4 230

c ISO/IEC

N3337

11
1

Member access control

[class.access]

A member of a class can be — private; that is, its name can be used only by members and friends of the class in which it is declared. — protected; that is, its name can be used only by members and friends of the class in which it is declared, by classes derived from that class, and by their friends (see 11.4). — public; that is, its name can be used anywhere without access restriction.

2

3

A member of a class can also access all the names to which the class has access. A local class of a member function may access the same names that the member function itself may access.113 Members of a class deﬁned with the keyword class are private by default. Members of a class deﬁned with the keywords struct or union are public by default. [ Example: class X { int a; }; struct S { int a; }; // X::a is private by default

// S::a is public by default

4

— end example ] Access control is applied uniformly to all names, whether the names are referred to from declarations or expressions. [ Note: Access control applies to names nominated by friend declarations (11.3) and usingdeclarations (7.3.3). — end note ] In the case of overloaded function names, access control is applied to the function selected by overload resolution. [ Note: Because access control applies to names, if access control is applied to a typedef name, only the accessibility of the typedef name itself is considered. The accessibility of the entity referred to by the typedef is not considered. For example, class A { class B { }; public: typedef B BB; }; void f() { A::BB x; A::B y; }

// OK, typedef name A::BB is public // access error, A::B is private

5

6

— end note ] It should be noted that it is access to members and base classes that is controlled, not their visibility. Names of members are still visible, and implicit conversions to base classes are still considered, when those members and base classes are inaccessible. The interpretation of a given construct is established without regard to access control. If the interpretation established makes use of inaccessible member names or base classes, the construct is ill-formed. All access controls in Clause 11 aﬀect the ability to access a class member name from the declaration of a particular entity, including parts of the declaration preceding the name of the entity being declared and, if the
113) Access permissions are thus transitive and cumulative to nested and local classes.

Member access control

231

c ISO/IEC

N3337

entity is a class, the deﬁnitions of members of the class appearing outside the class’s member-speciﬁcation. [ Note: this access also applies to implicit references to constructors, conversion functions, and destructors. — end note ] [ Example: class A { typedef int I; // private member I f(); friend I g(I); static I x; template struct Q; template friend struct R; protected: struct B { }; }; A::I A::f() { return 0; } A::I g(A::I p = A::x); A::I g(A::I p) { return 0; } A::I A::x = 0; template struct A::Q { }; template struct R { }; struct D: A::B, A { };
7

8

9

Here, all the uses of A::I are well-formed because A::f, A::x, and A::Q are members of class A and g and R are friends of class A. This implies, for example, that access checking on the ﬁrst use of A::I must be deferred until it is determined that this use of A::I is as the return type of a member of class A. Similarly, the use of A::B as a base-speciﬁer is well-formed because D is derived from A, so checking of base-speciﬁers must be deferred until the entire base-speciﬁer-list has been seen. — end example ] The names in a default argument (8.3.6) are bound at the point of declaration, and access is checked at that point rather than at any points of use of the default argument. Access checking for default arguments in function templates and in member functions of class templates is performed as described in 14.7.1. The names in a default template-argument (14.1) have their access checked in the context in which they appear rather than at any points of use of the default template-argument. [ Example: class B { }; template class C { protected: typedef T TT; }; template class D : public U { }; D * d; // access error, C::TT is protected

— end example ]

11.1
1

Access speciﬁers access-speciﬁer : member-speciﬁcationopt

[class.access.spec]

Member declarations can be labeled by an access-speciﬁer (Clause 10): An access-speciﬁer speciﬁes the access rules for members following it until the end of the class or until another access-speciﬁer is encountered. [ Example: class X { int a; // X::a is private by default: class used

§ 11.1

232

c ISO/IEC

N3337

public: int b; int c; };
2

// X::b is public // X::c is public

— end example ] Any number of access speciﬁers is allowed and no particular order is required. [ Example: struct S { int a; protected: int b; private: int c; public: int d; }; // S::a is public by default: struct used // S::b is protected // S::c is private // S::d is public

3

4

— end example ] [ Note: The eﬀect of access control on the order of allocation of data members is described in 9.2. — end note ] When a member is redeclared within its class deﬁnition, the access speciﬁed at its redeclaration shall be the same as at its initial declaration. [ Example: struct S { class A; enum E : int; private: class A { }; // error: cannot change access enum E: int { e0 }; // error: cannot change access };

5

— end example ] [ Note: In a derived class, the lookup of a base class name will ﬁnd the injected-class-name instead of the name of the base class in the scope in which it was declared. The injected-class-name might be less accessible than the name of the base class in the scope in which it was declared. — end note ] [ Example: class A { }; class B : private A { }; class C : public B { A *p; // error: injected-class-name A is inaccessible ::A *q; // OK };

— end example ]

11.2
1

Accessibility of base classes and base class members

[class.access.base]

If a class is declared to be a base class (Clause 10) for another class using the public access speciﬁer, the public members of the base class are accessible as public members of the derived class and protected members of the base class are accessible as protected members of the derived class. If a class is declared to be a base class for another class using the protected access speciﬁer, the public and protected members of the base class are accessible as protected members of the derived class. If a class is declared to be a base class for another class using the private access speciﬁer, the public and protected members of the base class are accessible as private members of the derived class114 .
114) As speciﬁed previously in Clause 11, private members of a base class remain inaccessible even to derived classes unless friend declarations within the base class deﬁnition are used to grant access explicitly.

§ 11.2

233

c ISO/IEC

N3337

2

In the absence of an access-speciﬁer for a base class, public is assumed when the derived class is deﬁned with the class-key struct and private is assumed when the class is deﬁned with the class-key class. [ Example: class B { /∗ ... ∗/ }; class D1 : private B { /∗ ... ∗/ }; class D2 : public B { /∗ ... ∗/ }; class D3 : B { /∗ ... ∗/ }; // B private by default struct D4 : public B { /∗ ... ∗/ }; struct D5 : private B { /∗ ... ∗/ }; struct D6 : B { /∗ ... ∗/ }; // B public by default class D7 : protected B { /∗ ... ∗/ }; struct D8 : protected B { /∗ ... ∗/ };

3

Here B is a public base of D2, D4, and D6, a private base of D1, D3, and D5, and a protected base of D7 and D8. — end example ] [ Note: A member of a private base class might be inaccessible as an inherited member name, but accessible directly. Because of the rules on pointer conversions (4.10) and explicit casts (5.4), a conversion from a pointer to a derived class to a pointer to an inaccessible base class might be ill-formed if an implicit conversion is used, but well-formed if an explicit cast is used. For example, class B { public: int mi; static int si; }; class D : private B { }; class DD : public D { void f(); }; void DD::f() { mi = 3; si = 3; ::B b; b.mi = 3; b.si = 3; ::B::si = 3; ::B* bp1 = this; ::B* bp2 = (::B*)this; bp2->mi = 3; }

// non-static member // static member

// error: mi is private in D // error: si is private in D // // // // // // OK ( b.mi is diﬀerent from this->mi) OK ( b.si is diﬀerent from this->si) OK error: B is a private base class OK with cast OK: access through a pointer to B.

4

— end note ] A base class B of N is accessible at R, if — an invented public member of B would be a public member of N, or — R occurs in a member or friend of class N, and an invented public member of B would be a private or protected member of N, or — R occurs in a member or friend of a class P derived from N, and an invented public member of B would be a private or protected member of P, or — there exists a class S such that B is a base class of S accessible at R and S is a base class of N accessible at R. [ Example: § 11.2 234

c ISO/IEC

N3337

class B { public: int m; }; class S: private B { friend class N; }; class N: private S { void f() { B* p = this; // // // // } };
5

OK because class S satisﬁes the fourth condition above: B is a base class of N accessible in f() because B is an accessible base class of S and S is an accessible base class of N.

— end example ] If a base class is accessible, one can implicitly convert a pointer to a derived class to a pointer to that base class (4.10, 4.11). [ Note: It follows that members and friends of a class X can implicitly convert an X* to a pointer to a private or protected immediate base class of X. — end note ] The access to a member is aﬀected by the class in which the member is named. This naming class is the class in which the member name was looked up and found. [ Note: This class can be explicit, e.g., when a qualiﬁed-id is used, or implicit, e.g., when a class member access operator (5.2.5) is used (including cases where an implicit “this->” is added). If both a class member access operator and a qualiﬁed-id are used to name the member (as in p->T::m), the class naming the member is the class denoted by the nested-name-speciﬁer of the qualiﬁed-id (that is, T). — end note ] A member m is accessible at the point R when named in class N if — m as a member of N is public, or — m as a member of N is private, and R occurs in a member or friend of class N, or — m as a member of N is protected, and R occurs in a member or friend of class N, or in a member or friend of a class P derived from N, where m as a member of P is public, private, or protected, or — there exists a base class B of N that is accessible at R, and m is accessible at R when named in class B. [ Example: class B; class A { private: int i; friend void f(B*); }; class B : public A { }; void f(B* p) { p->i = 1; // OK: B* can be implicitly converted to A*, // and f has access to i in A }

— end example ]
6

If a class member access operator, including an implicit “this->,” is used to access a non-static data member or non-static member function, the reference is ill-formed if the left operand (considered as a pointer in the “.” operator case) cannot be implicitly converted to a pointer to the naming class of the right operand. § 11.2 235

c ISO/IEC

N3337

[ Note: This requirement is in addition to the requirement that the member be accessible as named. — end note ]

11.3
1

Friends

[class.friend]

A friend of a class is a function or class that is given permission to use the private and protected member names from the class. A class speciﬁes its friends, if any, by way of friend declarations. Such declarations give special access rights to the friends, but they do not make the nominated friends members of the befriending class. [ Example: the following example illustrates the diﬀerences between members and friends: class X { int a; friend void friend_set(X*, int); public: void member_set(int); }; void friend_set(X* p, int i) { p->a = i; } void X::member_set(int i) { a = i; } void f() { X obj; friend_set(&obj,10); obj.member_set(10); }

2

— end example ] Declaring a class to be a friend implies that the names of private and protected members from the class granting friendship can be accessed in the base-speciﬁers and member declarations of the befriended class. [ Example: class A { class B { }; friend class X; }; struct X : A::B { A::B mx; class Y { A::B my; }; }; // OK: A::B accessible to friend // OK: A::B accessible to member of friend // OK: A::B accessible to nested member of friend

— end example ] [ Example: class X { enum { a=100 }; friend class Y; }; class Y { int v[X::a]; }; class Z { int v[X::a]; };

// OK, Y is a friend of X

// error: X::a is private

§ 11.3

236

c ISO/IEC

N3337

— end example ] A class shall not be deﬁned in a friend declaration. [ Example: class A { friend class B { }; // error: cannot deﬁne class in friend declaration };
3

— end example ] A friend declaration that does not declare a function shall have one of the following forms: friend elaborated-type-speciﬁer ; friend simple-type-speciﬁer ; friend typename-speciﬁer ;

[ Note: A friend declaration may be the declaration in a template-declaration (Clause 14, 14.5.4). — end note ] If the type speciﬁer in a friend declaration designates a (possibly cv-qualiﬁed) class type, that class is declared as a friend; otherwise, the friend declaration is ignored. [ Example: class C; typedef C Ct; class X1 { friend C; }; class X2 friend friend friend }; { Ct; D; class D;

// OK: class C is a friend

// OK: class C is a friend // error: no type-name D in scope // OK: elaborated-type-speciﬁer declares new class

template class R { friend T; }; R rc; R Ri;
4

// class C is a friend of R // OK: "friend int;" is ignored

5

— end example ] A function ﬁrst declared in a friend declaration has external linkage (3.5). Otherwise, the function retains its previous linkage (7.1.1). When a friend declaration refers to an overloaded name or operator, only the function speciﬁed by the parameter types becomes a friend. A member function of a class X can be a friend of a class Y. [ Example: class Y { friend char* X::foo(int); friend X::X(char); friend X::~X(); };

// constructors can be friends // destructors can be friends

6

— end example ] A function can be deﬁned in a friend declaration of a class if and only if the class is a non-local class (9.8), the function name is unqualiﬁed, and the function has namespace scope. [ Example: class M { friend void f() { } }; // deﬁnition of global f, a friend of M, // not the deﬁnition of a member function

— end example ] § 11.3 237

c ISO/IEC

N3337

7

8 9

10

Such a function is implicitly inline. A friend function deﬁned in a class is in the (lexical) scope of the class in which it is deﬁned. A friend function deﬁned outside the class is not (3.4.1). No storage-class-speciﬁer shall appear in the decl-speciﬁer-seq of a friend declaration. A name nominated by a friend declaration shall be accessible in the scope of the class containing the friend declaration. The meaning of the friend declaration is the same whether the friend declaration appears in the private, protected or public (9.2) portion of the class member-speciﬁcation. Friendship is neither inherited nor transitive. [ Example: class A { friend class B; int a; }; class B { friend class C; }; class C { void f(A* p) { p->a++; } }; class D : public B void f(A* p) { p->a++; } }; { // error: D is not a friend of A // despite being derived from a friend

// error: C is not a friend of A // despite being a friend of a friend

11

— end example ] If a friend declaration appears in a local class (9.8) and the name speciﬁed is an unqualiﬁed name, a prior declaration is looked up without considering scopes that are outside the innermost enclosing non-class scope. For a friend function declaration, if there is no prior declaration, the program is ill-formed. For a friend class declaration, if there is no prior declaration, the class that is speciﬁed belongs to the innermost enclosing non-class scope, but if it is subsequently referenced, its name is not found by name lookup until a matching declaration is provided in the innermost enclosing nonclass scope. [ Example: class X; void a(); void f() { class Y; extern void b(); class A { friend class X; friend class Y; friend class Z; friend void a(); friend void b(); friend void c(); }; X *px; Z *pz; }

// // // // // //

OK, but X is a local class, not ::X OK OK, introduces local class Z error, ::a is not considered OK error

// OK, but ::X is found // error, no Z is found

§ 11.3

238

c ISO/IEC

N3337

— end example ]

11.4
1

Protected member access

[class.protected]

An additional access check beyond those described earlier in Clause 11 is applied when a non-static data member or non-static member function is a protected member of its naming class (11.2)115 As described earlier, access to a protected member is granted because the reference occurs in a friend or member of some class C. If the access is to form a pointer to member (5.3.1), the nested-name-speciﬁer shall denote C or a class derived from C. All other accesses involve a (possibly implicit) object expression (5.2.5). In this case, the class of the object expression shall be C or a class derived from C. [ Example: class B { protected: int i; static int j; }; class D1 : public B { }; class D2 : public B { friend void fr(B*,D1*,D2*); void mem(B*,D1*); }; void fr(B* pb, D1* p1, D2* p2) { pb->i = 1; // p1->i = 2; // p2->i = 3; // p2->B::i = 4; // // int B::* pmi_B = &B::i; // int B::* pmi_B2 = &D2::i; // B::j = 5; // D2::j = 6; // } void D2::mem(B* pb, D1* p1) { pb->i = 1; p1->i = 2; i = 3; B::i = 4; int B::* pmi_B = &B::i; int B::* pmi_B2 = &D2::i; j = 5; B::j = 6; } void g(B* pb->i = p1->i = p2->i = }

ill-formed ill-formed OK (access through a D2) OK (access through a D2, even though naming class is B) ill-formed OK (type of &D2::i is int B::*) OK (because refers to static member) OK (because refers to static member)

// // // // // // // //

ill-formed ill-formed OK (access through this) OK (access through this, qualiﬁcation ignored) ill-formed OK OK (because j refers to static member) OK (because B::j refers to static member)

pb, D1* p1, D2* p2) { 1; // ill-formed 2; // ill-formed 3; // ill-formed

115) This additional check does not apply to other members, e.g., static data members or enumerator member constants.

§ 11.4

239

c ISO/IEC

N3337

— end example ]

11.5
1

Access to virtual functions

[class.access.virt]

The access rules (Clause 11) for a virtual function are determined by its declaration and are not aﬀected by the rules for a function that later overrides it. [ Example: class B { public: virtual int f(); }; class D : public B { private: int f(); }; void f() { D d; B* pb = &d; D* pd = &d; pb->f(); pd->f(); } // OK: B::f() is public, // D::f() is invoked // error: D::f() is private

2

— end example ] Access is checked at the call point using the type of the expression used to denote the object for which the member function is called (B* in the example above). The access of the member function in the class in which it was deﬁned (D in the example above) is in general not known.

11.6
1

Multiple access

[class.paths]

If a name can be reached by several paths through a multiple inheritance graph, the access is that of the path that gives most access. [ Example: class W { public: void f(); }; class A : private virtual W { }; class B : public virtual W { }; class C : public A, public B { void f() { W::f(); } // OK };

2

Since W::f() is available to C::f() along the public path through B, access is allowed. — end example ]

11.7
1

Nested classes

[class.access.nest]

A nested class is a member and as such has the same access rights as any other member. The members of an enclosing class have no special access to members of a nested class; the usual access rules (Clause 11) shall be obeyed. [ Example: class E { int x; class B { }; class I { B b; int y; void f(E* p, int i) { p->x = i;

// OK: E::I can access E::B

// OK: E::I can access E::x

§ 11.7

240

c ISO/IEC

N3337

} }; int g(I* p) { return p->y; } };

// error: I::y is private

— end example ]

§ 11.7

241

c ISO/IEC

N3337

12
1

Special member functions

[special]

2

The default constructor (12.1), copy constructor and copy assignment operator (12.8), move constructor and move assignment operator (12.8), and destructor (12.4) are special member functions. [ Note: The implementation will implicitly declare these member functions for some class types when the program does not explicitly declare them. The implementation will implicitly deﬁne them if they are odr-used (3.2). See 12.1, 12.4 and 12.8. — end note ] Programs shall not deﬁne implicitly-declared special member functions. Programs may explicitly refer to implicitly-declared special member functions. [ Example: a program may explicitly call, take the address of or form a pointer to member to an implicitly-declared special member function. struct A { }; struct B : A { B& operator=(const B &); }; B& B::operator=(const B& s) { this->A::operator=(s); return *this; } // implicitly declared A::operator=

// well formed

3

4

— end example ] [ Note: The special member functions aﬀect the way objects of class type are created, copied, moved, and destroyed, and how values can be converted to values of other types. Often such special member functions are called implicitly. — end note ] Special member functions obey the usual access rules (Clause 11). [ Example: declaring a constructor protected ensures that only derived classes and friends can create objects using it. — end example ]

12.1
1

Constructors

[class.ctor]

Constructors do not have names. A special declarator syntax is used to declare or deﬁne the constructor. The syntax uses: — an optional decl-speciﬁer-seq in which each decl-speciﬁer is either a function-speciﬁer or constexpr, — the constructor’s class name, and — a parameter list in that order. In such a declaration, optional parentheses around the constructor class name are ignored. [ Example: struct S { S(); }; S::S() { } // declares the constructor

// deﬁnes the constructor

2

3

— end example ] A constructor is used to initialize objects of its class type. Because constructors do not have names, they are never found during name lookup; however an explicit type conversion using the functional notation (5.2.3) will cause a constructor to be called to initialize an object. [ Note: For initialization of objects of class type see 12.6. — end note ] A typedef-name shall not be used as the class-name in the declarator-id for a constructor declaration.

§ 12.1

242

c ISO/IEC

N3337

4

5

A constructor shall not be virtual (10.3) or static (9.4). A constructor can be invoked for a const, volatile or const volatile object. A constructor shall not be declared const, volatile, or const volatile (9.3.2). const and volatile semantics (7.1.6.1) are not applied on an object under construction. They come into eﬀect when the constructor for the most derived object (1.8) ends. A constructor shall not be declared with a ref-qualiﬁer. A default constructor for a class X is a constructor of class X that can be called without an argument. If there is no user-declared constructor for class X, a constructor having no parameters is implicitly declared as defaulted (8.4). An implicitly-declared default constructor is an inline public member of its class. A defaulted default constructor for class X is deﬁned as deleted if: — X is a union-like class that has a variant member with a non-trivial default constructor, — any non-static data member with no brace-or-equal-initializer is of reference type, — any non-variant non-static data member of const-qualiﬁed type (or array thereof) with no brace-orequal-initializer does not have a user-provided default constructor, — X is a union and all of its variant members are of const-qualiﬁed type (or array thereof), — X is a non-union class and all members of any anonymous union member are of const-qualiﬁed type (or array thereof), — any direct or virtual base class, or non-static data member with no brace-or-equal-initializer, has class type M (or array thereof) and either M has no default constructor or overload resolution (13.3) as applied to M’s default constructor results in an ambiguity or in a function that is deleted or inaccessible from the defaulted default constructor, or — any direct or virtual base class or non-static data member has a type with a destructor that is deleted or inaccessible from the defaulted default constructor. A default constructor is trivial if it is not user-provided and if: — its class has no virtual functions (10.3) and no virtual base classes (10.1), and — no non-static data member of its class has a brace-or-equal-initializer, and — all the direct base classes of its class have trivial default constructors, and — for all the non-static data members of its class that are of class type (or array thereof), each such class has a trivial default constructor.

6

7

Otherwise, the default constructor is non-trivial. A default constructor that is defaulted and not deﬁned as deleted is implicitly deﬁned when it is odrused (3.2) to create an object of its class type (1.8) or when it is explicitly defaulted after its ﬁrst declaration. The implicitly-deﬁned default constructor performs the set of initializations of the class that would be performed by a user-written default constructor for that class with no ctor-initializer (12.6.2) and an empty compound-statement. If that user-written default constructor would be ill-formed, the program is ill-formed. If that user-written default constructor would satisfy the requirements of a constexpr constructor (7.1.5), the implicitly-deﬁned default constructor is constexpr. Before the defaulted default constructor for a class is implicitly deﬁned, all the non-user-provided default constructors for its base classes and its nonstatic data members shall have been implicitly deﬁned. [ Note: An implicitly-declared default constructor has an exception-speciﬁcation (15.4). An explicitly-defaulted deﬁnition might have an implicit exceptionspeciﬁcation, see 8.4. — end note ] Default constructors are called implicitly to create class objects of static, thread, or automatic storage duration (3.7.1, 3.7.2, 3.7.3) deﬁned without an initializer (8.5), are called to create class objects of dynamic § 12.1 243

c ISO/IEC

N3337

8

9

10

11

storage duration (3.7.4) created by a new-expression in which the new-initializer is omitted (5.3.4), or are called when the explicit type conversion syntax (5.2.3) is used. A program is ill-formed if the default constructor for an object is implicitly used and the constructor is not accessible (Clause 11). [ Note: 12.6.2 describes the order in which constructors for base classes and non-static data members are called and describes how arguments can be speciﬁed for the calls to these constructors. — end note ] A copy constructor (12.8) is used to copy objects of class type. A move constructor (12.8) is used to move the contents of objects of class type. No return type (not even void) shall be speciﬁed for a constructor. A return statement in the body of a constructor shall not specify a return value. The address of a constructor shall not be taken. A functional notation type conversion (5.2.3) can be used to create new objects of its type. [ Note: The syntax looks like an explicit call of the constructor. — end note ] [ Example: complex zz = complex(1,2.3); cprint( complex(7.8,1.2) );

12

13

14

— end example ] An object created in this way is unnamed. [ Note: 12.2 describes the lifetime of temporary objects. — end note ] [ Note: Explicit constructor calls do not yield lvalues, see 3.10. — end note ] [ Note: some language constructs have special semantics when used during construction; see 12.6.2 and 12.7. — end note ] During the construction of a const object, if the value of the object or any of its subobjects is accessed through a glvalue that is not obtained, directly or indirectly, from the constructor’s this pointer, the value of the object or subobject thus obtained is unspeciﬁed. [ Example: struct C; void no_opt(C*); struct C { int c; C() : c(0) { no_opt(this); } }; const C cobj; void no_opt(C* cptr) { int i = cobj.c * 100; cptr->c = 1; cout ~B_alias(); B_ptr->B_alias::~B(); B_ptr->B_alias::~B_alias(); }

// // // // //

calls calls calls calls calls

B’s D’s D’s B’s B’s

destructor destructor destructor destructor destructor

14

— end example ] [ Note: An explicit destructor call must always be written using a member access operator (5.2.5) or a qualiﬁed-id (5.1); in particular, the unary-expression ˜X() in a member function is not an explicit destructor call (5.3.1). — end note ] [ Note: explicit calls of destructors are rarely needed. One use of such calls is for objects placed at speciﬁc addresses using a new-expression with the placement option. Such use of explicit placement and destruction of objects can be necessary to cope with dedicated hardware resources and for writing memory management facilities. For example, void* operator new(std::size_t, void* p) { return p; } struct X { X(int); ~X(); }; void f(X* p); void g() { // rare, specialized use: char* buf = new char[sizeof(X)]; X* p = new(buf) X(222); // use buf[] and initialize f(p); p->X::~X(); // cleanup }

15

16

— end note ] Once a destructor is invoked for an object, the object no longer exists; the behavior is undeﬁned if the destructor is invoked for an object whose lifetime has ended (3.8). [ Example: if the destructor for an automatic object is explicitly invoked, and the block is subsequently left in a manner that would ordinarily invoke implicit destruction of the object, the behavior is undeﬁned. — end example ] [ Note: the notation for explicit call of a destructor can be used for any scalar type name (5.2.4). Allowing this makes it possible to write code without having to know if a destructor exists for a given type. For example, § 12.4 251

c ISO/IEC

N3337

typedef int I; I* p; p->I::~I();

— end note ]

12.5
1 2

Free store

[class.free]

Any allocation function for a class T is a static member (even if not explicitly declared static). [ Example: class Arena; struct B { void* operator new(std::size_t, Arena*); }; struct D1 : B { }; Arena* ap; void foo(int i) { new (ap) D1; new D1[i]; new D1; }

// calls B::operator new(std::size_t, Arena*) // calls ::operator new[](std::size_t) // ill-formed: ::operator new(std::size_t) hidden

3

4

5

6

— end example ] When an object is deleted with a delete-expression (5.3.5), a deallocation function (operator delete() for non-array objects or operator delete[]() for arrays) is (implicitly) called to reclaim the storage occupied by the object (3.7.4.2). If a delete-expression begins with a unary :: operator, the deallocation function’s name is looked up in global scope. Otherwise, if the delete-expression is used to deallocate a class object whose static type has a virtual destructor, the deallocation function is the one selected at the point of deﬁnition of the dynamic type’s virtual destructor (12.4).117 Otherwise, if the delete-expression is used to deallocate an object of class T or array thereof, the static and dynamic types of the object shall be identical and the deallocation function’s name is looked up in the scope of T. If this lookup fails to ﬁnd the name, the name is looked up in the global scope. If the result of the lookup is ambiguous or inaccessible, or if the lookup selects a placement deallocation function, the program is ill-formed. When a delete-expression is executed, the selected deallocation function shall be called with the address of the block of storage to be reclaimed as its ﬁrst argument and (if the two-parameter style is used) the size of the block as its second argument.118 Any deallocation function for a class X is a static member (even if not explicitly declared static). [ Example: class X { void operator delete(void*); void operator delete[](void*, std::size_t); }; class Y { void operator delete(void*, std::size_t); void operator delete[](void*); };
117) A similar provision is not needed for the array version of operator delete because 5.3.5 requires that in this situation, the static type of the object to be deleted be the same as its dynamic type. 118) If the static type of the object to be deleted is diﬀerent from the dynamic type and the destructor is not virtual the size might be incorrect, but that case is already undeﬁned; see 5.3.5.

§ 12.5

252

c ISO/IEC

N3337

7

— end example ] Since member allocation and deallocation functions are static they cannot be virtual. [ Note: however, when the cast-expression of a delete-expression refers to an object of class type, because the deallocation function actually called is looked up in the scope of the class that is the dynamic type of the object, if the destructor is virtual, the eﬀect is the same. For example, struct B { virtual ~B(); void operator delete(void*, std::size_t); }; struct D : B { void operator delete(void*); }; void f() { B* bp = new D; delete bp; }

//1: uses D::operator delete(void*)

Here, storage for the non-array object of class D is deallocated by D::operator delete(), due to the virtual destructor. — end note ] [ Note: Virtual destructors have no eﬀect on the deallocation function actually called when the cast-expression of a delete-expression refers to an array of objects of class type. For example, struct B { virtual ~B(); void operator delete[](void*, std::size_t); }; struct D : B { void operator delete[](void*, std::size_t); }; void f(int i) { D* dp = new D[i]; delete [] dp; // uses D::operator delete[](void*, std::size_t) B* bp = new D[i]; delete[] bp; // undeﬁned behavior }
8

9

— end note ] Access to the deallocation function is checked statically. Hence, even though a diﬀerent one might actually be executed, the statically visible deallocation function is required to be accessible. [ Example: for the call on line //1 above, if B::operator delete() had been private, the delete expression would have been ill-formed. — end example ] [ Note: If a deallocation function has no explicit exception-speciﬁcation, it is treated as if it were speciﬁed with noexcept(true) (15.4). — end note ]

12.6
1

Initialization

[class.init]

2 3

When no initializer is speciﬁed for an object of (possibly cv-qualiﬁed) class type (or array thereof), or the initializer has the form (), the object is initialized as speciﬁed in 8.5. An object of class type (or array thereof) can be explicitly initialized; see 12.6.1 and 12.6.2. When an array of class objects is initialized (either explicitly or implicitly) and the elements are initialized by constructor, the constructor shall be called for each element of the array, following the subscript order;

§ 12.6

253

c ISO/IEC

N3337

see 8.3.4. [ Note: Destructors for the array elements are called in reverse order of their construction. — end note ]

12.6.1
1

Explicit initialization

[class.expl.init]

An object of class type can be initialized with a parenthesized expression-list, where the expression-list is construed as an argument list for a constructor that is called to initialize the object. Alternatively, a single assignment-expression can be speciﬁed as an initializer using the = form of initialization. Either direct-initialization semantics or copy-initialization semantics apply; see 8.5. [ Example: struct complex { complex(); complex(double); complex(double,double); }; complex sqrt(complex,complex); complex a(1); complex b = a; complex c = complex(1,2); // // // // // // // // // // // // // // // // initialize by a call of complex(double) initialize by a copy of a construct complex(1,2) using complex(double,double) copy/move it into c call sqrt(complex,complex) and copy/move the result into d initialize by a call of complex() construct complex(3) using complex(double) copy/move it into f construct complex(1, 2) using complex(double, double) and copy/move it into g

complex d = sqrt(b,c); complex e; complex f = 3;

complex g = { 1, 2 };

2

— end example ] [ Note: overloading of the assignment operator (13.5.3) has no eﬀect on initialization. — end note ] An object of class type can also be initialized by a braced-init-list. List-initialization semantics apply; see 8.5 and 8.5.4. [ Example: complex v[6] = { 1, complex(1,2), complex(), 2 };

Here, complex::complex(double) is called for the initialization of v[0] and v[3], complex::complex( double, double) is called for the initialization of v[1], complex::complex() is called for the initialization v[2], v[4], and v[5]. For another example, struct X { int i; float f; complex c; } x = { 99, 88.8, 77.7 };

3

Here, x.i is initialized with 99, x.f is initialized with 88.8, and complex::complex(double) is called for the initialization of x.c. — end example ] [ Note: Braces can be elided in the initializer-list for any aggregate, even if the aggregate has members of a class type with user-deﬁned type conversions; see 8.5.1. — end note ] [ Note: If T is a class type with no default constructor, any declaration of an object of type T (or array thereof) is ill-formed if no initializer is explicitly speciﬁed (see 12.6 and 8.5). — end note ] § 12.6.1 254

c ISO/IEC

N3337

4

[ Note: the order in which objects with static or thread storage duration are initialized is described in 3.6.2 and 6.7. — end note ]

12.6.2
1

Initializing bases and members

[class.base.init]

In the deﬁnition of a constructor for a class, initializers for direct and virtual base subobjects and non-static data members can be speciﬁed by a ctor-initializer, which has the form ctor-initializer: : mem-initializer-list mem-initializer-list: mem-initializer ...opt mem-initializer , mem-initializer-list ...opt mem-initializer: mem-initializer-id ( expression-listopt ) mem-initializer-id braced-init-list mem-initializer-id: class-or-decltype identiﬁer

2

3

In a mem-initializer-id an initial unqualiﬁed identiﬁer is looked up in the scope of the constructor’s class and, if not found in that scope, it is looked up in the scope containing the constructor’s deﬁnition. [ Note: If the constructor’s class contains a member with the same name as a direct or virtual base class of the class, a mem-initializer-id naming the member or base class and composed of a single identiﬁer refers to the class member. A mem-initializer-id for the hidden base class may be speciﬁed using a qualiﬁed name. — end note ] Unless the mem-initializer-id names the constructor’s class, a non-static data member of the constructor’s class, or a direct or virtual base of that class, the mem-initializer is ill-formed. A mem-initializer-list can initialize a base class using any class-or-decltype that denotes that base class type. [ Example: struct A { A(); }; typedef A global_A; struct B { }; struct C: public A, public B { C(); }; C::C(): global_A() { } // mem-initializer for base A

4

— end example ] If a mem-initializer-id is ambiguous because it designates both a direct non-virtual base class and an inherited virtual base class, the mem-initializer is ill-formed. [ Example: struct A { A(); }; struct B: public virtual A { }; struct C: public A, public B { C(); }; C::C(): A() { } // ill-formed: which A?

5

6

— end example ] A ctor-initializer may initialize a variant member of the constructor’s class. If a ctor-initializer speciﬁes more than one mem-initializer for the same member or for the same base class, the ctor-initializer is ill-formed. A mem-initializer-list can delegate to another constructor of the constructor’s class using any class-ordecltype that denotes the constructor’s class itself. If a mem-initializer-id designates the constructor’s class, it shall be the only mem-initializer; the constructor is a delegating constructor, and the constructor selected by the mem-initializer is the target constructor. The principal constructor is the ﬁrst constructor invoked in the construction of an object (that is, not a target constructor for that object’s construction). The target constructor is selected by overload resolution. Once the target constructor returns, the body of the delegating constructor is executed. If a constructor delegates to itself directly or indirectly, the program is ill-formed; no diagnostic is required. [ Example: struct C {

§ 12.6.2

255

c ISO/IEC

N3337

C( int ) { } C(): C(42) { } C( char c ) : C(42.0) { } C( double d ) : C(’a’) { } };
7

// // // //

#1: #2: #3: #4:

non-delegating constructor delegates to #1 ill-formed due to recursion with #4 ill-formed due to recursion with #3

— end example ] The expression-list or braced-init-list in a mem-initializer is used to initialize the designated subobject (or, in the case of a delegating constructor, the complete class object) according to the initialization rules of 8.5 for direct-initialization. [ Example: struct B1 { B1(int); /∗ ... ∗/ }; struct B2 { B2(int); /∗ ... ∗/ }; struct D : B1, B2 { D(int); B1 b; const int c; }; D::D(int a) : B2(a+1), B1(a+2), c(a+3), b(a+4) { /∗ ... ∗/ } D d(10);

8

— end example ] The initialization performed by each mem-initializer constitutes a full-expression. Any expression in a mem-initializer is evaluated as part of the full-expression that performs the initialization. A mem-initializer where the mem-initializer-id denotes a virtual base class is ignored during execution of a constructor of any class that is not the most derived class. In a non-delegating constructor, if a given non-static data member or base class is not designated by a mem-initializer-id (including the case where there is no mem-initializer-list because the constructor has no ctor-initializer) and the entity is not a virtual base class of an abstract class (10.4), then — if the entity is a non-static data member that has a brace-or-equal-initializer, the entity is initialized as speciﬁed in 8.5; — otherwise, if the entity is a variant member (9.5), no initialization is performed; — otherwise, the entity is default-initialized (8.5). [ Note: An abstract class (10.4) is never a most derived class, thus its constructors never initialize virtual base classes, therefore the corresponding mem-initializers may be omitted. — end note ] An attempt to initialize more than one non-static data member of a union renders the program ill-formed. After the call to a constructor for class X has completed, if a member of X is neither initialized nor given a value during execution of the compound-statement of the body of the constructor, the member has indeterminate value. [ Example: struct A { A(); }; struct B { B(int); }; struct C { C() { } A a;

// initializes members as follows: // OK: calls A::A()

§ 12.6.2

256

c ISO/IEC

N3337

const B b; int i; int j = 5; };
9

// error: B has no default constructor // OK: i has indeterminate value // OK: j has the value 5

— end example ] If a given non-static data member has both a brace-or-equal-initializer and a mem-initializer, the initialization speciﬁed by the mem-initializer is performed, and the non-static data member’s brace-or-equal-initializer is ignored. [ Example: Given struct A { int i = /∗ some integer expression with side eﬀects ∗/ ; A(int arg) : i(arg) { } // ... };

10

the A(int) constructor will simply initialize i to the value of arg, and the side eﬀects in i’s brace-orequal-initializer will not take place. — end example ] In a non-delegating constructor, initialization proceeds in the following order: — First, and only for the constructor of the most derived class (1.8), virtual base classes are initialized in the order they appear on a depth-ﬁrst left-to-right traversal of the directed acyclic graph of base classes, where “left-to-right” is the order of appearance of the base classes in the derived class base-speciﬁer-list. — Then, direct base classes are initialized in declaration order as they appear in the base-speciﬁer-list (regardless of the order of the mem-initializers). — Then, non-static data members are initialized in the order they were declared in the class deﬁnition (again regardless of the order of the mem-initializers). — Finally, the compound-statement of the constructor body is executed. [ Note: The declaration order is mandated to ensure that base and member subobjects are destroyed in the reverse order of initialization. — end note ] [ Example: struct V { V(); V(int); }; struct A : virtual V { A(); A(int); }; struct B : virtual V { B(); B(int); }; struct C : A, B, virtual V { C(); C(int); }; A::A(int i) : V(i) { /∗ ... ∗/ }

11

§ 12.6.2

257

c ISO/IEC

N3337

B::B(int i) { /∗ ... ∗/ } C::C(int i) { /∗ ... ∗/ } V A B C
12

v(1); a(2); b(3); c(4);

// // // //

use use use use

V(int) V(int) V() V()

— end example ] Names in the expression-list or braced-init-list of a mem-initializer are evaluated in the scope of the constructor for which the mem-initializer is speciﬁed. [ Example: class X { int a; int b; int i; int j; public: const int& r; X(int i): r(a), b(i), i(i), j(this->i) { } };

13

initializes X::r to refer to X::a, initializes X::b with the value of the constructor parameter i, initializes X::i with the value of the constructor parameter i, and initializes X::j with the value of X::i; this takes place each time an object of class X is created. — end example ] [ Note: Because the mem-initializer are evaluated in the scope of the constructor, the this pointer can be used in the expression-list of a meminitializer to refer to the object being initialized. — end note ] Member functions (including virtual member functions, 10.3) can be called for an object under construction. Similarly, an object under construction can be the operand of the typeid operator (5.2.8) or of a dynamic_cast (5.2.7). However, if these operations are performed in a ctor-initializer (or in a function called directly or indirectly from a ctor-initializer) before all the mem-initializers for base classes have completed, the result of the operation is undeﬁned. [ Example: class A { public: A(int); }; class B : public A { int j; public: int f(); B() : A(f()), // undeﬁned: calls member function // but base A not yet initialized j(f()) { } // well-deﬁned: bases are all initialized }; class C { public: C(int); }; class D : public B, C { int i; public: D() : C(f()), // undeﬁned: calls member function

§ 12.6.2

258

c ISO/IEC

N3337

i(f()) { } };
14

// but base C not yet initialized // well-deﬁned: bases are all initialized

15

— end example ] [ Note: 12.7 describes the result of virtual function calls, typeid and dynamic_casts during construction for the well-deﬁned cases; that is, describes the polymorphic behavior of an object under construction. — end note ] A mem-initializer followed by an ellipsis is a pack expansion (14.5.3) that initializes the base classes speciﬁed by a pack expansion in the base-speciﬁer-list for the class. [ Example: template class X : public Mixins... { public: X(const Mixins&... mixins) : Mixins(mixins)... { } };

— end example ]

12.7
1

Construction and destruction

[class.cdtor]

For an object with a non-trivial constructor, referring to any non-static member or base class of the object before the constructor begins execution results in undeﬁned behavior. For an object with a non-trivial destructor, referring to any non-static member or base class of the object after the destructor ﬁnishes execution results in undeﬁned behavior. [ Example: struct struct struct struct X Y A B { : { : int i; }; X { Y(); }; int a; }; public A { int j; Y y; }; // non-trivial // non-trivial

extern B bobj; B* pb = &bobj; int* p1 = &bobj.a; int* p2 = &bobj.y.i; A* pa = &bobj; B bobj; extern X xobj; int* p3 = &xobj.i; X xobj;
2

// OK // undeﬁned, refers to base class member // undeﬁned, refers to member’s member // undeﬁned, upcast to a base class type // deﬁnition of bobj

//OK, X is a trivial class

For another example, struct W { int j; }; struct X : public virtual W { }; struct Y { int *p; X x; Y() : p(&x.j) { // undeﬁned, x is not yet constructed } };

3

— end example ] To explicitly or implicitly convert a pointer (a glvalue) referring to an object of class X to a pointer (reference) to a direct or indirect base class B of X, the construction of X and the construction of all of its direct or indirect bases that directly or indirectly derive from B shall have started and the destruction of these classes § 12.7 259

c ISO/IEC

N3337

shall not have completed, otherwise the conversion results in undeﬁned behavior. To form a pointer to (or access the value of) a direct non-static member of an object obj, the construction of obj shall have started and its destruction shall not have completed, otherwise the computation of the pointer value (or accessing the member value) results in undeﬁned behavior. [ Example: struct struct struct struct struct A B C D X { : : : { }; virtual A { }; B { }; virtual A { D(A*); }; X(A*); };

struct E : C, D, X { E() : D(this), // // // // // // // X(this) { // // } };
4

undeﬁned: upcast from E* to A* might use path E* → D* → A* but D is not constructed D((C*)this), // deﬁned: E* → C* deﬁned because E() has started and C* → A* deﬁned because C fully constructed deﬁned: upon construction of X, C/B/D/A sublattice is fully constructed

— end example ] Member functions, including virtual functions (10.3), can be called during construction or destruction (12.6.2). When a virtual function is called directly or indirectly from a constructor or from a destructor, including during the construction or destruction of the class’s non-static data members, and the object to which the call applies is the object (call it x) under construction or destruction, the function called is the ﬁnal overrider in the constructor’s or destructor’s class and not one overriding it in a more-derived class. If the virtual function call uses an explicit class member access (5.2.5) and the object expression refers to the complete object of x or one of that object’s base class subobjects but not x or one of its base class subobjects, the behavior is undeﬁned. [ Example: struct V { virtual void f(); virtual void g(); }; struct A : virtual V { virtual void f(); }; struct B : virtual V { virtual void g(); B(V*, A*); }; struct D : A, B { virtual void f(); virtual void g(); D() : B((A*)this, this) { } }; B::B(V* v, A* a) { f();

// calls V::f, not A::f

§ 12.7

260

c ISO/IEC

N3337

g(); v->g(); a->f(); }
5

// calls B::g, not D::g // v is base of B, the call is well-deﬁned, calls B::g // undeﬁned behavior, a’s type not a base of B

6

— end example ] The typeid operator (5.2.8) can be used during construction or destruction (12.6.2). When typeid is used in a constructor (including the mem-initializer or brace-or-equal-initializer for a non-static data member) or in a destructor, or used in a function called (directly or indirectly) from a constructor or destructor, if the operand of typeid refers to the object under construction or destruction, typeid yields the std::type_info object representing the constructor or destructor’s class. If the operand of typeid refers to the object under construction or destruction and the static type of the operand is neither the constructor or destructor’s class nor one of its bases, the result of typeid is undeﬁned. dynamic_casts (5.2.7) can be used during construction or destruction (12.6.2). When a dynamic_cast is used in a constructor (including the mem-initializer or brace-or-equal-initializer for a non-static data member) or in a destructor, or used in a function called (directly or indirectly) from a constructor or destructor, if the operand of the dynamic_cast refers to the object under construction or destruction, this object is considered to be a most derived object that has the type of the constructor or destructor’s class. If the operand of the dynamic_cast refers to the object under construction or destruction and the static type of the operand is not a pointer to or object of the constructor or destructor’s own class or one of its bases, the dynamic_cast results in undeﬁned behavior. [ Example: struct V { virtual void f(); }; struct A : virtual V { }; struct B : virtual V { B(V*, A*); }; struct D : A, B { D() : B((A*)this, this) { } }; B::B(V* v, A* a) { typeid(*this); typeid(*v); typeid(*a); dynamic_cast(v); dynamic_cast(a); }

// // // // // // // //

type_info for B well-deﬁned: *v has type V, a base of B yields type_info for B undeﬁned behavior: type A not a base of B well-deﬁned: v of type V*, V base of B results in B* undeﬁned behavior, a has type A*, A not a base of B

— end example ]

12.8
1

Copying and moving class objects

[class.copy]

A class object can be copied or moved in two ways: by initialization (12.1, 8.5), including for function argument passing (5.2.2) and for function value return (6.6.3); and by assignment (5.17). Conceptually, these two operations are implemented by a copy/move constructor (12.1) and copy/move assignment operator (13.5.3).

§ 12.8

261

c ISO/IEC

N3337

2

A non-template constructor for class X is a copy constructor if its ﬁrst parameter is of type X&, const X&, volatile X& or const volatile X&, and either there are no other parameters or else all other parameters have default arguments (8.3.6). [ Example: X::X(const X&) and X::X(X&,int=1) are copy constructors. struct X { X(int); X(const X&, int = 1); }; X a(1); // calls X(int); X b(a, 0); // calls X(const X&, int); X c = b; // calls X(const X&, int);

3

— end example ] A non-template constructor for class X is a move constructor if its ﬁrst parameter is of type X&&, const X&&, volatile X&&, or const volatile X&&, and either there are no other parameters or else all other parameters have default arguments (8.3.6). [ Example: Y::Y(Y&&) is a move constructor. struct Y { Y(const Y&); Y(Y&&); }; extern Y f(int); Y d(f(1)); Y e = d;

// calls Y(Y&&) // calls Y(const Y&)

4

— end example ] [ Note: All forms of copy/move constructor may be declared for a class. [ Example: struct X { X(const X&); X(X&); X(X&&); X(const X&&); };

// OK // OK, but possibly not sensible

5

— end example ] — end note ] [ Note: If a class X only has a copy constructor with a parameter of type X&, an initializer of type const X or volatile X cannot initialize an object of type (possibly cv-qualiﬁed) X. [ Example: struct X { X(); X(X&); }; const X cx; X x = cx; // default constructor // copy constructor with a nonconst parameter

// error: X::X(X&) cannot copy cx into x

6

— end example ] — end note ] A declaration of a constructor for a class X is ill-formed if its ﬁrst parameter is of type (optionally cv-qualiﬁed) X and either there are no other parameters or else all other parameters have default arguments. A member function template is never instantiated to produce such a constructor signature. [ Example: struct S { template S(T); S(); }; S g;

§ 12.8

262

c ISO/IEC

N3337

void h() { S a(g); }
7

// does not instantiate the member template to produce S::S(S); // uses the implicitly declared copy constructor

— end example ] If the class deﬁnition does not explicitly declare a copy constructor, one is declared implicitly. If the class deﬁnition declares a move constructor or move assignment operator, the implicitly declared copy constructor is deﬁned as deleted; otherwise, it is deﬁned as defaulted (8.4). The latter case is deprecated if the class has a user-declared copy assignment operator or a user-declared destructor. Thus, for the class deﬁnition struct X { X(const X&, int); };

a copy constructor is implicitly-declared. If the user-declared constructor is later deﬁned as
X::X(const X& x, int i =0) { /∗ ... ∗/ }
8

then any use of X’s copy constructor is ill-formed because of the ambiguity; no diagnostic is required. The implicitly-declared copy constructor for a class X will have the form
X::X(const X&)

if — each direct or virtual base class B of X has a copy constructor whose ﬁrst parameter is of type const B& or const volatile B&, and — for all the non-static data members of X that are of a class type M (or array thereof), each such class type has a copy constructor whose ﬁrst parameter is of type const M& or const volatile M&.119 Otherwise, the implicitly-declared copy constructor will have the form
X::X(X&)
9

If the deﬁnition of a class X does not explicitly declare a move constructor, one will be implicitly declared as defaulted if and only if — X does not have a user-declared copy constructor, — X does not have a user-declared copy assignment operator, — X does not have a user-declared move assignment operator, — X does not have a user-declared destructor, and — the move constructor would not be implicitly deﬁned as deleted. [ Note: When the move constructor is not implicitly declared or explicitly supplied, expressions that otherwise would have invoked the move constructor may instead invoke a copy constructor. — end note ] The implicitly-declared move constructor for class X will have the form
X::X(X&&)

10

11

An implicitly-declared copy/move constructor is an inline public member of its class. A defaulted copy/ move constructor for a class X is deﬁned as deleted (8.4.3) if X has:
119) This implies that the reference parameter of the implicitly-declared copy constructor cannot bind to a volatile lvalue; see C.1.9.

§ 12.8

263

c ISO/IEC

N3337

— a variant member with a non-trivial corresponding constructor and X is a union-like class, — a non-static data member of class type M (or array thereof) that cannot be copied/moved because overload resolution (13.3), as applied to M’s corresponding constructor, results in an ambiguity or a function that is deleted or inaccessible from the defaulted constructor, — a direct or virtual base class B that cannot be copied/moved because overload resolution (13.3), as applied to B’s corresponding constructor, results in an ambiguity or a function that is deleted or inaccessible from the defaulted constructor, — any direct or virtual base class or non-static data member of a type with a destructor that is deleted or inaccessible from the defaulted constructor, — for the copy constructor, a non-static data member of rvalue reference type, or — for the move constructor, a non-static data member or direct or virtual base class with a type that does not have a move constructor and is not trivially copyable.
12

A copy/move constructor for class X is trivial if it is not user-provided and if — class X has no virtual functions (10.3) and no virtual base classes (10.1), and — the constructor selected to copy/move each direct base class subobject is trivial, and — for each non-static data member of X that is of class type (or array thereof), the constructor selected to copy/move that member is trivial; otherwise the copy/move constructor is non-trivial. A copy/move constructor that is defaulted and not deﬁned as deleted is implicitly deﬁned if it is odr-used (3.2) to initialize an object of its class type from a copy of an object of its class type or of a class type derived from its class type120 or when it is explicitly defaulted after its ﬁrst declaration. [ Note: The copy/move constructor is implicitly deﬁned even if the implementation elided its odr-use (3.2, 12.2). — end note ] If the implicitly-deﬁned constructor would satisfy the requirements of a constexpr constructor (7.1.5), the implicitly-deﬁned constructor is constexpr. Before the defaulted copy/move constructor for a class is implicitly deﬁned, all non-user-provided copy/move constructors for its direct and virtual base classes and its non-static data members shall have been implicitly deﬁned. [ Note: An implicitly-declared copy/move constructor has an exception-speciﬁcation (15.4). — end note ] The implicitly-deﬁned copy/move constructor for a non-union class X performs a memberwise copy/move of its bases and members. [ Note: brace-or-equal-initializers of non-static data members are ignored. See also the example in 12.6.2. — end note ] The order of initialization is the same as the order of initialization of bases and members in a user-deﬁned constructor (see 12.6.2). Let x be either the parameter of the constructor or, for the move constructor, an xvalue referring to the parameter. Each base or non-static data member is copied/moved in the manner appropriate to its type: — if the member is an array, each element is direct-initialized with the corresponding subobject of x; — if a member m has rvalue reference type T&&, it is direct-initialized with static_cast(x.m); — otherwise, the base or member is direct-initialized with the corresponding base or member of x.
120) See 8.5 for more details on direct and copy initialization.

13

14

15

§ 12.8

264

c ISO/IEC

N3337

16 17

Virtual base class subobjects shall be initialized only once by the implicitly-deﬁned copy/move constructor (see 12.6.2). The implicitly-deﬁned copy/move constructor for a union X copies the object representation (3.9) of X. A user-declared copy assignment operator X::operator= is a non-static non-template member function of class X with exactly one parameter of type X, X&, const X&, volatile X& or const volatile X&.121 [ Note: An overloaded assignment operator must be declared to have only one parameter; see 13.5.3. — end note ] [ Note: More than one form of copy assignment operator may be declared for a class. — end note ] [ Note: If a class X only has a copy assignment operator with a parameter of type X&, an expression of type const X cannot be assigned to an object of type X. [ Example: struct X { X(); X& operator=(X&); }; const X cx; X x; void f() { x = cx; // error: X::operator=(X&) cannot assign cx into x }

18

— end example ] — end note ] If the class deﬁnition does not explicitly declare a copy assignment operator, one is declared implicitly. If the class deﬁnition declares a move constructor or move assignment operator, the implicitly declared copy assignment operator is deﬁned as deleted; otherwise, it is deﬁned as defaulted (8.4). The latter case is deprecated if the class has a user-declared copy constructor or a user-declared destructor. The implicitlydeclared copy assignment operator for a class X will have the form
X& X::operator=(const X&)

if — each direct base class B of X has a copy assignment operator whose parameter is of type const B&, const volatile B& or B, and — for all the non-static data members of X that are of a class type M (or array thereof), each such class type has a copy assignment operator whose parameter is of type const M&, const volatile M& or M.122 Otherwise, the implicitly-declared copy assignment operator will have the form
X& X::operator=(X&)
19

20

A user-declared move assignment operator X::operator= is a non-static non-template member function of class X with exactly one parameter of type X&&, const X&&, volatile X&&, or const volatile X&&. [ Note: An overloaded assignment operator must be declared to have only one parameter; see 13.5.3. — end note ] [ Note: More than one form of move assignment operator may be declared for a class. — end note ] If the deﬁnition of a class X does not explicitly declare a move assignment operator, one will be implicitly declared as defaulted if and only if — X does not have a user-declared copy constructor,
121) Because a template assignment operator or an assignment operator taking an rvalue reference parameter is never a copy assignment operator, the presence of such an assignment operator does not suppress the implicit declaration of a copy assignment operator. Such assignment operators participate in overload resolution with other assignment operators, including copy assignment operators, and, if selected, will be used to assign an object. 122) This implies that the reference parameter of the implicitly-declared copy assignment operator cannot bind to a volatile lvalue; see C.1.9.

§ 12.8

265

c ISO/IEC

N3337

— X does not have a user-declared move constructor, — X does not have a user-declared copy assignment operator, — X does not have a user-declared destructor, and — the move assignment operator would not be implicitly deﬁned as deleted. [ Example: The class deﬁnition struct S { int a; S& operator=(const S&) = default; };

will not have a default move assignment operator implicitly declared because the copy assignment operator has been user-declared. The move assignment operator may be explicitly defaulted. struct S { int a; S& operator=(const S&) = default; S& operator=(S&&) = default; };
21

— end example ] The implicitly-declared move assignment operator for a class X will have the form
X& X::operator=(X&&);

22

23

The implicitly-declared copy/move assignment operator for class X has the return type X&; it returns the object for which the assignment operator is invoked, that is, the object assigned to. An implicitly-declared copy/move assignment operator is an inline public member of its class. A defaulted copy/move assignment operator for class X is deﬁned as deleted if X has: — a variant member with a non-trivial corresponding assignment operator and X is a union-like class, or — a non-static data member of const non-class type (or array thereof), or — a non-static data member of reference type, or — a non-static data member of class type M (or array thereof) that cannot be copied/moved because overload resolution (13.3), as applied to M’s corresponding assignment operator, results in an ambiguity or a function that is deleted or inaccessible from the defaulted assignment operator, or — a direct or virtual base class B that cannot be copied/moved because overload resolution (13.3), as applied to B’s corresponding assignment operator, results in an ambiguity or a function that is deleted or inaccessible from the defaulted assignment operator, or — for the move assignment operator, a non-static data member or direct base class with a type that does not have a move assignment operator and is not trivially copyable, or any direct or indirect virtual base class.

24

25

Because a copy/move assignment operator is implicitly declared for a class if not declared by the user, a base class copy/move assignment operator is always hidden by the corresponding assignment operator of a derived class (13.5.3). A using-declaration (7.3.3) that brings in from a base class an assignment operator with a parameter type that could be that of a copy/move assignment operator for the derived class is not considered an explicit declaration of such an operator and does not suppress the implicit declaration of the derived class operator; the operator introduced by the using-declaration is hidden by the implicitly-declared operator in the derived class. A copy/move assignment operator for class X is trivial if it is not user-provided and if § 12.8 266

c ISO/IEC

N3337

— class X has no virtual functions (10.3) and no virtual base classes (10.1), and — the assignment operator selected to copy/move each direct base class subobject is trivial, and — for each non-static data member of X that is of class type (or array thereof), the assignment operator selected to copy/move that member is trivial;
26

27

28

otherwise the copy/move assignment operator is non-trivial. A copy/move assignment operator that is defaulted and not deﬁned as deleted is implicitly deﬁned when it is odr-used (3.2) (e.g., when it is selected by overload resolution to assign to an object of its class type) or when it is explicitly defaulted after its ﬁrst declaration. Before the defaulted copy/move assignment operator for a class is implicitly deﬁned, all non-user-provided copy/move assignment operators for its direct base classes and its non-static data members shall have been implicitly deﬁned. [ Note: An implicitly-declared copy/move assignment operator has an exceptionspeciﬁcation (15.4). — end note ] The implicitly-deﬁned copy/move assignment operator for a non-union class X performs memberwise copy/move assignment of its subobjects. The direct base classes of X are assigned ﬁrst, in the order of their declaration in the base-speciﬁer-list, and then the immediate non-static data members of X are assigned, in the order in which they were declared in the class deﬁnition. Let x be either the parameter of the function or, for the move operator, an xvalue referring to the parameter. Each subobject is assigned in the manner appropriate to its type: — if the subobject is of class type, as if by a call to operator= with the subobject as the object expression and the corresponding subobject of x as a single function argument (as if by explicit qualiﬁcation; that is, ignoring any possible virtual overriding functions in more derived classes); — if the subobject is an array, each element is assigned, in the manner appropriate to the element type; — if the subobject is of scalar type, the built-in assignment operator is used. It is unspeciﬁed whether subobjects representing virtual base classes are assigned more than once by the implicitly-deﬁned copy assignment operator. [ Example: struct struct struct struct V A B C { : : : }; virtual V { }; virtual V { }; B, A { };

29 30

31

It is unspeciﬁed whether the virtual base class subobject V is assigned twice by the implicitly-deﬁned copy assignment operator for C. — end example ] [ Note: This does not apply to move assignment, as a defaulted move assignment operator is deleted if the class has virtual bases. — end note ] The implicitly-deﬁned copy assignment operator for a union X copies the object representation (3.9) of X. A program is ill-formed if the copy/move constructor or the copy/move assignment operator for an object is implicitly odr-used and the special member function is not accessible (Clause 11). [ Note: Copying/moving one object into another using the copy/move constructor or the copy/move assignment operator does not change the layout or size of either object. — end note ] When certain criteria are met, an implementation is allowed to omit the copy/move construction of a class object, even if the copy/move constructor and/or destructor for the object have side eﬀects. In such cases, the implementation treats the source and target of the omitted copy/move operation as simply two diﬀerent ways of referring to the same object, and the destruction of that object occurs at the later of the times when the two objects would have been destroyed without the optimization.123 This elision of copy/move operations, called copy elision, is permitted in the following circumstances (which may be combined to eliminate multiple copies):
123) Because only one object is destroyed instead of two, and one copy/move constructor is not executed, there is still one object destroyed for each one constructed.

§ 12.8

267

c ISO/IEC

N3337

— in a return statement in a function with a class return type, when the expression is the name of a non-volatile automatic object (other than a function or catch-clause parameter) with the same cvunqualiﬁed type as the function return type, the copy/move operation can be omitted by constructing the automatic object directly into the function’s return value — in a throw-expression, when the operand is the name of a non-volatile automatic object (other than a function or catch-clause parameter) whose scope does not extend beyond the end of the innermost enclosing try-block (if there is one), the copy/move operation from the operand to the exception object (15.1) can be omitted by constructing the automatic object directly into the exception object — when a temporary class object that has not been bound to a reference (12.2) would be copied/moved to a class object with the same cv-unqualiﬁed type, the copy/move operation can be omitted by constructing the temporary object directly into the target of the omitted copy/move — when the exception-declaration of an exception handler (Clause 15) declares an object of the same type (except for cv-qualiﬁcation) as the exception object (15.1), the copy/move operation can be omitted by treating the exception-declaration as an alias for the exception object if the meaning of the program will be unchanged except for the execution of constructors and destructors for the object declared by the exception-declaration. [ Example: class Thing { public: Thing(); ~Thing(); Thing(const Thing&); }; Thing f() { Thing t; return t; } Thing t2 = f();

32

Here the criteria for elision can be combined to eliminate two calls to the copy constructor of class Thing: the copying of the local automatic object t into the temporary object for the return value of function f() and the copying of that temporary object into object t2. Eﬀectively, the construction of the local object t can be viewed as directly initializing the global object t2, and that object’s destruction will occur at program exit. Adding a move constructor to Thing has the same eﬀect, but it is the move construction from the temporary object to t2 that is elided. — end example ] When the criteria for elision of a copy operation are met or would be met save for the fact that the source object is a function parameter, and the object to be copied is designated by an lvalue, overload resolution to select the constructor for the copy is ﬁrst performed as if the object were designated by an rvalue. If overload resolution fails, or if the type of the ﬁrst parameter of the selected constructor is not an rvalue reference to the object’s type (possibly cv-qualiﬁed), overload resolution is performed again, considering the object as an lvalue. [ Note: This two-stage overload resolution must be performed regardless of whether copy elision will occur. It determines the constructor to be called if elision is not performed, and the selected constructor must be accessible even if the call is elided. — end note ] [ Example: class Thing { public: Thing();

§ 12.8

268

c ISO/IEC

N3337

~Thing(); Thing(Thing&&); private: Thing(const Thing&); }; Thing f(bool b) { Thing t; if (b) throw t; return t; } Thing t2 = f(false);

// OK: Thing(Thing&&) used (or elided) to throw t // OK: Thing(Thing&&) used (or elided) to return t

// OK: Thing(Thing&&) used (or elided) to construct t2

— end example ]

12.9
1

Inheriting constructors

[class.inhctor]

A using-declaration (7.3.3) that names a constructor implicitly declares a set of inheriting constructors. The candidate set of inherited constructors from the class X named in the using-declaration consists of actual constructors and notional constructors that result from the transformation of defaulted parameters as follows: — all non-template constructors of X, and — for each non-template constructor of X that has at least one parameter with a default argument, the set of constructors that results from omitting any ellipsis parameter speciﬁcation and successively omitting parameters with a default argument from the end of the parameter-type-list, and — all constructor templates of X, and — for each constructor template of X that has at least one parameter with a default argument, the set of constructor templates that results from omitting any ellipsis parameter speciﬁcation and successively omitting parameters with a default argument from the end of the parameter-type-list.

2

The constructor characteristics of a constructor or constructor template are — the template parameter list (14.1), if any, — the parameter-type-list (8.3.5), — the exception-speciﬁcation (15.4), — absence or presence of explicit (12.3.1), and — absence or presence of constexpr (7.1.5).

3

4

5

6

For each non-template constructor in the candidate set of inherited constructors other than a constructor having no parameters or a copy/move constructor having a single parameter, a constructor is implicitly declared with the same constructor characteristics unless there is a user-declared constructor with the same signature in the class where the using-declaration appears. Similarly, for each constructor template in the candidate set of inherited constructors, a constructor template is implicitly declared with the same constructor characteristics unless there is an equivalent user-declared constructor template (14.5.6.1) in the class where the using-declaration appears. [ Note: Default arguments are not inherited. — end note ] A constructor so declared has the same access as the corresponding constructor in X. It is deleted if the corresponding constructor in X is deleted (8.4). [ Note: Default and copy/move constructors may be implicitly declared as speciﬁed in 12.1 and 12.8. — end note ] [ Example: § 12.9 269

c ISO/IEC

N3337

struct B1 { B1(int); }; struct B2 { B2(int = 13, int = 42); }; struct D1 : B1 { using B1::B1; }; struct D2 : B2 { using B2::B2; };

The candidate set of inherited constructors in D1 for B1 is — B1(const B1&) — B1(B1&&) — B1(int) The set of constructors present in D1 is — D1(), implicitly-declared default constructor, ill-formed if odr-used — D1(const D1&), implicitly-declared copy constructor, not inherited — D1(D1&&), implicitly-declared move constructor, not inherited — D1(int), implicitly-declared inheriting constructor The candidate set of inherited constructors in D2 for B2 is — B2(const B2&) — B2(B2&&) — B2(int = 13, int = 42) — B2(int = 13) — B2() The set of constructors present in D2 is — D2(), implicitly-declared default constructor, not inherited — D2(const D2&), implicitly-declared copy constructor, not inherited — D2(D2&&), implicitly-declared move constructor, not inherited — D2(int, int), implicitly-declared inheriting constructor — D2(int), implicitly-declared inheriting constructor

§ 12.9

270

c ISO/IEC

N3337

7

— end example ] [ Note: If two using-declarations declare inheriting constructors with the same signatures, the program is ill-formed (9.2, 13.1), because an implicitly-declared constructor introduced by the ﬁrst using-declaration is not a user-declared constructor and thus does not preclude another declaration of a constructor with the same signature by a subsequent using-declaration. [ Example: struct B1 { B1(int); }; struct B2 { B2(int); }; struct D1 : B1, B2 { using B1::B1; using B2::B2; }; // ill-formed: attempts to declare D1(int) twice struct D2 : B1, B2 { using B1::B1; using B2::B2; D2(int); // OK: user declaration supersedes both implicit declarations };

8

9

— end example ] — end note ] An inheriting constructor for a class is implicitly deﬁned when it is odr-used (3.2) to create an object of its class type (1.8). An implicitly-deﬁned inheriting constructor performs the set of initializations of the class that would be performed by a user-written inline constructor for that class with a mem-initializer-list whose only mem-initializer has a mem-initializer-id that names the base class denoted in the nested-name-speciﬁer of the using-declaration and an expression-list as speciﬁed below, and where the compound-statement in its function body is empty (12.6.2). If that user-written constructor would be ill-formed, the program is ill-formed. Each expression in the expression-list is of the form static_cast(p), where p is the name of the corresponding constructor parameter and T is the declared type of p. [ Example: struct B1 { B1(int) { } }; struct B2 { B2(double) { } }; struct D1 : B1 { using B1::B1; int x; }; void test() { D1 d(6); D1 e; } struct D2 : B2 { using B2::B2;

// implicitly declares D1(int)

// OK: d.x is not initialized // error: D1 has no default constructor

// OK: implicitly declares D2(double)

§ 12.9

271

c ISO/IEC

N3337

B1 b; }; D2 f(1.0); // error: B1 has no default constructor

template< class T > struct D : T { using T::T; // declares all constructors from class T ~D() { std::clog B::f(1); pd->f("Ben"); }
2

// // // //

error: D::f(const char*) hides B::f(int) OK OK, calls D::f

— end example ] A locally declared function is not in the same scope as a function in a containing scope. [ Example: void f(const char*); void g() { extern void f(int); f("asdf"); } void caller () { extern void callee(int, int); { extern void callee(int); // hides callee(int, int) callee(88, 99); // error: only callee(int) in scope } }

// error: f(int) hides f(const char*) // so there is no f(const char*) in this scope

3

— end example ] Diﬀerent versions of an overloaded member function can be given diﬀerent access rules. [ Example: class buffer { private: char* p; int size; protected: buffer(int s, char* store) { size = s; p = store; } public: buffer(int s) { p = new char[size = s]; } };

— end example ]

13.3
1

Overload resolution

[over.match]

Overload resolution is a mechanism for selecting the best function to call given a list of expressions that are to be the arguments of the call and a set of candidate functions that can be called based on the context of the call. The selection criteria for the best function are the number of arguments, how well the arguments match the parameter-type-list of the candidate function, how well (for non-static member functions) the object matches the implicit object parameter, and certain other properties of the candidate function. [ Note: The function selected by overload resolution is not guaranteed to be appropriate for the context. Other

§ 13.3

276

c ISO/IEC

N3337

2

restrictions, such as the accessibility of the function, can make its use in the calling context ill-formed. — end note ] Overload resolution selects the function to call in seven distinct contexts within the language: — invocation of a function named in the function call syntax (13.3.1.1.1); — invocation of a function call operator, a pointer-to-function conversion function, a reference-to-pointerto-function conversion function, or a reference-to-function conversion function on a class object named in the function call syntax (13.3.1.1.2); — invocation of the operator referenced in an expression (13.3.1.2); — invocation of a constructor for direct-initialization (8.5) of a class object (13.3.1.3); — invocation of a user-deﬁned conversion for copy-initialization (8.5) of a class object (13.3.1.4); — invocation of a conversion function for initialization of an object of a nonclass type from an expression of class type (13.3.1.5); and — invocation of a conversion function for conversion to a glvalue or class prvalue to which a reference (8.5.3) will be directly bound (13.3.1.6). Each of these contexts deﬁnes the set of candidate functions and the list of arguments in its own unique way. But, once the candidate functions and argument lists have been identiﬁed, the selection of the best function is the same in all cases: — First, a subset of the candidate functions (those that have the proper number of arguments and meet certain other conditions) is selected to form a set of viable functions (13.3.2). — Then the best viable function is selected based on the implicit conversion sequences (13.3.3.1) needed to match each argument to the corresponding parameter of each viable function.

3

If a best viable function exists and is unique, overload resolution succeeds and produces it as the result. Otherwise overload resolution fails and the invocation is ill-formed. When overload resolution succeeds, and the best viable function is not accessible (Clause 11) in the context in which it is used, the program is ill-formed.

13.3.1
1

Candidate functions and argument lists

[over.match.funcs]

2

3

4

The subclauses of 13.3.1 describe the set of candidate functions and the argument list submitted to overload resolution in each of the seven contexts in which overload resolution is used. The source transformations and constructions deﬁned in these subclauses are only for the purpose of describing the overload resolution process. An implementation is not required to use such transformations and constructions. The set of candidate functions can contain both member and non-member functions to be resolved against the same argument list. So that argument and parameter lists are comparable within this heterogeneous set, a member function is considered to have an extra parameter, called the implicit object parameter, which represents the object for which the member function has been called. For the purposes of overload resolution, both static and non-static member functions have an implicit object parameter, but constructors do not. Similarly, when appropriate, the context can construct an argument list that contains an implied object argument to denote the object to be operated on. Since arguments and parameters are associated by position within their respective lists, the convention is that the implicit object parameter, if present, is always the ﬁrst parameter and the implied object argument, if present, is always the ﬁrst argument. For non-static member functions, the type of the implicit object parameter is — “lvalue reference to cv X” for functions declared without a ref-qualiﬁer or with the & ref-qualiﬁer — “rvalue reference to cv X” for functions declared with the && ref-qualiﬁer § 13.3.1 277

c ISO/IEC

N3337

5

where X is the class of which the function is a member and cv is the cv-qualiﬁcation on the member function declaration. [ Example: for a const member function of class X, the extra parameter is assumed to have type “reference to const X”. — end example ] For conversion functions, the function is considered to be a member of the class of the implied object argument for the purpose of deﬁning the type of the implicit object parameter. For non-conversion functions introduced by a using-declaration into a derived class, the function is considered to be a member of the derived class for the purpose of deﬁning the type of the implicit object parameter. For static member functions, the implicit object parameter is considered to match any object (since if the function is selected, the object is discarded). [ Note: No actual type is established for the implicit object parameter of a static member function, and no attempt will be made to determine a conversion sequence for that parameter (13.3.3). — end note ] During overload resolution, the implied object argument is indistinguishable from other arguments. The implicit object parameter, however, retains its identity since conversions on the corresponding argument shall obey these additional rules: — no temporary object can be introduced to hold the argument for the implicit object parameter; and — no user-deﬁned conversions can be applied to achieve a type match with it. For non-static member functions declared without a ref-qualiﬁer, an additional rule applies: — even if the implicit object parameter is not const-qualiﬁed, an rvalue can be bound to the parameter as long as in all other respects the argument can be converted to the type of the implicit object parameter. [ Note: The fact that such an argument is an rvalue does not aﬀect the ranking of implicit conversion sequences (13.3.3.2). — end note ]

6

Because other than in list-initialization only one user-deﬁned conversion is allowed in an implicit conversion sequence, special rules apply when selecting the best user-deﬁned conversion (13.3.3, 13.3.3.1). [ Example: class T { public: T(); }; class C : T { public: C(int); }; T a = 1;

// ill-formed: T(C(1)) not tried

7

— end example ] In each case where a candidate is a function template, candidate function template specializations are generated using template argument deduction (14.8.3, 14.8.2). Those candidates are then handled as candidate functions in the usual way.125 A given name can refer to one or more function templates and also to a set of overloaded non-template functions. In such a case, the candidate functions generated from each function template are combined with the set of non-template candidate functions. 13.3.1.1 Function call syntax postﬁx-expression ( expression-listopt )
125) The process of argument deduction fully determines the parameter types of the function template specializations, i.e., the parameters of function template specializations contain no template parameter types. Therefore the function template specializations can be treated as normal (non-template) functions for the remainder of overload resolution.

[over.match.call]

1

In a function call (5.2.2)

§ 13.3.1.1

278

c ISO/IEC

N3337

2

if the postﬁx-expression denotes a set of overloaded functions and/or function templates, overload resolution is applied as speciﬁed in 13.3.1.1.1. If the postﬁx-expression denotes an object of class type, overload resolution is applied as speciﬁed in 13.3.1.1.2. If the postﬁx-expression denotes the address of a set of overloaded functions and/or function templates, overload resolution is applied using that set as described above. If the function selected by overload resolution is a non-static member function, the program is ill-formed. [ Note: The resolution of the address of an overload set in other contexts is described in 13.4. — end note ] 13.3.1.1.1 Call to named function [over.call.func] Of interest in 13.3.1.1.1 are only those function calls in which the postﬁx-expression ultimately contains a name that denotes one or more functions that might be called. Such a postﬁx-expression, perhaps nested arbitrarily deep in parentheses, has one of the following forms: postﬁx-expression: postﬁx-expression . id-expression postﬁx-expression -> id-expression primary-expression

1

2

3

These represent two syntactic subcategories of function calls: qualiﬁed function calls and unqualiﬁed function calls. In qualiﬁed function calls, the name to be resolved is an id-expression and is preceded by an -> or . operator. Since the construct A->B is generally equivalent to (*A).B, the rest of Clause 13 assumes, without loss of generality, that all member function calls have been normalized to the form that uses an object and the . operator. Furthermore, Clause 13 assumes that the postﬁx-expression that is the left operand of the . operator has type “cv T” where T denotes a class126 . Under this assumption, the id-expression in the call is looked up as a member function of T following the rules for looking up names in classes (10.2). The function declarations found by that lookup constitute the set of candidate functions. The argument list is the expression-list in the call augmented by the addition of the left operand of the . operator in the normalized member function call as the implied object argument (13.3.1). In unqualiﬁed function calls, the name is not qualiﬁed by an -> or . operator and has the more general form of a primary-expression. The name is looked up in the context of the function call following the normal rules for name lookup in function calls (3.4). The function declarations found by that lookup constitute the set of candidate functions. Because of the rules for name lookup, the set of candidate functions consists (1) entirely of non-member functions or (2) entirely of member functions of some class T. In case (1), the argument list is the same as the expression-list in the call. In case (2), the argument list is the expression-list in the call augmented by the addition of an implied object argument as in a qualiﬁed function call. If the keyword this (9.3.2) is in scope and refers to class T, or a derived class of T, then the implied object argument is (*this). If the keyword this is not in scope or refers to another class, then a contrived object of type T becomes the implied object argument127 . If the argument list is augmented by a contrived object and overload resolution selects one of the non-static member functions of T, the call is ill-formed. 13.3.1.1.2 Call to object of class type [over.call.object] If the primary-expression E in the function call syntax evaluates to a class object of type “cv T”, then the set of candidate functions includes at least the function call operators of T. The function call operators of T are obtained by ordinary lookup of the name operator() in the context of (E).operator(). In addition, for each non-explicit conversion function declared in T of the form operator conversion-type-id ( ) attribute-speciﬁer-seqopt cv-qualiﬁer ;

1

2

where cv-qualiﬁer is the same cv-qualiﬁcation as, or a greater cv-qualiﬁcation than, cv, and where conversion-type-id denotes the type “pointer to function of (P1,...,Pn) returning R”, or the type “reference
126) Note that cv-qualiﬁers on the type of objects are signiﬁcant in overload resolution for both glvalue and class prvalue objects. 127) An implied object argument must be contrived to correspond to the implicit object parameter attributed to member functions during overload resolution. It is not used in the call to the selected function. Since the member functions all have the same implicit object parameter, the contrived object will not be the cause to select or reject a function.

§ 13.3.1.1.2

279

c ISO/IEC

N3337

to pointer to function of (P1,...,Pn) returning R”, or the type “reference to function of (P1,...,Pn) returning R”, a surrogate call function with the unique name call-function and having the form
R call-function ( conversion-type-id F, P1 a1, ... ,Pn an) { return F (a1,... ,an); }

3

4

is also considered as a candidate function. Similarly, surrogate call functions are added to the set of candidate functions for each non-explicit conversion function declared in a base class of T provided the function is not hidden within T by another intervening declaration128 . If such a surrogate call function is selected by overload resolution, the corresponding conversion function will be called to convert E to the appropriate function pointer or reference, and the function will then be invoked with the arguments of the call. If the conversion function cannot be called (e.g., because of an ambiguity), the program is ill-formed. The argument list submitted to overload resolution consists of the argument expressions present in the function call syntax preceded by the implied object argument (E). [ Note: When comparing the call against the function call operators, the implied object argument is compared against the implicit object parameter of the function call operator. When comparing the call against a surrogate call function, the implied object argument is compared against the ﬁrst parameter of the surrogate call function. The conversion function from which the surrogate call function was derived will be used in the conversion sequence for that parameter since it converts the implied object argument to the appropriate function pointer or reference required by that ﬁrst parameter. — end note ] [ Example: int f1(int); int f2(float); typedef int (*fp1)(int); typedef int (*fp2)(float); struct A { operator fp1() { return f1; } operator fp2() { return f2; } } a; int i = a(1); // calls f1 via pointer returned from // conversion function

— end example ] 13.3.1.2 Operators in expressions
1

[over.match.oper]

If no operand of an operator in an expression has a type that is a class or an enumeration, the operator is assumed to be a built-in operator and interpreted according to Clause 5. [ Note: Because ., .*, and :: cannot be overloaded, these operators are always built-in operators interpreted according to Clause 5. ?: cannot be overloaded, but the rules in this subclause are used to determine the conversions to be applied to the second and third operands when they have class or enumeration type (5.16). — end note ] [ Example: struct String { String (const String&); String (const char*); operator const char* (); }; String operator + (const String&, const String&); void f(void) { const char* p= "one" + "two"; int I = 1 + 1;

// // // // //

ill-formed because neither operand has user-deﬁned type Always evaluates to 2 even if user-deﬁned types exist which would perform the operation.

128) Note that this construction can yield candidate call functions that cannot be diﬀerentiated one from the other by overload resolution because they have identical declarations or diﬀer only in their return type. The call will be ambiguous if overload resolution cannot select a match to the call that is uniquely better than such undiﬀerentiable functions.

§ 13.3.1.2

280

c ISO/IEC

N3337

}
2

— end example ] If either operand has a type that is a class or an enumeration, a user-deﬁned operator function might be declared that implements this operator or a user-deﬁned conversion can be necessary to convert the operand to a type that is appropriate for a built-in operator. In this case, overload resolution is used to determine which operator function or built-in operator is to be invoked to implement the operator. Therefore, the operator notation is ﬁrst transformed to the equivalent function-call notation as summarized in Table 11 (where @ denotes one of the operators covered in the speciﬁed subclause). Table 11 — Relationship between operator and function call notation Subclause 13.5.1 13.5.2 13.5.3 13.5.5 13.5.6 13.5.7 Expression @a a@b a=b a[b] a-> a@ As member function (a).operator@ ( ) (a).operator@ (b) (a).operator= (b) (a).operator[](b) (a).operator-> ( ) (a).operator@ (0) As non-member function operator@ (a) operator@ (a, b)

operator@ (a, 0)

3

For a unary operator @ with an operand of a type whose cv-unqualiﬁed version is T1, and for a binary operator @ with a left operand of a type whose cv-unqualiﬁed version is T1 and a right operand of a type whose cv-unqualiﬁed version is T2, three sets of candidate functions, designated member candidates, nonmember candidates and built-in candidates, are constructed as follows: — If T1 is a complete class type, the set of member candidates is the result of the qualiﬁed lookup of T1::operator@ (13.3.1.1.1); otherwise, the set of member candidates is empty. — The set of non-member candidates is the result of the unqualiﬁed lookup of operator@ in the context of the expression according to the usual rules for name lookup in unqualiﬁed function calls (3.4.2) except that all member functions are ignored. However, if no operand has a class type, only those non-member functions in the lookup set that have a ﬁrst parameter of type T1 or “reference to (possibly cv-qualiﬁed) T1”, when T1 is an enumeration type, or (if there is a right operand) a second parameter of type T2 or “reference to (possibly cv-qualiﬁed) T2”, when T2 is an enumeration type, are candidate functions. — For the operator ,, the unary operator &, or the operator ->, the built-in candidates set is empty. For all other operators, the built-in candidates include all of the candidate operator functions deﬁned in 13.6 that, compared to the given operator, — have the same operator name, and — accept the same number of operands, and — accept operand types to which the given operand or operands can be converted according to 13.3.3.1, and — do not have the same parameter-type-list as any non-template non-member candidate.

4

For the built-in assignment operators, conversions of the left operand are restricted as follows: — no temporaries are introduced to hold the left operand, and — no user-deﬁned conversions are applied to the left operand to achieve a type match with the left-most parameter of a built-in candidate. § 13.3.1.2 281

c ISO/IEC

N3337

5 6

For all other operators, no such restrictions apply. The set of candidate functions for overload resolution is the union of the member candidates, the non-member candidates, and the built-in candidates. The argument list contains all of the operands of the operator. The best function from the set of candidate functions is selected according to 13.3.2 and 13.3.3.129 [ Example: struct A { operator int(); }; A operator+(const A&, const A&); void m() { A a, b; a + b; // operator+(a,b) chosen over int(a) + int(b) }

7

8

9

10

— end example ] If a built-in candidate is selected by overload resolution, the operands are converted to the types of the corresponding parameters of the selected operation function. Then the operator is treated as the corresponding built-in operator and interpreted according to Clause 5. The second operand of operator -> is ignored in selecting an operator-> function, and is not an argument when the operator-> function is called. When operator-> returns, the operator -> is applied to the value returned, with the original second operand.130 If the operator is the operator ,, the unary operator &, or the operator ->, and there are no viable functions, then the operator is assumed to be the built-in operator and interpreted according to Clause 5. [ Note: The lookup rules for operators in expressions are diﬀerent than the lookup rules for operator function names in a function call, as shown in the following example: struct A { }; void operator + (A, A); struct B { void operator + (B); void f (); }; A a; void B::f() { operator+ (a,a); a + a; }

// error: global operator hidden by member // OK: calls global operator+

— end note ] 13.3.1.3
1

Initialization by constructor

[over.match.ctor]

When objects of class type are direct-initialized (8.5), or copy-initialized from an expression of the same or a derived class type (8.5), overload resolution selects the constructor. For direct-initialization, the candidate functions are all the constructors of the class of the object being initialized. For copy-initialization, the candidate functions are all the converting constructors (12.3.1) of that class. The argument list is the expression-list or assignment-expression of the initializer. 13.3.1.4 Copy-initialization of class by user-deﬁned conversion [over.match.copy] Under the conditions speciﬁed in 8.5, as part of a copy-initialization of an object of class type, a user-deﬁned conversion can be invoked to convert an initializer expression to the type of the object being initialized.
129) If the set of candidate functions is empty, overload resolution is unsuccessful. 130) If the value returned by the operator-> function has class type, this may result in selecting and calling another operator->

1

function. The process repeats until an operator-> function returns a value of non-class type.

§ 13.3.1.4

282

c ISO/IEC

N3337

Overload resolution is used to select the user-deﬁned conversion to be invoked. Assuming that “cv1 T” is the type of the object being initialized, with T a class type, the candidate functions are selected as follows: — The converting constructors (12.3.1) of T are candidate functions. — When the type of the initializer expression is a class type “cv S”, the non-explicit conversion functions of S and its base classes are considered. When initializing a temporary to be bound to the ﬁrst parameter of a constructor that takes a reference to possibly cv-qualiﬁed T as its ﬁrst argument, called with a single argument in the context of direct-initialization, explicit conversion functions are also considered. Those that are not hidden within S and yield a type whose cv-unqualiﬁed version is the same type as T or is a derived class thereof are candidate functions. Conversion functions that return “reference to X” return lvalues or xvalues, depending on the type of reference, of type X and are therefore considered to yield X for this process of selecting candidate functions.
2

In both cases, the argument list has one argument, which is the initializer expression. [ Note: This argument will be compared against the ﬁrst parameter of the constructors and against the implicit object parameter of the conversion functions. — end note ] 13.3.1.5 Initialization by conversion function [over.match.conv]

1

Under the conditions speciﬁed in 8.5, as part of an initialization of an object of nonclass type, a conversion function can be invoked to convert an initializer expression of class type to the type of the object being initialized. Overload resolution is used to select the conversion function to be invoked. Assuming that “cv1 T” is the type of the object being initialized, and “cv S” is the type of the initializer expression, with S a class type, the candidate functions are selected as follows: — The conversion functions of S and its base classes are considered. Those non-explicit conversion functions that are not hidden within S and yield type T or a type that can be converted to type T via a standard conversion sequence (13.3.3.1.1) are candidate functions. For direct-initialization, those explicit conversion functions that are not hidden within S and yield type T or a type that can be converted to type T with a qualiﬁcation conversion (4.4) are also candidate functions. Conversion functions that return a cv-qualiﬁed type are considered to yield the cv-unqualiﬁed version of that type for this process of selecting candidate functions. Conversion functions that return “reference to cv2 X” return lvalues or xvalues, depending on the type of reference, of type “cv2 X” and are therefore considered to yield X for this process of selecting candidate functions. The argument list has one argument, which is the initializer expression. [ Note: This argument will be compared against the implicit object parameter of the conversion functions. — end note ] 13.3.1.6 Initialization by conversion function for direct reference binding [over.match.ref]

2

1

Under the conditions speciﬁed in 8.5.3, a reference can be bound directly to a glvalue or class prvalue that is the result of applying a conversion function to an initializer expression. Overload resolution is used to select the conversion function to be invoked. Assuming that “cv1 T” is the underlying type of the reference being initialized, and “cv S” is the type of the initializer expression, with S a class type, the candidate functions are selected as follows: — The conversion functions of S and its base classes are considered, except that for copy-initialization, only the non-explicit conversion functions are considered. Those that are not hidden within S and yield type “lvalue reference to cv2 T2” (when 8.5.3 requires an lvalue result) or “cv2 T2” or “rvalue reference to cv2 T2” (when 8.5.3 requires an rvalue result), where “cv1 T” is reference-compatible (8.5.3) with “cv2 T2”, are candidate functions. The argument list has one argument, which is the initializer expression. [ Note: This argument will be compared against the implicit object parameter of the conversion functions. — end note ]

2

§ 13.3.1.6

283

c ISO/IEC

N3337

13.3.1.7
1

Initialization by list-initialization

[over.match.list]

When objects of non-aggregate class type T are list-initialized (8.5.4), overload resolution selects the constructor in two phases: — Initially, the candidate functions are the initializer-list constructors (8.5.4) of the class T and the argument list consists of the initializer list as a single argument. — If no viable initializer-list constructor is found, overload resolution is performed again, where the candidate functions are all the constructors of the class T and the argument list consists of the elements of the initializer list. If the initializer list has no elements and T has a default constructor, the ﬁrst phase is omitted. In copy-list-initialization, if an explicit constructor is chosen, the initialization is ill-formed. [ Note: This diﬀers from other situations (13.3.1.3, 13.3.1.4), where only converting constructors are considered for copyinitialization. This restriction only applies if this initialization is part of the ﬁnal result of overload resolution. — end note ]

13.3.2
1

Viable functions

[over.match.viable]

2

From the set of candidate functions constructed for a given context (13.3.1), a set of viable functions is chosen, from which the best function will be selected by comparing argument conversion sequences for the best ﬁt (13.3.3). The selection of viable functions considers relationships between arguments and function parameters other than the ranking of conversion sequences. First, to be a viable function, a candidate function shall have enough parameters to agree in number with the arguments in the list. — If there are m arguments in the list, all candidate functions having exactly m parameters are viable. — A candidate function having fewer than m parameters is viable only if it has an ellipsis in its parameter list (8.3.5). For the purposes of overload resolution, any argument for which there is no corresponding parameter is considered to “match the ellipsis” (13.3.3.1.3) . — A candidate function having more than m parameters is viable only if the (m+1)-st parameter has a default argument (8.3.6).131 For the purposes of overload resolution, the parameter list is truncated on the right, so that there are exactly m parameters.

3

Second, for F to be a viable function, there shall exist for each argument an implicit conversion sequence (13.3.3.1) that converts that argument to the corresponding parameter of F. If the parameter has reference type, the implicit conversion sequence includes the operation of binding the reference, and the fact that an lvalue reference to non-const cannot be bound to an rvalue and that an rvalue reference cannot be bound to an lvalue can aﬀect the viability of the function (see 13.3.3.1.4).

13.3.3
1

Best viable function

[over.match.best]

Deﬁne ICSi(F) as follows: — if F is a static member function, ICS1 (F) is deﬁned such that ICS1 (F) is neither better nor worse than ICS1 (G) for any function G, and, symmetrically, ICS1 (G) is neither better nor worse than ICS1 (F)132 ; otherwise, — let ICSi(F) denote the implicit conversion sequence that converts the i-th argument in the list to the type of the i-th parameter of viable function F. 13.3.3.1 deﬁnes the implicit conversion sequences and 13.3.3.2 deﬁnes what it means for one implicit conversion sequence to be a better conversion sequence or worse conversion sequence than another.
131) According to 8.3.6, parameters following the (m+1)-st parameter must also have default arguments. 132) If a function is a static member function, this deﬁnition means that the ﬁrst argument, the implied object argument, has

no eﬀect in the determination of whether the function is better or worse than any other function.

§ 13.3.3

284

c ISO/IEC

N3337

Given these deﬁnitions, a viable function F1 is deﬁned to be a better function than another viable function F2 if for all arguments i, ICSi(F1) is not a worse conversion sequence than ICSi(F2), and then — for some argument j, ICSj(F1) is a better conversion sequence than ICSj(F2), or, if not that, — the context is an initialization by user-deﬁned conversion (see 8.5, 13.3.1.5, and 13.3.1.6) and the standard conversion sequence from the return type of F1 to the destination type (i.e., the type of the entity being initialized) is a better conversion sequence than the standard conversion sequence from the return type of F2 to the destination type. [ Example: struct A { A(); operator int(); operator double(); } a; int i = a;

float x = a;

// // // // //

a.operator int() followed by no conversion is better than a.operator double() followed by a conversion to int ambiguous: both possibilities require conversions, and neither is better than the other

— end example ] or, if not that, — F1 is a non-template function and F2 is a function template specialization, or, if not that, — F1 and F2 are function template specializations, and the function template for F1 is more specialized than the template for F2 according to the partial ordering rules described in 14.5.6.2.
2

If there is exactly one viable function that is a better function than all other viable functions, then it is the one selected by overload resolution; otherwise the call is ill-formed133 . [ Example: void Fcn(const int*, void Fcn(int*, int); int i; short s = 0; void f() { Fcn(&i, s); short);

// is ambiguous because // &i → int* is better than &i → const int* // but s → short is also better than s → int // calls Fcn(int*, int), because // &i → int* is better than &i → const int* // and 1L → short and 1L → int are indistinguishable // calls Fcn(int*, int), because // &i → int* is better than &i → const int* // and c → int is better than c → short

Fcn(&i, 1L);

Fcn(&i,’c’);

}
133) The algorithm for selecting the best viable function is linear in the number of viable functions. Run a simple tournament to ﬁnd a function W that is not worse than any opponent it faced. Although another function F that W did not face might be at least as good as W, F cannot be the best function because at some point in the tournament F encountered another function G such that F was not better than G. Hence, W is either the best function or there is no best function. So, make a second pass over the viable functions to verify that W is better than all other functions.

§ 13.3.3

285

c ISO/IEC

N3337

3

— end example ] If the best viable function resolves to a function for which multiple declarations were found, and if at least two of these declarations — or the declarations they refer to in the case of using-declarations — specify a default argument that made the function viable, the program is ill-formed. [ Example: namespace A { extern "C" void f(int = 5); } namespace B { extern "C" void f(int = 5); } using A::f; using B::f; void use() { f(3); f(); }

// OK, default argument was not used for viability // Error: found default argument twice

— end example ] 13.3.3.1
1

Implicit conversion sequences

[over.best.ics]

2

3

An implicit conversion sequence is a sequence of conversions used to convert an argument in a function call to the type of the corresponding parameter of the function being called. The sequence of conversions is an implicit conversion as deﬁned in Clause 4, which means it is governed by the rules for initialization of an object or reference by a single expression (8.5, 8.5.3). Implicit conversion sequences are concerned only with the type, cv-qualiﬁcation, and value category of the argument and how these are converted to match the corresponding properties of the parameter. Other properties, such as the lifetime, storage class, alignment, or accessibility of the argument and whether or not the argument is a bit-ﬁeld are ignored. So, although an implicit conversion sequence can be deﬁned for a given argument-parameter pair, the conversion from the argument to the parameter might still be ill-formed in the ﬁnal analysis. A well-formed implicit conversion sequence is one of the following forms: — a standard conversion sequence (13.3.3.1.1), — a user-deﬁned conversion sequence (13.3.3.1.2), or — an ellipsis conversion sequence (13.3.3.1.3).

4

5 6

However, when considering the argument of a constructor or user-deﬁned conversion function that is a candidate by 13.3.1.3 when invoked for the copying/moving of the temporary in the second step of a class copy-initialization, by 13.3.1.7 when passing the initializer list as a single argument or when the initializer list has exactly one element and a conversion to some class X or reference to (possibly cv-qualiﬁed) X is considered for the ﬁrst parameter of a constructor of X, or by 13.3.1.4, 13.3.1.5, or 13.3.1.6 in all cases, only standard conversion sequences and ellipsis conversion sequences are considered. For the case where the parameter type is a reference, see 13.3.3.1.4. When the parameter type is not a reference, the implicit conversion sequence models a copy-initialization of the parameter from the argument expression. The implicit conversion sequence is the one required to convert the argument expression to a prvalue of the type of the parameter. [ Note: When the parameter has a class type, this is a conceptual conversion deﬁned for the purposes of Clause 13; the actual initialization is deﬁned in terms of constructors and is not a conversion. — end note ] Any diﬀerence in top-level cv-qualiﬁcation is subsumed by the initialization itself and does not constitute a conversion. [ Example: a parameter of type A can be initialized from an argument of type const A. The implicit conversion sequence for that case is the § 13.3.3.1 286

c ISO/IEC

N3337

7

8

9

10

11

identity sequence; it contains no “conversion” from const A to A. — end example ] When the parameter has a class type and the argument expression has the same type, the implicit conversion sequence is an identity conversion. When the parameter has a class type and the argument expression has a derived class type, the implicit conversion sequence is a derived-to-base Conversion from the derived class to the base class. [ Note: There is no such standard conversion; this derived-to-base Conversion exists only in the description of implicit conversion sequences. — end note ] A derived-to-base Conversion has Conversion rank (13.3.3.1.1). In all contexts, when converting to the implicit object parameter or when converting to the left operand of an assignment operation only standard conversion sequences that create no temporary object for the result are allowed. If no conversions are required to match an argument to a parameter type, the implicit conversion sequence is the standard conversion sequence consisting of the identity conversion (13.3.3.1.1). If no sequence of conversions can be found to convert an argument to a parameter type or the conversion is otherwise ill-formed, an implicit conversion sequence cannot be formed. If several diﬀerent sequences of conversions exist that each convert the argument to the parameter type, the implicit conversion sequence associated with the parameter is deﬁned to be the unique conversion sequence designated the ambiguous conversion sequence. For the purpose of ranking implicit conversion sequences as described in 13.3.3.2, the ambiguous conversion sequence is treated as a user-deﬁned sequence that is indistinguishable from any other user-deﬁned conversion sequence134 . If a function that uses the ambiguous conversion sequence is selected as the best viable function, the call will be ill-formed because the conversion of one of the arguments in the call is ambiguous. The three forms of implicit conversion sequences mentioned above are deﬁned in the following subclauses. 13.3.3.1.1 Standard conversion sequences [over.ics.scs]

1

2

Table 12 summarizes the conversions deﬁned in Clause 4 and partitions them into four disjoint categories: Lvalue Transformation, Qualiﬁcation Adjustment, Promotion, and Conversion. [ Note: These categories are orthogonal with respect to value category, cv-qualiﬁcation, and data representation: the Lvalue Transformations do not change the cv-qualiﬁcation or data representation of the type; the Qualiﬁcation Adjustments do not change the value category or data representation of the type; and the Promotions and Conversions do not change the value category or cv-qualiﬁcation of the type. — end note ] [ Note: As described in Clause 4, a standard conversion sequence is either the Identity conversion by itself (that is, no conversion) or consists of one to three conversions from the other four categories. At most one conversion from each category is allowed in a single standard conversion sequence. If there are two or more
134) The ambiguous conversion sequence is ranked with user-deﬁned conversion sequences because multiple conversion sequences for an argument can exist only if they involve diﬀerent user-deﬁned conversions. The ambiguous conversion sequence is indistinguishable from any other user-deﬁned conversion sequence because it represents at least two user-deﬁned conversion sequences, each with a diﬀerent user-deﬁned conversion, and any other user-deﬁned conversion sequence must be indistinguishable from at least one of them. This rule prevents a function from becoming non-viable because of an ambiguous conversion sequence for one of its parameters. Consider this example,

class B; class A { class B { class C { void f(A) void f(C) B b; f(b);

A (B&);}; operator A (); }; C (B&); }; { } { } // ambiguous because b → C via constructor and // b → A via constructor or conversion function.

If it were not for this rule, f(A) would be eliminated as a viable function for the call f(b) causing overload resolution to select f(C) as the function to call even though it is not clearly the best choice. On the other hand, if an f(B) were to be declared then f(b) would resolve to that f(B) because the exact match with f(B) is better than any of the sequences required to match f(A).

§ 13.3.3.1.1

287

c ISO/IEC

N3337

3

conversions in the sequence, the conversions are applied in the canonical order: Lvalue Transformation, Promotion or Conversion, Qualiﬁcation Adjustment. — end note ] Each conversion in Table 12 also has an associated rank (Exact Match, Promotion, or Conversion). These are used to rank standard conversion sequences (13.3.3.2). The rank of a conversion sequence is determined by considering the rank of each conversion in the sequence and the rank of any reference binding (13.3.3.1.4). If any of those has Conversion rank, the sequence has Conversion rank; otherwise, if any of those has Promotion rank, the sequence has Promotion rank; otherwise, the sequence has Exact Match rank. Table 12 — Conversions Conversion No conversions required Lvalue-to-rvalue conversion Array-to-pointer conversion Function-to-pointer conversion Qualiﬁcation conversions Integral promotions Floating point promotion Integral conversions Floating point conversions Floating-integral conversions Pointer conversions Pointer to member conversions Boolean conversions Category Identity Lvalue Transformation Qualiﬁcation Adjustment Promotion Promotion Rank Subclause 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12

Exact Match

Conversion

Conversion

13.3.3.1.2
1

User-deﬁned conversion sequences

[over.ics.user]

2

3

4

A user-deﬁned conversion sequence consists of an initial standard conversion sequence followed by a userdeﬁned conversion (12.3) followed by a second standard conversion sequence. If the user-deﬁned conversion is speciﬁed by a constructor (12.3.1), the initial standard conversion sequence converts the source type to the type required by the argument of the constructor. If the user-deﬁned conversion is speciﬁed by a conversion function (12.3.2), the initial standard conversion sequence converts the source type to the implicit object parameter of the conversion function. The second standard conversion sequence converts the result of the user-deﬁned conversion to the target type for the sequence. Since an implicit conversion sequence is an initialization, the special rules for initialization by user-deﬁned conversion apply when selecting the best user-deﬁned conversion for a user-deﬁned conversion sequence (see 13.3.3 and 13.3.3.1). If the user-deﬁned conversion is speciﬁed by a specialization of a conversion function template, the second standard conversion sequence shall have exact match rank. A conversion of an expression of class type to the same class type is given Exact Match rank, and a conversion of an expression of class type to a base class of that type is given Conversion rank, in spite of the fact that a copy/move constructor (i.e., a user-deﬁned conversion function) is called for those cases. 13.3.3.1.3 Ellipsis conversion sequences [over.ics.ellipsis] An ellipsis conversion sequence occurs when an argument in a function call is matched with the ellipsis parameter speciﬁcation of the function called (see 5.2.2). 13.3.3.1.4 Reference binding [over.ics.ref] When a parameter of reference type binds directly (8.5.3) to an argument expression, the implicit conversion sequence is the identity conversion, unless the argument expression has a type that is a derived class of the

1

1

§ 13.3.3.1.4

288

c ISO/IEC

N3337

parameter type, in which case the implicit conversion sequence is a derived-to-base Conversion (13.3.3.1). [ Example: struct A {}; struct B : public A {} b; int f(A&); int f(B&); int i = f(b);

// calls f(B&), an exact match, rather than // f(A&), a conversion

2

3

4

5

— end example ] If the parameter binds directly to the result of applying a conversion function to the argument expression, the implicit conversion sequence is a user-deﬁned conversion sequence (13.3.3.1.2), with the second standard conversion sequence either an identity conversion or, if the conversion function returns an entity of a type that is a derived class of the parameter type, a derived-to-base Conversion. When a parameter of reference type is not bound directly to an argument expression, the conversion sequence is the one required to convert the argument expression to the underlying type of the reference according to 13.3.3.1. Conceptually, this conversion sequence corresponds to copy-initializing a temporary of the underlying type with the argument expression. Any diﬀerence in top-level cv-qualiﬁcation is subsumed by the initialization itself and does not constitute a conversion. Except for an implicit object parameter, for which see 13.3.1, a standard conversion sequence cannot be formed if it requires binding an lvalue reference other than a reference to a non-volatile const type to an rvalue or binding an rvalue reference to an lvalue other than a function lvalue. [ Note: This means, for example, that a candidate function cannot be a viable function if it has a non-const lvalue reference parameter (other than the implicit object parameter) and the corresponding argument is a temporary or would require one to be created to initialize the lvalue reference (see 8.5.3). — end note ] Other restrictions on binding a reference to a particular argument that are not based on the types of the reference and the argument do not aﬀect the formation of a standard conversion sequence, however. [ Example: a function with an “lvalue reference to int” parameter can be a viable candidate even if the corresponding argument is an int bit-ﬁeld. The formation of implicit conversion sequences treats the int bit-ﬁeld as an int lvalue and ﬁnds an exact match with the parameter. If the function is selected by overload resolution, the call will nonetheless be ill-formed because of the prohibition on binding a non-const lvalue reference to a bit-ﬁeld (8.5.3). — end example ] The binding of a reference to an expression that is reference-compatible with added qualiﬁcation inﬂuences the rank of a standard conversion; see 13.3.3.2 and 8.5.3. 13.3.3.1.5 List-initialization sequence [over.ics.list] When an argument is an initializer list (8.5.4), it is not an expression and special rules apply for converting it to a parameter type. If the parameter type is std::initializer_list or “array of X”135 and all the elements of the initializer list can be implicitly converted to X, the implicit conversion sequence is the worst conversion necessary to convert an element of the list to X. This conversion can be a user-deﬁned conversion even in the context of a call to an initializer-list constructor. [ Example: void f(std::initializer_list); f( {1,2,3} ); // OK: f(initializer_list) identity conversion f( {’a’,’b’} ); // OK: f(initializer_list) integral promotion f( {1.0} ); // error: narrowing struct A { A(std::initializer_list); A(std::initializer_list); A(std::initializer_list); };

1

2

// #1 // #2 // #3

135) Since there are no parameters of array type, this will only occur as the underlying type of a reference parameter.

§ 13.3.3.1.5

289

c ISO/IEC

N3337

A a{ 1.0,2.0 }; void g(A); g({ "foo", "bar" }); typedef int IA[3]; void h(const IA&); h({ 1, 2, 3 });
3

// OK, uses #1

// OK, uses #3

// OK: identity conversion

— end example ] Otherwise, if the parameter is a non-aggregate class X and overload resolution per 13.3.1.7 chooses a single best constructor of X to perform the initialization of an object of type X from the argument initializer list, the implicit conversion sequence is a user-deﬁned conversion sequence. If multiple constructors are viable but none is better than the others, the implicit conversion sequence is the ambiguous conversion sequence. Userdeﬁned conversions are allowed for conversion of the initializer list elements to the constructor parameter types except as noted in 13.3.3.1. [ Example: struct A { A(std::initializer_list); }; void f(A); f( {’a’, ’b’} ); // OK: f(A(std::initializer_list)) user-deﬁned conversion struct B { B(int, double); }; void g(B); g( {’a’, ’b’} ); g( {1.0, 1,0} ); void f(B); f( {’a’, ’b’} ); struct C { C(std::string); }; void h(C); h({"foo"}); struct D { C(A, C); }; void i(D); i({ {1,2}, {"bar"} });

// OK: g(B(int,double)) user-deﬁned conversion // error: narrowing

// error: ambiguous f(A) or f(B)

// OK: h(C(std::string("foo")))

// OK: i(D(A(std::initializer_list{1,2}),C(std::string("bar"))))

4

— end example ] Otherwise, if the parameter has an aggregate type which can be initialized from the initializer list according to the rules for aggregate initialization (8.5.1), the implicit conversion sequence is a user-deﬁned conversion sequence. [ Example: struct A { int m1; double m2; }; void f(A);

§ 13.3.3.1.5

290

c ISO/IEC

N3337

f( {’a’, ’b’} ); f( {1.0} );
5

// OK: f(A(int,double)) user-deﬁned conversion // error: narrowing

— end example ] Otherwise, if the parameter is a reference, see 13.3.3.1.4. [ Note: The rules in this section will apply for initializing the underlying temporary for the reference. — end note ] [ Example: struct A { int m1; double m2; }; void f(const A&); f( {’a’, ’b’} ); f( {1.0} ); void g(const double &); g({1});

// OK: f(A(int,double)) user-deﬁned conversion // error: narrowing

// same conversion as int to double

6

— end example ] Otherwise, if the parameter type is not a class: — if the initializer list has one element, the implicit conversion sequence is the one required to convert the element to the parameter type; [ Example: void f(int); f( {’a’} ); f( {1.0} ); // OK: same conversion as char to int // error: narrowing

— end example ] — if the initializer list has no elements, the implicit conversion sequence is the identity conversion. [ Example: void f(int); f( { } ); // OK: identity conversion

— end example ]
7

In all cases other than those enumerated above, no conversion is possible. 13.3.3.2 Ranking implicit conversion sequences [over.ics.rank]

1

2

13.3.3.2 deﬁnes a partial ordering of implicit conversion sequences based on the relationships better conversion sequence and better conversion. If an implicit conversion sequence S1 is deﬁned by these rules to be a better conversion sequence than S2, then it is also the case that S2 is a worse conversion sequence than S1. If conversion sequence S1 is neither better than nor worse than conversion sequence S2, S1 and S2 are said to be indistinguishable conversion sequences. When comparing the basic forms of implicit conversion sequences (as deﬁned in 13.3.3.1) — a standard conversion sequence (13.3.3.1.1) is a better conversion sequence than a user-deﬁned conversion sequence or an ellipsis conversion sequence, and — a user-deﬁned conversion sequence (13.3.3.1.2) is a better conversion sequence than an ellipsis conversion sequence (13.3.3.1.3).

3

Two implicit conversion sequences of the same form are indistinguishable conversion sequences unless one of the following rules applies:

§ 13.3.3.2

291

c ISO/IEC

N3337

— Standard conversion sequence S1 is a better conversion sequence than standard conversion sequence S2 if — S1 is a proper subsequence of S2 (comparing the conversion sequences in the canonical form deﬁned by 13.3.3.1.1, excluding any Lvalue Transformation; the identity conversion sequence is considered to be a subsequence of any non-identity conversion sequence) or, if not that, — the rank of S1 is better than the rank of S2, or S1 and S2 have the same rank and are distinguishable by the rules in the paragraph below, or, if not that, — S1 and S2 diﬀer only in their qualiﬁcation conversion and yield similar types T1 and T2 (4.4), respectively, and the cv-qualiﬁcation signature of type T1 is a proper subset of the cv-qualiﬁcation signature of type T2. [ Example: int int int int f(const int *); f(int *); i; j = f(&i);

// calls f(int*)

— end example ] or, if not that, — S1 and S2 are reference bindings (8.5.3) and neither refers to an implicit object parameter of a non-static member function declared without a ref-qualiﬁer, and S1 binds an rvalue reference to an rvalue and S2 binds an lvalue reference. [ Example: int i; int f1(); int&& f2(); int g(const int&); int g(const int&&); int j = g(i); int k = g(f1()); int l = g(f2()); struct A { A& operator declaration template-parameter-list: template-parameter template-parameter-list , template-parameter [ Note: The > token following the template-parameter-list of a template-declaration may be the product of

replacing a >> token by two consecutive > tokens (14.2). — end note ] The declaration in a template-declaration shall — declare or deﬁne a function or a class, or — deﬁne a member function, a member class, a member enumeration, or a static data member of a class template or of a class nested within a class template, or — deﬁne a member template of a class or class template, or — be an alias-declaration. A template-declaration is a declaration. A template-declaration is also a deﬁnition if its declaration deﬁnes a function, a class, or a static data member. A template-declaration can appear only as a namespace scope or class scope declaration. In a function template declaration, the last component of the declarator-id shall not be a template-id. [ Note: That last component may be an identiﬁer, an operator-function-id, a conversion-function-id, or a literal-operator-id. In a class template declaration, if the class name is a simple-template-id, the declaration declares a class template partial specialization (14.5.5). — end note ] In a template-declaration, explicit specialization, or explicit instantiation the init-declarator-list in the declaration shall contain at most one declarator. When such a declaration is used to declare a class template, no declarator is permitted. A template name has linkage (3.5). A non-member function template can have internal linkage; any other template name shall have external linkage. Specializations (explicit or implicit) of a template that has internal linkage are distinct from all specializations in other translation units. A template, a template explicit specialization (14.7.3), and a class template partial specialization shall not have C linkage. Use of a linkage speciﬁcation other than C or C++ with any of these constructs is conditionally-supported, with implementation-deﬁned semantics. Template deﬁnitions shall obey the one deﬁnition rule (3.2). [ Note: Default arguments for function templates and for member functions of class templates are considered deﬁnitions for the purpose of template instantiation (14.5) and must also obey the one deﬁnition rule. — end note ] A class template shall not have the same name as any other template, class, function, variable, enumeration, enumerator, namespace, or type in the same scope (3.3), except as speciﬁed in (14.5.5). Except that a function template can be overloaded either by (non-template) functions with the same name or by other function templates with the same name (14.8.3), a template name declared in namespace scope or in class scope shall be unique in that scope. A function template, member function of a class template, or static data member of a class template shall be deﬁned in every translation unit in which it is implicitly instantiated (14.7.1) unless the corresponding specialization is explicitly instantiated (14.7.2) in some translation unit; no diagnostic is required.

2

3

4

5

6

Templates

303

c ISO/IEC

N3337

14.1
1

Template parameters

[temp.param]

The syntax for template-parameters is: template-parameter: type-parameter parameter-declaration type-parameter: class ...opt identiﬁeropt class identiﬁeropt = type-id typename ...opt identiﬁeropt typename identiﬁeropt = type-id template < template-parameter-list > class ...opt identiﬁeropt template < template-parameter-list > class identiﬁeropt = id-expression [ Note: The > token following the template-parameter-list of a type-parameter may be the product of replacing

2

a >> token by two consecutive > tokens (14.2). — end note ] There is no semantic diﬀerence between class and typename in a template-parameter. typename followed by an unqualiﬁed-id names a template type parameter. typename followed by a qualiﬁed-id denotes the type in a non-type 137 parameter-declaration. A storage class shall not be speciﬁed in a template-parameter declaration. [ Note: A template parameter may be a class template. For example, template class myarray { /∗ ... ∗/ }; template class Map { C key; C value; };

3

— end note ] A type-parameter whose identiﬁer does not follow an ellipsis deﬁnes its identiﬁer to be a typedef-name (if declared with class or typename) or template-name (if declared with template) in the scope of the template declaration. [ Note: Because of the name lookup rules, a template-parameter that could be interpreted as either a non-type template-parameter or a type-parameter (because its identiﬁer is the name of an already existing class) is taken as a type-parameter. For example, class T { /∗ ... ∗/ }; int i; template void f(T t) { T t1 = i; // template-parameters T and i ::T t2 = ::i; // global namespace members T and i }

4

Here, the template f has a type-parameter called T, rather than an unnamed non-type template-parameter of class T. — end note ] A non-type template-parameter shall have one of the following (optionally cv-qualiﬁed) types: — integral or enumeration type, — pointer to object or pointer to function, — lvalue reference to object or lvalue reference to function, — pointer to member,
137) Since template template-parameters and template template-arguments are treated as types for descriptive purposes, the terms non-type parameter and non-type argument are used to refer to non-type, non-template parameters and arguments.

§ 14.1

304

c ISO/IEC

N3337

— std::nullptr_t.
5

6

[ Note: Other types are disallowed either explicitly below or implicitly by the rules governing the form of template-arguments (14.3). — end note ] The top-level cv-qualiﬁers on the template-parameter are ignored when determining its type. A non-type non-reference template-parameter is a prvalue. It shall not be assigned to or in any other way have its value changed. A non-type non-reference template-parameter cannot have its address taken. When a non-type non-reference template-parameter is used as an initializer for a reference, a temporary is always used. [ Example: template void f() { i++; // error: change of template-parameter value &x; &i; int& ri = i; const int& cri = i; } // OK // error: address of non-reference template-parameter // error: non-const reference bound to temporary // OK: const reference bound to temporary

7

— end example ] A non-type template-parameter shall not be declared to have ﬂoating point, class, or void type. [ Example: template class X; template class Y; template class Z; // error // OK // OK

8

— end example ] A non-type template-parameter of type “array of T” or “function returning T” is adjusted to be of type “pointer to T” or “pointer to function returning T”, respectively. [ Example: template struct R { /∗ ... ∗/ }; template struct S { /∗ ... ∗/ }; int p; R w; // OK S x; // OK due to parameter adjustment int v[5]; R y; // OK due to implicit argument conversion S z; // OK due to both adjustment and conversion

9

10

— end example ] A default template-argument is a template-argument (14.3) speciﬁed after = in a template-parameter. A default template-argument may be speciﬁed for any kind of template-parameter (type, non-type, template) that is not a template parameter pack (14.5.3). A default template-argument may be speciﬁed in a template declaration. A default template-argument shall not be speciﬁed in the template-parameter-lists of the deﬁnition of a member of a class template that appears outside of the member’s class. A default template-argument shall not be speciﬁed in a friend class template declaration. If a friend function template declaration speciﬁes a default template-argument, that declaration shall be a deﬁnition and shall be the only declaration of the function template in the translation unit. The set of default template-arguments available for use with a template declaration or deﬁnition is obtained by merging the default arguments from the deﬁnition (if in scope) and all declarations in scope in the same way default function arguments are (8.3.6). [ Example: template class A; template class A;

is equivalent to § 14.1 305

c ISO/IEC

N3337

template class A;
11

— end example ] If a template-parameter of a class template or alias template has a default template-argument, each subsequent template-parameter shall either have a default template-argument supplied or be a template parameter pack. If a template-parameter of a primary class template or alias template is a template parameter pack, it shall be the last template-parameter. A template parameter pack of a function template shall not be followed by another template parameter unless that template parameter can be deduced or has a default argument (14.8.2). [ Example: template class B; // U cannot be deduced or speciﬁed template void f() { } template void g() { } // error

12

— end example ] A template-parameter shall not be given default arguments by two diﬀerent declarations in the same scope. [ Example: template class X; template class X { /∗... ∗/ }; // error

13

— end example ] When parsing a default template-argument for a non-type template-parameter, the ﬁrst non-nested > is taken as the end of the template-parameter-list rather than a greater-than operator. [ Example: template 4 > class X { /∗ ... ∗/ }; template 4) > class Y { /∗ ... ∗/ }; // syntax error

// OK

14

— end example ] A template-parameter of a template template-parameter is permitted to have a default template-argument. When such default arguments are speciﬁed, they apply to the template template-parameter in the scope of the template template-parameter. [ Example: template struct B {}; template struct A { inline void f(); inline void g(); }; template void A::f() { T t; // error - TT has no default template argument } template void A::g() { T t; // OK - T }

15

— end example ] If a template-parameter is a type-parameter with an ellipsis prior to its optional identiﬁer or is a parameterdeclaration that declares a parameter pack (8.3.5), then the template-parameter is a template parameter pack (14.5.3). A template parameter pack that is a parameter-declaration whose type contains one or more unexpanded parameter packs is a pack expansion. Similarly, a template parameter pack that is a typeparameter with a template-parameter-list containing one or more unexpanded parameter packs is a pack expansion. A template parameter pack that is a pack expansion shall not expand a parameter pack declared in the same template-parameter-list. [ Example: § 14.1 306

c ISO/IEC

N3337

template class Tuple; template struct multi_array; template struct value_holder { template apply { };

// // // //

Types is a template type parameter pack but not a pack expansion Dims is a non-type template parameter pack but not a pack expansion

// Values is a non-type template parameter pack // and a pack expansion

}; template struct static_array;// error: Values expands template type parameter // pack T within the same template parameter list

— end example ]

14.2
1

Names of template specializations simple-template-id: template-name < template-argument-listopt > template-id: simple-template-id operator-function-id < template-argument-listopt > literal-operator-id < template-argument-listopt > template-name: identiﬁer template-argument-list: template-argument ...opt template-argument-list , template-argument ...opt template-argument: constant-expression type-id id-expression

[temp.names]

A template specialization (14.7) can be referred to by a template-id:

2

3

[ Note: The name lookup rules (3.4) are used to associate the use of a name with a template declaration; that is, to identify a name as a template-name. — end note ] For a template-name to be explicitly qualiﬁed by the template arguments, the name must be known to refer to a template. After name lookup (3.4) ﬁnds that a name is a template-name or that an operator-function-id or a literaloperator-id refers to a set of overloaded functions any member of which is a function template if this is followed by a 138 is taken as the ending delimiter rather than a greater-than operator. Similarly, the ﬁrst non-nested >> is treated as two consecutive but distinct > tokens, the ﬁrst of which is taken as the end of the template-argument-list and completes the template-id. [ Note: The second > token produced by this replacement rule may terminate an enclosing template-id construct or it may be part of a diﬀerent construct (e.g. a cast). — end note ] [ Example: template class X { /* ... X< 1>2 > x1; X2)> x2; template class Y { /* ... Y x3; Y1>> x4; */ }; // syntax error // OK */ }; // OK, same as Y x3; // syntax error

138) A > that encloses the type-id of a dynamic_cast, static_cast, reinterpret_cast or const_cast, or which encloses the template-arguments of a subsequent template-id, is considered nested for the purpose of this description.

§ 14.2

307

c ISO/IEC

N3337

Y1)>> x5;
4

// OK

— end example ] When the name of a member template specialization appears after . or -> in a postﬁx-expression or after a nested-name-speciﬁer in a qualiﬁed-id, and the object expression of the postﬁx-expression is type-dependent or the nested-name-speciﬁer in the qualiﬁed-id refers to a dependent type, but the name is not a member of the current instantiation (14.6.2.1), the member template name must be preﬁxed by the keyword template. Otherwise the name is assumed to name a non-template. [ Example: struct X { template X* alloc(); template static X* adjust(); }; template void f(T* p) { T* p1 = p->alloc(); // ill-formed: < T* p2 = p->template alloc(); // OK: < starts T::adjust(); // ill-formed: < T::template adjust(); // OK: < starts }

means less than template argument list means less than template argument list

5

— end example ] A name preﬁxed by the keyword template shall be a template-id or the name shall refer to a class template. [ Note: The keyword template may not be applied to non-template members of class templates. — end note ] [ Note: As is the case with the typename preﬁx, the template preﬁx is allowed in cases where it is not strictly necessary; i.e., when the nested-name-speciﬁer or the expression on the left of the -> or . is not dependent on a template-parameter, or the use does not appear in the scope of a template. — end note ] [ Example: template struct A { void f(int); template void f(U); }; template void f(T t) { A a; a.template f(t); a.template f(t); } template struct B { template struct C { }; }; // OK: T::template C names a class template: template struct D { }; D db;

// OK: calls template // error: not a template-id

6 7

— end example ] A simple-template-id that names a class template specialization is a class-name (Clause 9). A template-id that names an alias template specialization is a type-name.

14.3
1

Template arguments

[temp.arg]

There are three forms of template-argument, corresponding to the three forms of template-parameter: type, non-type and template. The type and form of each template-argument speciﬁed in a template-id shall match the type and form speciﬁed for the corresponding parameter declared by the template in its templateparameter-list. When the parameter declared by the template is a template parameter pack (14.5.3), it will correspond to zero or more template-arguments. [ Example: § 14.3 308

c ISO/IEC

N3337

template class Array { T* v; int sz; public: explicit Array(int); T& operator[](int); T& elem(int i) { return v[i]; } }; Array v1(20); typedef std::complex dcomplex; Array v2(30); Array v3(40); void bar() { v1[3] = 7; v2[3] = v3.elem(4) = dcomplex(7,8); }
2

// std::complex is a standard // library template

— end example ] In a template-argument, an ambiguity between a type-id and an expression is resolved to a type-id, regardless of the form of the corresponding template-parameter.139 [ Example: template void f(); template void f(); void g() { f(); }

// int() is a type-id: call the ﬁrst f()

3

— end example ] The name of a template-argument shall be accessible at the point where it is used as a template-argument. [ Note: If the name of the template-argument is accessible at the point where it is used as a templateargument, there is no further access restriction in the resulting instantiation where the corresponding template-parameter name is used. — end note ] [ Example: template class X { static T t; }; class Y { private: struct S { /∗ ... ∗/ }; X x; // OK: S is accessible // X has a static member of type Y::S // OK: even though Y::S is private }; X y; // error: S not accessible

— end example ] For a template-argument that is a class type or a class template, the template deﬁnition has no special access rights to the members of the template-argument. [ Example:
139) There is no such ambiguity in a default template-argument because the form of the template-parameter determines the allowable forms of the template-argument.

§ 14.3

309

c ISO/IEC

N3337

template class A { typename T::S s; }; template class B { private: struct S { /∗ ... ∗/ }; }; A b;
4

// ill-formed: A has no access to B::S

— end example ] When template argument packs or default template-arguments are used, a template-argument list can be empty. In that case the empty brackets shall still be used as the template-argument-list. [ Example: template class String; String* p; // OK: String String* q; // syntax error template class Tuple; Tuple* t; // OK: Elements is empty Tuple* u; // syntax error

5

— end example ] An explicit destructor call (12.4) for an object that has a type that is a class template specialization may explicitly specify the template-arguments. [ Example: template struct A { ~A(); }; void f(A* p, A* q) { p->A::~A(); q->A::~A(); }

// OK: destructor call // OK: destructor call

6

7

8

— end example ] If the use of a template-argument gives rise to an ill-formed construct in the instantiation of a template specialization, the program is ill-formed. When the template in a template-id is an overloaded function template, both non-template functions in the overload set and function templates in the overload set for which the template-arguments do not match the template-parameters are ignored. If none of the function templates have matching template-parameters, the program is ill-formed. A template-argument followed by an ellipsis is a pack expansion (14.5.3).

14.3.1
1 2

Template type arguments

[temp.arg.type]

A template-argument for a template-parameter which is a type shall be a type-id. [ Example: template class X { }; template void f(T t) { } struct { } unnamed_obj; void f() { struct A { }; enum { e1 }; typedef struct { } B; B b; X x1; // OK

§ 14.3.1

310

c ISO/IEC

N3337

X x2; X x3; f(e1); f(unnamed_obj); f(b); }
3

// // // // //

OK OK OK OK OK

— end example ] [ Note: A template type argument may be an incomplete type (3.9). — end note ] If a declaration acquires a function type through a type dependent on a template-parameter and this causes a declaration that does not use the syntactic form of a function declarator to have function type, the program is ill-formed. [ Example: template struct A { static T t; }; typedef int function(); A a;

// ill-formed: would declare A::t // as a static member function

— end example ]

14.3.2
1

Template non-type arguments

[temp.arg.nontype]

A template-argument for a non-type, non-template template-parameter shall be one of: — for a non-type template-parameter of integral or enumeration type, a converted constant expression (5.19) of the type of the template-parameter; or — the name of a non-type template-parameter; or — a constant expression (5.19) that designates the address of an object with static storage duration and external or internal linkage or a function with external or internal linkage, including function templates and function template-ids but excluding non-static class members, expressed (ignoring parentheses) as & id-expression, except that the & may be omitted if the name refers to a function or array and shall be omitted if the corresponding template-parameter is a reference; or — a constant expression that evaluates to a null pointer value (4.10); or — a constant expression that evaluates to a null member pointer value (4.11); or — a pointer to member expressed as described in 5.3.1.

2

[ Note: A string literal (2.14.5) does not satisfy the requirements of any of these categories and thus is not an acceptable template-argument. [ Example: template class X { /∗ ... ∗/ }; X x1; // error: string literal as template-argument

const char p[] = "Vivisectionist"; X x2; // OK
3

— end example ] — end note ] [ Note: Addresses of array elements and names or addresses of non-static class members are not acceptable template-arguments. [ Example:

§ 14.3.2

311

c ISO/IEC

N3337

template class X { }; int a[10]; struct S { int m; static int s; } s; X x3; X x4; X x5; X x6;
4

// // // //

error: address of array element error: address of non-static member error: &S::s must be used OK: address of static member

— end example ] — end note ] [ Note: Temporaries, unnamed lvalues, and named lvalues with no linkage are not acceptable templatearguments when the corresponding template-parameter has reference type. [ Example: template struct B { /∗ ... ∗/ }; B b2; int c = 1; B b1; // error: temporary would be required for template argument

// OK

5

— end example ] — end note ] The following conversions are performed on each expression used as a non-type template-argument. If a non-type template-argument cannot be converted to the type of the corresponding template-parameter then the program is ill-formed. — For a non-type template-parameter of integral or enumeration type, conversions permitted in a converted constant expression (5.19) are applied. — for a non-type template-parameter of type pointer to object, qualiﬁcation conversions (4.4) and the array-to-pointer conversion (4.2) are applied; if the template-argument is of type std::nullptr_t, the null pointer conversion (4.10) is applied. [ Note: In particular, neither the null pointer conversion for a zero-valued integral constant expression (4.10) nor the derived-to-base conversion (4.10) are applied. Although 0 is a valid template-argument for a non-type template-parameter of integral type, it is not a valid template-argument for a non-type template-parameter of pointer type. However, both (int*)0 and nullptr are valid template-arguments for a non-type template-parameter of type “pointer to int.” — end note ] — For a non-type template-parameter of type reference to object, no conversions apply. The type referred to by the reference may be more cv-qualiﬁed than the (otherwise identical) type of the templateargument. The template-parameter is bound directly to the template-argument, which shall be an lvalue. — For a non-type template-parameter of type pointer to function, the function-to-pointer conversion (4.3) is applied; if the template-argument is of type std::nullptr_t, the null pointer conversion (4.10) is applied. If the template-argument represents a set of overloaded functions (or a pointer to such), the matching function is selected from the set (13.4). — For a non-type template-parameter of type reference to function, no conversions apply. If the templateargument represents a set of overloaded functions, the matching function is selected from the set (13.4). — For a non-type template-parameter of type pointer to member function, if the template-argument is of type std::nullptr_t, the null member pointer conversion (4.11) is applied; otherwise, no conversions apply. If the template-argument represents a set of overloaded member functions, the matching member function is selected from the set (13.4). § 14.3.2 312

c ISO/IEC

N3337

— For a non-type template-parameter of type pointer to data member, qualiﬁcation conversions (4.4) are applied; if the template-argument is of type std::nullptr_t, the null member pointer conversion (4.11) is applied. [ Example: template struct X { /∗ ... ∗/ }; int ai[10]; X xi; // array to pointer and qualiﬁcation conversions struct Y { /∗ ... ∗/ }; template struct Z { /∗ ... ∗/ }; Y y; Z z; // no conversion, but note extra cv-qualiﬁcation template struct W { /∗ ... ∗/ }; int b[5]; W w; // no conversion void f(char); void f(int); template struct A { /∗ ... ∗/ }; A a; // selects f(int)

— end example ]

14.3.3
1

Template template arguments

[temp.arg.template]

2

A template-argument for a template template-parameter shall be the name of a class template or an alias template, expressed as id-expression. When the template-argument names a class template, only primary class templates are considered when matching the template template argument with the corresponding parameter; partial specializations are not considered even if their parameter lists match that of the template template parameter. Any partial specializations (14.5.5) associated with the primary class template are considered when a specialization based on the template template-parameter is instantiated. If a specialization is not visible at the point of instantiation, and it would have been selected had it been visible, the program is ill-formed; no diagnostic is required. [ Example: template class A { // primary template int x; }; template class A { // partial specialization long x; }; template class C { V y; V z; }; C c; // V within C uses the primary template, // so c.y.x has type int // V within C uses the partial specialization, // so c.z.x has type long

— end example ] [ Example: § 14.3.3 313

c ISO/IEC

N3337

template class A { /∗ ... ∗/ }; template class B { /∗ ... ∗/ }; template class C { /∗ ... ∗/ }; template class X { /∗ ... ∗/ }; template class Y { /∗ ... ∗/ }; X xa; X xb; X xc; Y ya; Y yb; Y yc;
3

// OK // ill-formed: default arguments for the parameters of a template argument are ignored // ill-formed: a template parameter pack does not match a template parameter // OK // OK // OK

— end example ] A template-argument matches a template template-parameter (call it P) when each of the template parameters in the template-parameter-list of the template-argument’s corresponding class template or alias template (call it A) matches the corresponding template parameter in the template-parameter-list of P. When P’s templateparameter-list contains a template parameter pack (14.5.3), the template parameter pack will match zero or more template parameters or template parameter packs in the template-parameter-list of A with the same type and form as the template parameter pack in P (ignoring whether those template parameters are template parameter packs) [ Example: template struct eval; template struct eval { }; template template template template template struct A; struct B; struct C; struct D; struct E; // // // // // OK: matches OK: matches error: C does error: D does error: E does partial specialization of partial specialization of not match TT in partial not match TT in partial not match TT in partial eval eval specialization specialization specialization

eval eA; eval eB; eval eC; eval eD; eval eE;

— end example ]

14.4
1

Type equivalence

[temp.type]

Two template-ids refer to the same class or function if — their template-names, operator-function-ids, or literal-operator-ids refer to the same template and — their corresponding type template-arguments are the same type and — their corresponding non-type template arguments of integral or enumeration type have identical values and — their corresponding non-type template-arguments of pointer type refer to the same external object or function or are both the null pointer value and — their corresponding non-type template-arguments of pointer-to-member type refer to the same class member or are both the null member pointer value and § 14.4 314

c ISO/IEC

N3337

— their corresponding non-type template-arguments of reference type refer to the same external object or function and — their corresponding template template-arguments refer to the same template. [ Example: template class buffer { /∗ ... ∗/ }; buffer x; buffer y;

declares x and y to be of the same type, and template class list { /∗ ... ∗/ }; list x1; list x2; list x3; list x4;

declares x2 and x3 to be of the same type. Their type diﬀers from the types of x1 and x4. template struct X { }; template struct Y { }; template using Z = Y; X y; X z;
2

declares y and z to be of the same type. — end example ] If an expression e involves a template parameter, decltype(e) denotes a unique dependent type. Two such decltype-speciﬁers refer to the same type only if their expressions are equivalent (14.5.6.1). [ Note: however, it may be aliased, e.g., by a typedef-name. — end note ]

14.5
1

Template declarations

[temp.decls]

A template-id, that is, the template-name followed by a template-argument-list shall not be speciﬁed in the declaration of a primary template declaration. [ Example: template class A { }; template void sort(T1 data[I]); // error // error

2

3

— end example ] [ Note: However, this syntax is allowed in class template partial specializations (14.5.5). — end note ] For purposes of name lookup and instantiation, default arguments of function templates and default arguments of member functions of class templates are considered deﬁnitions; each default argument is a separate deﬁnition which is unrelated to the function template deﬁnition or to any other default arguments. Because an alias-declaration cannot declare a template-id, it is not possible to partially or explicitly specialize an alias template.

14.5.1
1

Class templates

[temp.class]

A class template deﬁnes the layout and operations for an unbounded set of related types. [ Example: a single class template List might provide a common deﬁnition for list of int, list of float, and list of pointers to Shapes. — end example ] [ Example: An array class template might be declared like this: template class Array { T* v; int sz; public: explicit Array(int);

§ 14.5.1

315

c ISO/IEC

N3337

T& operator[](int); T& elem(int i) { return v[i]; } };
2

3

The preﬁx template speciﬁes that a template is being declared and that a type-name T will be used in the declaration. In other words, Array is a parameterized type with T as its parameter. — end example ] When a member function, a member class, a member enumeration, a static data member or a member template of a class template is deﬁned outside of the class template deﬁnition, the member deﬁnition is deﬁned as a template deﬁnition in which the template-parameters are those of the class template. The names of the template parameters used in the deﬁnition of the member may be diﬀerent from the template parameter names used in the class template deﬁnition. The template argument list following the class template name in the member deﬁnition shall name the parameters in the same order as the one used in the template parameter list of the member. Each template parameter pack shall be expanded with an ellipsis in the template argument list. [ Example: template struct A { void f1(); void f2(); }; template void A::f1() { } template void A::f2() { } template struct B { void f3(); void f4(); }; template void B::f3() { } template void B::f4() { } // OK // error // OK // error

4

— end example ] In a redeclaration, partial specialization, explicit specialization or explicit instantiation of a class template, the class-key shall agree in kind with the original class template declaration (7.1.6.3). 14.5.1.1 Member functions of class templates [temp.mem.func] A member function of a class template may be deﬁned outside of the class template deﬁnition in which it is declared. [ Example: template class Array { T* v; int sz; public: explicit Array(int); T& operator[](int); T& elem(int i) { return v[i]; } };

1

declares three function templates. The subscript function might be deﬁned like this: template T& Array::operator[](int i) { if (i class A { };

// error

— end example ] — The argument list of the specialization shall not be identical to the implicit argument list of the primary template. — The template parameter list of a specialization shall not contain default template argument values.140 — An argument shall not contain an unexpanded parameter pack. If an argument is a pack expansion (14.5.3), it shall be the last argument in the template argument list. 14.5.5.1
1

Matching of class template partial specializations

[temp.class.spec.match]

When a class template is used in a context that requires an instantiation of the class, it is necessary to determine whether the instantiation is to be generated using the primary template or one of the partial specializations. This is done by matching the template arguments of the class template specialization with the template argument lists of the partial specializations. — If exactly one matching specialization is found, the instantiation is generated from that specialization. — If more than one matching specialization is found, the partial order rules (14.5.5.2) are used to determine whether one of the specializations is more specialized than the others. If none of the specializations is more specialized than all of the other matching specializations, then the use of the class template is ambiguous and the program is ill-formed. — If no matches are found, the instantiation is generated from the primary template.

2

A partial specialization matches a given actual template argument list if the template arguments of the partial specialization can be deduced from the actual template argument list (14.8.2). [ Example:
A A A A A a1; a2; a3; a4; a5; // // // // // uses #1 uses #2, T is int, I is 1 uses #4, T is char uses #5, T1 is int, T2 is char, I is 1 ambiguous: matches #3 and #5

3

4

— end example ] A non-type template argument can also be deduced from the value of an actual template argument of a non-type parameter of the primary template. [ Example: the declaration of a2 above. — end example ] In a type name that refers to a class template specialization, (e.g., A) the argument list shall match the template parameter list of the primary template. The template arguments of a specialization are deduced from the arguments of the primary template. 14.5.5.2 Partial ordering of class template specializations [temp.class.order]

1

For two class template partial specializations, the ﬁrst is at least as specialized as the second if, given the following rewrite to two function templates, the ﬁrst function template is at least as specialized as the second according to the ordering rules for function templates (14.5.6.2): — the ﬁrst function template has the same template parameters as the ﬁrst partial specialization and has a single function parameter whose type is a class template specialization with the template arguments of the ﬁrst partial specialization, and
140) There is no way in which they could be used.

§ 14.5.5.2

325

c ISO/IEC

N3337

— the second function template has the same template parameters as the second partial specialization and has a single function parameter whose type is a class template specialization with the template arguments of the second partial specialization.
2

[ Example: template class X { }; template class X { }; // #1 template class X { }; // #2 template void f(X); template void f(X); // A // B

The partial specialization #2 is more specialized than the partial specialization #1 because the function template B is more specialized than the function template A according to the ordering rules for function templates. — end example ] 14.5.5.3
1

Members of class template specializations

[temp.class.spec.mfunc]

The template parameter list of a member of a class template partial specialization shall match the template parameter list of the class template partial specialization. The template argument list of a member of a class template partial specialization shall match the template argument list of the class template partial specialization. A class template specialization is a distinct template. The members of the class template partial specialization are unrelated to the members of the primary template. Class template partial specialization members that are used in a way that requires a deﬁnition shall be deﬁned; the deﬁnitions of members of the primary template are never used as deﬁnitions for members of a class template partial specialization. An explicit specialization of a member of a class template partial specialization is declared in the same way as an explicit specialization of the primary template. [ Example:
// primary template template struct A { void f(); }; template void A::f() { } // class template partial specialization template struct A { void f(); void g(); void h(); }; // member of class template partial specialization template void A::g() { } // explicit specialization template void A::h() { } int main() { A a0; A a2; a0.f(); a2.g(); a2.h();

// // // //

OK, uses deﬁnition of primary template’s member OK, uses deﬁnition of partial specialization’s member OK, uses deﬁnition of

§ 14.5.5.3

326

c ISO/IEC

N3337

a2.f(); }
2

// explicit specialization’s member // ill-formed, no deﬁnition of f for A // the primary template is not used here

— end example ] If a member template of a class template is partially specialized, the member template partial specializations are member templates of the enclosing class template; if the enclosing class template is instantiated (14.7.1, 14.7.2), a declaration for every member template partial specialization is also instantiated as part of creating the members of the class template specialization. If the primary member template is explicitly specialized for a given (implicit) specialization of the enclosing class template, the partial specializations of the member template are ignored for this specialization of the enclosing class template. If a partial specialization of the member template is explicitly specialized for a given (implicit) specialization of the enclosing class template, the primary member template and its other partial specializations are still considered for this specialization of the enclosing class template. [ Example: template struct A { template struct B {}; template struct B {}; }; template template struct A::B {}; A::B abcip; A::B absip; A::B abci; // uses #2 // uses #3 // uses #1 // #1 // #2

// #3

— end example ]

14.5.6
1

Function templates

[temp.fct]

A function template deﬁnes an unbounded set of related functions. [ Example: a family of sort functions might be declared like this: template class Array { }; template void sort(Array&);

2

— end example ] A function template can be overloaded with other function templates and with normal (non-template) functions. A normal function is not related to a function template (i.e., it is never considered to be a specialization), even if it has the same name and type as a potentially generated function template specialization.141 14.5.6.1 Function template overloading [temp.over.link] It is possible to overload function templates so that two diﬀerent function template specializations have the same type. [ Example:
// ﬁle1.c template void f(T*); void g(int* p) { f(p); // calls f(int*) } // ﬁle2.c template void f(T); void h(int* p) { f(p); // calls f(int*) }

1

2

— end example ] Such specializations are distinct functions and do not violate the one deﬁnition rule (3.2).
141) That is, declarations of non-template functions do not merely guide overload resolution of function template specializations with the same name. If such a non-template function is odr-used (3.2) in a program, it must be deﬁned; it will not be implicitly instantiated using the function template deﬁnition.

§ 14.5.6.1

327

c ISO/IEC

N3337

3

The signature of a function template is deﬁned in 1.3. The names of the template parameters are signiﬁcant only for establishing the relationship between the template parameters and the rest of the signature. [ Note: Two distinct function templates may have identical function return types and function parameter lists, even if overload resolution alone cannot distinguish them. template void f(); template void f(); // OK: overloads the ﬁrst template // distinguishable with an explicit template argument list

4

— end note ] When an expression that references a template parameter is used in the function parameter list or the return type in the declaration of a function template, the expression that references the template parameter is part of the signature of the function template. This is necessary to permit a declaration of a function template in one translation unit to be linked with another declaration of the function template in another translation unit and, conversely, to ensure that function templates that are intended to be distinct are not linked with one another. [ Example: template A f(A, A); template A f(A, A); template A f(A, A); // #1 // same as #1 // diﬀerent from #1

5

— end example ] [ Note: Most expressions that use template parameters use non-type template parameters, but it is possible for an expression to reference a type parameter. For example, a template type parameter can be used in the sizeof operator. — end note ] Two expressions involving template parameters are considered equivalent if two function deﬁnitions containing the expressions would satisfy the one deﬁnition rule (3.2), except that the tokens used to name the template parameters may diﬀer as long as a token used to name a template parameter in one expression is replaced by another token that names the same template parameter in the other expression. [ Example: template void f(A); template void f(A); // #1 // same as #1

6

7

— end example ] Two expressions involving template parameters that are not equivalent are functionally equivalent if, for any given set of template arguments, the evaluation of the expression results in the same value. Two function templates are equivalent if they are declared in the same scope, have the same name, have identical template parameter lists, and have return types and parameter lists that are equivalent using the rules described above to compare expressions involving template parameters. Two function templates are functionally equivalent if they are equivalent except that one or more expressions that involve template parameters in the return types and parameter lists are functionally equivalent using the rules described above to compare expressions involving template parameters. If a program contains declarations of function templates that are functionally equivalent but not equivalent, the program is ill-formed; no diagnostic is required. [ Note: This rule guarantees that equivalent declarations will be linked with one another, while not requiring implementations to use heroic eﬀorts to guarantee that functionally equivalent declarations will be treated as distinct. For example, the last two declarations are functionally equivalent and would cause a program to be ill-formed:
// Guaranteed to be the same template void f(A, A); template void f(A, A); // Guaranteed to be diﬀerent template void f(A, A); template void f(A, A);

§ 14.5.6.1

328

c ISO/IEC

N3337

// Ill-formed, no diagnostic required template void f(A, A); template void f(A, A);

— end note ] 14.5.6.2 Partial ordering of function templates
1

[temp.func.order]

If a function template is overloaded, the use of a function template specialization might be ambiguous because template argument deduction (14.8.2) may associate the function template specialization with more than one function template declaration. Partial ordering of overloaded function template declarations is used in the following contexts to select the function template to which a function template specialization refers: — during overload resolution for a call to a function template specialization (13.3.3); — when the address of a function template specialization is taken; — when a placement operator delete that is a function template specialization is selected to match a placement operator new (3.7.4.2, 5.3.4); — when a friend function declaration (14.5.4), an explicit instantiation (14.7.2) or an explicit specialization (14.7.3) refers to a function template specialization.

2

3

Partial ordering selects which of two function templates is more specialized than the other by transforming each template in turn (see next paragraph) and performing template argument deduction using the function type. The deduction process determines whether one of the templates is more specialized than the other. If so, the more specialized template is the one chosen by the partial ordering process. To produce the transformed template, for each type, non-type, or template template parameter (including template parameter packs (14.5.3) thereof) synthesize a unique type, value, or class template respectively and substitute it for each occurrence of that parameter in the function type of the template. If only one of the function templates is a non-static member, that function template is considered to have a new ﬁrst parameter inserted in its function parameter list. The new parameter is of type “reference to cv A,” where cv are the cv-qualiﬁers of the function template (if any) and A is the class of which the function template is a member. [ Note: This allows a non-static member to be ordered with respect to a nonmember function and for the results to be equivalent to the ordering of two equivalent nonmembers. — end note ] [ Example: struct A { }; template struct B { template int operator*(R&); }; template int operator*(T&, R&);

// #1

// #2

// The declaration of B::operator* is transformed into the equivalent of // template int operator*(B&, R&); // #1a int main() { A a; B b; b * a; }
4

// calls #1a

— end example ] Using the transformed function template’s function type, perform type deduction against the other template as described in 14.8.2.4. [ Example: § 14.5.6.2 329

c ISO/IEC

N3337

template struct A { A(); }; template void f(T); template void f(T*); template void f(const T*); template void g(T); template void g(T&); template void h(const T&); template void h(A&); void m() { const int *p; f(p); float x; g(x); A z; h(z); const A z2; h(z2); }
5

// f(const T*) is more specialized than f(T) or f(T*) // Ambiguous: g(T) or g(T&) // overload resolution selects h(A&) // h(const T&) is called because h(A&) is not callable

— end example ] [ Note: Since partial ordering in a call context considers only parameters for which there are explicit call arguments, some parameters are ignored (namely, function parameter packs, parameters with default arguments, and ellipsis parameters). [ Example: template void void void void f(T); f(T*, int=1); g(T); g(T*, ...); // // // // #1 #2 #3 #4

// calls #2 // calls #4

— end example ] [ Example: template struct A { }; template template< class U> template template void g(T, U ...); // #4

void h() { f(42, (A*)0); f(42); g(42); }

// calls #2 // error: ambiguous // error: ambiguous

— end example ] [ Example: template void f(T, U...); template void f(T); // #1 // #2

§ 14.5.6.2

330

c ISO/IEC

N3337

template void g(T*, U...); template void g(T); void h(int i) { f(&i); g(&i); }

// #3 // #4

// error: ambiguous // OK: calls #3

— end example ] — end note ]

14.5.7
1

Alias templates

[temp.alias]

2

A template-declaration in which the declaration is an alias-declaration (Clause 7) declares the identiﬁer to be a alias template. An alias template is a name for a family of types. The name of the alias template is a template-name. When a template-id refers to the specialization of an alias template, it is equivalent to the associated type obtained by substitution of its template-arguments for the template-parameters in the type-id of the alias template. [ Note: An alias template name is never deduced. — end note ] [ Example: template struct Alloc { /∗ ... ∗/ }; template using Vec = vector; Vec v; // same as vector v; template void process(Vec& v) { /∗ ... ∗/ } template void process(vector& w) { /∗ ... ∗/ } // error: redeﬁnition template void f(TT); f(v); // error: Vec not deduced

template void g(TT); g(v); // OK: TT = vector
3

— end example ] The type-id in an alias template declaration shall not refer to the alias template being declared. The type produced by an alias template specialization shall not directly or indirectly make use of that specialization. [ Example: template struct A; template using B = typename A::U; template struct A { typedef B U; }; B b; // error: instantiation of B uses own type via A::U

— end example ]

14.6
1

Name resolution

[temp.res]

Three kinds of names can be used within a template deﬁnition: — The name of the template itself, and names declared within the template itself. § 14.6 331

c ISO/IEC

N3337

— Names dependent on a template-parameter (14.6.2). — Names from scopes which are visible within the template deﬁnition.
2

A name used in a template declaration or deﬁnition and that is dependent on a template-parameter is assumed not to name a type unless the applicable name lookup ﬁnds a type name or the name is qualiﬁed by the keyword typename. [ Example:
// no B declared here class X; template class Y { class Z; void f() { X* a1; T* a2; Y* a3; Z* a4; typedef typename T::A TA; TA* a5; typename T::A* a6; T::A* a7;

// forward declaration of member class

// // // // // // // // // // // //

declare declare declare declare

pointer pointer pointer pointer

to to to to

X T Y Z

B* a8;

declare pointer to T’s A declare pointer to T’s A T::A is not a type name: multiply T::A by a7; ill-formed, no visible declaration of a7 B is not a type name: multiply B by a8; ill-formed, no visible declarations of B and a8

} };
3

— end example ] When a qualiﬁed-id is intended to refer to a type that is not a member of the current instantiation (14.6.2.1) and its nested-name-speciﬁer refers to a dependent type, it shall be preﬁxed by the keyword typename, forming a typename-speciﬁer. If the qualiﬁed-id in a typename-speciﬁer does not denote a type, the program is illformed. typename-speciﬁer: typename nested-name-speciﬁer identiﬁer typename nested-name-speciﬁer templateopt simple-template-id

4

If a specialization of a template is instantiated for a set of template-arguments such that the qualiﬁed-id preﬁxed by typename does not denote a type, the specialization is ill-formed. The usual qualiﬁed name lookup (3.4.3) is used to ﬁnd the qualiﬁed-id even in the presence of typename. [ Example: struct A { struct X { }; int X; }; struct B { struct X { }; }; template void f(T t) { typename T::X x; } void foo() { A a;

§ 14.6

332

c ISO/IEC

N3337

B b; f(b); f(a); }
5

// OK: T::X refers to B::X // error: T::X refers to the data member A::X not the struct A::X

6

— end example ] A qualiﬁed name used as the name in a mem-initializer-id, a base-speciﬁer, or an elaborated-type-speciﬁer is implicitly assumed to name a type, without the use of the typename keyword. In a nested-name-speciﬁer that immediately contains a nested-name-speciﬁer that depends on a template parameter, the identiﬁer or simple-template-id is implicitly assumed to name a type, without the use of the typename keyword. [ Note: The typename keyword is not permitted by the syntax of these constructs. — end note ] If, for a given set of template arguments, a specialization of a template is instantiated that refers to a qualiﬁed-id that denotes a type, and the qualiﬁed-id refers to a member of an unknown specialization, the qualiﬁed-id shall either be preﬁxed by typename or shall be used in a context in which it implicitly names a type as described above. [ Example: template void f(int i) { T::x * i; // T::x must not be a type } struct Foo { typedef int x; }; struct Bar { static int const x = 5; }; int main() { f(1); f(1); }

// OK // error: Foo::x is a type

7

— end example ] Within the deﬁnition of a class template or within the deﬁnition of a member of a class template following the declarator-id, the keyword typename is not required when referring to the name of a previously declared member of the class template that declares a type. [ Note: such names can be found using unqualiﬁed name lookup (3.4.1), class member lookup (3.4.3.1) into the current instantiation (14.6.2.1), or class member access expression lookup (3.4.5) when the type of the object expression is the current instantiation (14.6.2.2). — end note ] [ Example: template struct A { typedef int B; B b; // OK, no typename required };

8

— end example ] Knowing which names are type names allows the syntax of every template deﬁnition to be checked. No diagnostic shall be issued for a template deﬁnition for which a valid specialization can be generated. If no valid specialization can be generated for a template deﬁnition, and that template is not instantiated, the template deﬁnition is ill-formed, no diagnostic required. If every valid specialization of a variadic template requires an empty template parameter pack, the template deﬁnition is ill-formed, no diagnostic required. If a type used in a non-dependent name is incomplete at the point at which a template is deﬁned but is complete at the point at which an instantiation is done, and if the completeness of that type aﬀects whether or not the program is well-formed or aﬀects the semantics of the program, the program is ill-formed; no § 14.6 333

c ISO/IEC

N3337

diagnostic is required. [ Note: If a template is instantiated, errors will be diagnosed according to the other rules in this Standard. Exactly when these errors are diagnosed is a quality of implementation issue. — end note ] [ Example: int j; template class X { void f(T t, int i, char* p) { t = i; // diagnosed if X::f is instantiated // and the assignment to t is an error p = i; // may be diagnosed even if X::f is // not instantiated p = j; // may be diagnosed even if X::f is // not instantiated } void g(T t) { +; // may be diagnosed even if X::g is // not instantiated } }; template struct A { void operator++(int, T... t); // error: too many parameters }; template union X : T... { }; // error: union with base class template struct A : T..., T... { };// error: duplicate base class
9

— end example ] When looking for the declaration of a name used in a template deﬁnition, the usual lookup rules (3.4.1, 3.4.2) are used for non-dependent names. The lookup of names dependent on the template parameters is postponed until the actual template argument is known (14.6.2). [ Example:
#include using namespace std; template class Set { T* p; int cnt; public: Set(); Set(const Set&); void printall() { for (int i = 0; i ( expression ) reinterpret_cast < type-id > ( expression ) ( type-id ) cast-expression
4

Expressions of the following forms are never type-dependent (because the type of the expression cannot be dependent): literal postﬁx-expression . pseudo-destructor-name postﬁx-expression -> pseudo-destructor-name sizeof unary-expression sizeof ( type-id ) sizeof ... ( identiﬁer ) alignof ( type-id ) typeid ( expression ) typeid ( type-id ) ::opt delete cast-expression ::opt delete [ ] cast-expression throw assignment-expressionopt noexcept ( expression )

5

[ Note: For the standard library macro offsetof, see 18.2. — end note ] A class member access expression (5.2.5) is type-dependent if the expression refers to a member of the current instantiation and the type of the referenced member is dependent, or the class member access expression refers to a member of an unknown specialization. [ Note: In an expression of the form x.y or xp->y the type of the expression is usually the type of the member y of the class of x (or the class pointed to by xp). However, if x or xp refers to a dependent type that is not the current instantiation, the type of y is always dependent. If x or xp refers to a non-dependent type or refers to the current instantiation, the type of y is the type of the class member access expression. — end note ] 14.6.2.3 Value-dependent expressions [temp.dep.constexpr]

1 2

Except as described below, a constant expression is value-dependent if any subexpression is value-dependent. An identiﬁer is value-dependent if it is: — a name declared with a dependent type, — the name of a non-type template parameter, — a constant with literal type and is initialized with an expression that is value-dependent. Expressions of the following form are value-dependent if the unary-expression or expression is typedependent or the type-id is dependent: sizeof unary-expression sizeof ( type-id ) typeid ( expression ) typeid ( type-id ) alignof ( type-id ) noexcept ( expression )

3

[ Note: For the standard library macro offsetof, see 18.2. — end note ] Expressions of the following form are value-dependent if either the type-id or simple-type-speciﬁer is dependent or the expression or cast-expression is value-dependent:

§ 14.6.2.3

342

c ISO/IEC

N3337

simple-type-speciﬁer ( expression-listopt ) static_cast < type-id > ( expression ) const_cast < type-id > ( expression ) reinterpret_cast < type-id > ( expression ) ( type-id ) cast-expression
4

Expressions of the following form are value-dependent: sizeof ... ( identiﬁer )

5

An id-expression is value-dependent if it names a member of an unknown specialization. 14.6.2.4 Dependent template arguments [temp.dep.temp]

1 2

3

4

A type template-argument is dependent if the type it speciﬁes is dependent. A non-type template-argument is dependent if its type is dependent or the constant expression it speciﬁes is value-dependent. Furthermore, a non-type template-argument is dependent if the corresponding non-type template-parameter is of reference or pointer type and the template-argument designates or points to a member of the current instantiation or a member of a dependent type. A template template-argument is dependent if it names a template-parameter or is a qualiﬁed-id that refers to a member of an unknown specialization.

14.6.3
1

Non-dependent names

[temp.nondep]

Non-dependent names used in a template deﬁnition are found using the usual name lookup and bound at the point they are used. [ Example: void g(double); void h(); template class Z { public: void f() { g(1); // calls g(double) h++; // ill-formed: cannot increment function; // this could be diagnosed either here or // at the point of instantiation } }; void g(int); // not in scope at the point of the template // deﬁnition, not considered for the call g(1)

— end example ]

14.6.4
1

Dependent name resolution

[temp.dep.res]

In resolving dependent names, names from the following sources are considered: — Declarations that are visible at the point of deﬁnition of the template. — Declarations from namespaces associated with the types of the function arguments both from the instantiation context (14.6.4.1) and from the deﬁnition context. 14.6.4.1 Point of instantiation [temp.point]

1

For a function template specialization, a member function template specialization, or a specialization for a member function or static data member of a class template, if the specialization is implicitly instantiated because it is referenced from within another template specialization and the context from which it is referenced depends on a template parameter, the point of instantiation of the specialization is the point of instantiation of the enclosing specialization. Otherwise, the point of instantiation for such a specialization immediately follows the namespace scope declaration or deﬁnition that refers to the specialization. § 14.6.4.1 343

c ISO/IEC

N3337

2

3

4

5

6

7

If a function template or member function of a class template is called in a way which uses the deﬁnition of a default argument of that function template or member function, the point of instantiation of the default argument is the point of instantiation of the function template or member function specialization. For a class template specialization, a class member template specialization, or a specialization for a class member of a class template, if the specialization is implicitly instantiated because it is referenced from within another template specialization, if the context from which the specialization is referenced depends on a template parameter, and if the specialization is not instantiated previous to the instantiation of the enclosing template, the point of instantiation is immediately before the point of instantiation of the enclosing template. Otherwise, the point of instantiation for such a specialization immediately precedes the namespace scope declaration or deﬁnition that refers to the specialization. If a virtual function is implicitly instantiated, its point of instantiation is immediately following the point of instantiation of its enclosing class template specialization. An explicit instantiation deﬁnition is an instantiation point for the specialization or specializations speciﬁed by the explicit instantiation. The instantiation context of an expression that depends on the template arguments is the set of declarations with external linkage declared prior to the point of instantiation of the template specialization in the same translation unit. A specialization for a function template, a member function template, or of a member function or static data member of a class template may have multiple points of instantiations within a translation unit, and in addition to the points of instantiation described above, for any such specialization that has a point of instantiation within the translation unit, the end of the translation unit is also considered a point of instantiation. A specialization for a class template has at most one point of instantiation within a translation unit. A specialization for any template may have points of instantiation in multiple translation units. If two diﬀerent points of instantiation give a template specialization diﬀerent meanings according to the one deﬁnition rule (3.2), the program is ill-formed, no diagnostic required. 14.6.4.2 Candidate functions [temp.dep.candidate] For a function call that depends on a template parameter, the candidate functions are found using the usual lookup rules (3.4.1, 3.4.2, 3.4.3) except that: — For the part of the lookup using unqualiﬁed name lookup (3.4.1) or qualiﬁed name lookup (3.4.3), only function declarations from the template deﬁnition context are found. — For the part of the lookup using associated namespaces (3.4.2), only function declarations found in either the template deﬁnition context or the template instantiation context are found. If the function name is an unqualiﬁed-id and the call would be ill-formed or would ﬁnd a better match had the lookup within the associated namespaces considered all the function declarations with external linkage introduced in those namespaces in all translation units, not just considering those declarations found in the template deﬁnition and template instantiation contexts, then the program has undeﬁned behavior.

1

14.6.5
1

Friend names declared within a class template

[temp.inject]

2

Friend classes or functions can be declared within a class template. When a template is instantiated, the names of its friends are treated as if the specialization had been explicitly declared at its point of instantiation. As with non-template classes, the names of namespace-scope friend functions of a class template specialization are not visible during an ordinary lookup unless explicitly declared at namespace scope (11.3). Such names may be found under the rules for associated classes (3.4.2).142 [ Example: template struct number { number(int); friend number gcd(number x, number y) { return 0; };
142) Friend declarations do not introduce new names into any scope, either when the template is declared or when it is instantiated.

§ 14.6.5

344

c ISO/IEC

N3337

}; void g() { number a(3), b(4); a = gcd(a,b); // ﬁnds gcd because number is an // associated class, making gcd visible // in its namespace (global scope) b = gcd(3,4); // ill-formed; gcd is not visible }

— end example ]

14.7
1

Template instantiation and specialization

[temp.spec]

2

3

The act of instantiating a function, a class, a member of a class template or a member template is referred to as template instantiation. A function instantiated from a function template is called an instantiated function. A class instantiated from a class template is called an instantiated class. A member function, a member class, a member enumeration, or a static data member of a class template instantiated from the member deﬁnition of the class template is called, respectively, an instantiated member function, member class, member enumeration, or static data member. A member function instantiated from a member function template is called an instantiated member function. A member class instantiated from a member class template is called an instantiated member class. An explicit specialization may be declared for a function template, a class template, a member of a class template or a member template. An explicit specialization declaration is introduced by template. In an explicit specialization declaration for a class template, a member of a class template or a class member template, the name of the class that is explicitly specialized shall be a simple-template-id. In the explicit specialization declaration for a function template or a member function template, the name of the function or member function explicitly specialized may be a template-id. [ Example: template struct A { static int x; }; template void g(U) { } template struct A { }; template struct A { }; template void g(char) { } template void g(int) { } template int A::x = 0; template struct B { static int x; }; template int B::x = 1; // // // // // // specialize for T == double specialize for T == int specialize for U == char U is deduced from the parameter type specialize for U == int specialize for T == char

// specialize for T == int

4

5

— end example ] An instantiated template specialization can be either implicitly instantiated (14.7.1) for a given argument list or be explicitly instantiated (14.7.2). A specialization is a class, function, or class member that is either instantiated or explicitly specialized (14.7.3). For a given template and a given set of template-arguments, — an explicit instantiation deﬁnition shall appear at most once in a program, — an explicit specialization shall be deﬁned at most once in a program (according to 3.2), and — both an explicit instantiation and a declaration of an explicit specialization shall not appear in a program unless the explicit instantiation follows a declaration of the explicit specialization. § 14.7 345

c ISO/IEC

N3337

6

An implementation is not required to diagnose a violation of this rule. Each class template specialization instantiated from a template has its own copy of any static members. [ Example: template class X { static T s; }; template T X::s = 0; X aa; X bb;

X has a static member s of type int and X has a static member s of type char*. — end example ]

14.7.1
1

Implicit instantiation

[temp.inst]

Unless a class template specialization has been explicitly instantiated (14.7.2) or explicitly specialized (14.7.3), the class template specialization is implicitly instantiated when the specialization is referenced in a context that requires a completely-deﬁned object type or when the completeness of the class type aﬀects the semantics of the program. The implicit instantiation of a class template specialization causes the implicit instantiation of the declarations, but not of the deﬁnitions or default arguments, of the class member functions, member classes, scoped member enumerations, static data members and member templates; and it causes the implicit instantiation of the deﬁnitions of unscoped member enumerations and member anonymous unions. However, for the purpose of determining whether an instantiated redeclaration of a member is valid according to 9.2, a declaration that corresponds to a deﬁnition in the template is considered to be a deﬁnition. [ Example: template struct Outer { template struct template struct Inner { };

// #1a // #1b; OK: valid redeclaration of #1a // #2

// error at #2

2

3

4

Outer::Inner is redeclared at #1b. (It is not deﬁned but noted as being associated with a deﬁnition in Outer.) #2 is also a redeclaration of #1a. It is noted as associated with a deﬁnition, so it is an invalid redeclaration of the same partial specialization. — end example ] Unless a member of a class template or a member template has been explicitly instantiated or explicitly specialized, the specialization of the member is implicitly instantiated when the specialization is referenced in a context that requires the member deﬁnition to exist; in particular, the initialization (and any associated side-eﬀects) of a static data member does not occur unless the static data member is itself used in a way that requires the deﬁnition of the static data member to exist. Unless a function template specialization has been explicitly instantiated or explicitly specialized, the function template specialization is implicitly instantiated when the specialization is referenced in a context that requires a function deﬁnition to exist. Unless a call is to a function template explicit specialization or to a member function of an explicitly specialized class template, a default argument for a function template or a member function of a class template is implicitly instantiated when the function is called in a context that requires the value of the default argument. [ Example: template struct Z { void f(); void g();

§ 14.7.1

346

c ISO/IEC

N3337

}; void h() { Z a; Z* p; Z* q; a.f(); p->g(); }

// instantiation of class Z required // instantiation of class Z not required // instantiation of class Z not required // instantiation of Z::f() required // instantiation of class Z required, and // instantiation of Z::g() required

5

Nothing in this example requires class Z, Z::g(), or Z::f() to be implicitly instantiated. — end example ] A class template specialization is implicitly instantiated if the class type is used in a context that requires a completely-deﬁned object type or if the completeness of the class type might aﬀect the semantics of the program. [ Note: In particular, if the semantics of an expression depend on the member or base class lists of a class template specialization, the class template specialization is implicitly generated. For instance, deleting a pointer to class type depends on whether or not the class declares a destructor, and conversion between pointer to class types depends on the inheritance relationship between the two classes involved. — end note ] [ Example: template class B { /∗ ... ∗/ }; template class D : public B { /∗ ... ∗/ }; void f(void*); void f(B*); void g(D* p, D* pp, D* ppp) { f(p); // instantiation of D required: call f(B*) B* q = pp; // instantiation of D required: // convert D* to B* delete ppp; // instantiation of D required }

6

— end example ] If the overload resolution process can determine the correct function to call without instantiating a class template deﬁnition, it is unspeciﬁed whether that instantiation actually takes place. [ Example: template struct S { operator int(); }; void f(int); void f(S&); void f(S); void g(S& sr) { f(sr); // instantiation of S allowed but not required // instantiation of S allowed but not required };

7

— end example ] If an implicit instantiation of a class template specialization is required and the template is declared but not deﬁned, the program is ill-formed. [ Example: template class X;

§ 14.7.1

347

c ISO/IEC

N3337

X ch;
8

// error: deﬁnition of X required

9

10

11

— end example ] The implicit instantiation of a class template does not cause any static data members of that class to be implicitly instantiated. If a function template or a member function template specialization is used in a way that involves overload resolution, a declaration of the specialization is implicitly instantiated (14.8.3). An implementation shall not implicitly instantiate a function template, a member template, a non-virtual member function, a member class, or a static data member of a class template that does not require instantiation. It is unspeciﬁed whether or not an implementation implicitly instantiates a virtual member function of a class template if the virtual member function would not otherwise be instantiated. The use of a template specialization in a default argument shall not cause the template to be implicitly instantiated except that a class template may be instantiated where its complete type is needed to determine the correctness of the default argument. The use of a default argument in a function call causes specializations in the default argument to be implicitly instantiated. Implicitly instantiated class and function template specializations are placed in the namespace where the template is deﬁned. Implicitly instantiated specializations for members of a class template are placed in the namespace where the enclosing class template is deﬁned. Implicitly instantiated member templates are placed in the namespace where the enclosing class or class template is deﬁned. [ Example: namespace N { template class List { public: T* get(); }; } template class Map { public: N::List lt; V get(K); }; void g(Map& m) { int i = m.get("Nicholas"); }

12

13

a call of lt.get() from Map::get() would place List::get() in the namespace N rather than in the global namespace. — end example ] If a function template f is called in a way that requires a default argument to be used, the dependent names are looked up, the semantics constraints are checked, and the instantiation of any template used in the default argument is done as if the default argument had been an initializer used in a function template specialization with the same scope, the same template parameters and the same access as that of the function template f used at that point. This analysis is called default argument instantiation. The instantiated default argument is then used as the argument of f. Each default argument is instantiated independently. [ Example: template void f(T x, T y = ydef(T()), T z = zdef(T())); class A { };

A zdef(A); void g(A a, A b, A c) {

§ 14.7.1

348

c ISO/IEC

N3337

f(a, b, c); f(a, b); f(a); }
14 15

// no default argument instantiation // default argument z = zdef(T()) instantiated // ill-formed; ydef is not declared

— end example ] [ Note: 14.6.4.1 deﬁnes the point of instantiation of a template specialization. — end note ] There is an implementation-deﬁned quantity that speciﬁes the limit on the total depth of recursive instantiations, which could involve more than one template. The result of an inﬁnite recursion in instantiation is undeﬁned. [ Example: template class X { X* p; // OK X a; // implicit generation of X requires // the implicit instantiation of X which requires // the implicit instantiation of X which ... };

— end example ]

14.7.2
1

Explicit instantiation

[temp.explicit]

2

A class, a function or member template specialization can be explicitly instantiated from its template. A member function, member class or static data member of a class template can be explicitly instantiated from the member deﬁnition associated with its class template. An explicit instantiation of a function template or member function of a class template shall not use the inline or constexpr speciﬁers. The syntax for explicit instantiation is: explicit-instantiation: externopt template declaration

3

There are two forms of explicit instantiation: an explicit instantiation deﬁnition and an explicit instantiation declaration. An explicit instantiation declaration begins with the extern keyword. If the explicit instantiation is for a class or member class, the elaborated-type-speciﬁer in the declaration shall include a simple-template-id. If the explicit instantiation is for a function or member function, the unqualiﬁedid in the declaration shall be either a template-id or, where all template arguments can be deduced, a template-name or operator-function-id. [ Note: The declaration may declare a qualiﬁed-id, in which case the unqualiﬁed-id of the qualiﬁed-id must be a template-id. — end note ] If the explicit instantiation is for a member function, a member class or a static data member of a class template specialization, the name of the class template specialization in the qualiﬁed-id for the member name shall be a simple-template-id. An explicit instantiation shall appear in an enclosing namespace of its template. If the name declared in the explicit instantiation is an unqualiﬁed name, the explicit instantiation shall appear in the namespace where its template is declared or, if that namespace is inline (7.3.1), any namespace from its enclosing namespace set. [ Note: Regarding qualiﬁed names in declarators, see 8.3. — end note ] [ Example: template class Array { void mf(); }; template class Array; template void Array::mf(); template void sort(Array& v) { /∗ ... ∗/ } template void sort(Array&); // argument is deduced here namespace N { template void f(T&) { } } template void N::f(int&);

— end example ]

§ 14.7.2

349

c ISO/IEC

N3337

4

5

6

A declaration of a function template, a member function or static data member of a class template, or a member function template of a class or class template shall precede an explicit instantiation of that entity. A deﬁnition of a class template, a member class of a class template, or a member class template of a class or class template shall precede an explicit instantiation of that entity unless the explicit instantiation is preceded by an explicit specialization of the entity with the same template arguments. If the declaration of the explicit instantiation names an implicitly-declared special member function (Clause 12), the program is ill-formed. For a given set of template arguments, if an explicit instantiation of a template appears after a declaration of an explicit specialization for that template, the explicit instantiation has no eﬀect. Otherwise, for an explicit instantiation deﬁnition the deﬁnition of a function template, a member function template, or a member function or static data member of a class template shall be present in every translation unit in which it is explicitly instantiated. An explicit instantiation of a class or function template specialization is placed in the namespace in which the template is deﬁned. An explicit instantiation for a member of a class template is placed in the namespace where the enclosing class template is deﬁned. An explicit instantiation for a member template is placed in the namespace where the enclosing class or class template is deﬁned. [ Example: namespace N { template class Y { void mf() { } }; } template class Y; // error: class template Y not visible // in the global namespace

using N::Y; template class Y;

// error: explicit instantiation outside of the // namespace of the template // OK: explicit instantiation in namespace N // OK: explicit instantiation // in namespace N

template class N::Y; template void N::Y::mf();

7

— end example ] A trailing template-argument can be left unspeciﬁed in an explicit instantiation of a function template specialization or of a member function template specialization provided it can be deduced from the type of a function parameter (14.8.2). [ Example: template class Array { /∗ ... ∗/ }; template void sort(Array& v) { /∗ ... ∗/ } // instantiate sort(Array&) - template-argument deduced template void sort(Array&);

8

9

10

— end example ] An explicit instantiation that names a class template specialization is also an explicit instantiation of the same kind (declaration or deﬁnition) of each of its members (not including members inherited from base classes) that has not been previously explicitly specialized in the translation unit containing the explicit instantiation, except as described below. [ Note: In addition, it will typically be an explicit instantiation of certain implementation-dependent data about the class. — end note ] An explicit instantiation deﬁnition that names a class template specialization explicitly instantiates the class template specialization and is an explicit instantiation deﬁnition of only those members that have been deﬁned at the point of instantiation. Except for inline functions and class template specializations, explicit instantiation declarations have the eﬀect of suppressing the implicit instantiation of the entity to which they refer. [ Note: The intent is that an § 14.7.2 350

c ISO/IEC

N3337

11

12

13

inline function that is the subject of an explicit instantiation declaration will still be implicitly instantiated when odr-used (3.2) so that the body can be considered for inlining, but that no out-of-line copy of the inline function would be generated in the translation unit. — end note ] If an entity is the subject of both an explicit instantiation declaration and an explicit instantiation deﬁnition in the same translation unit, the deﬁnition shall follow the declaration. An entity that is the subject of an explicit instantiation declaration and that is also used in a way that would otherwise cause an implicit instantiation (14.7.1) in the translation unit shall be the subject of an explicit instantiation deﬁnition somewhere in the program; otherwise the program is ill-formed, no diagnostic required. [ Note: This rule does apply to inline functions even though an explicit instantiation declaration of such an entity has no other normative eﬀect. This is needed to ensure that if the address of an inline function is taken in a translation unit in which the implementation chose to suppress the out-of-line body, another translation unit will supply the body. — end note ] An explicit instantiation declaration shall not name a specialization of a template with internal linkage. The usual access checking rules do not apply to names used to specify explicit instantiations. [ Note: In particular, the template arguments and names used in the function declarator (including parameter types, return types and exception speciﬁcations) may be private types or objects which would normally not be accessible and the template may be a member template or member function which would not normally be accessible. — end note ] An explicit instantiation does not constitute a use of a default argument, so default argument instantiation is not done. [ Example: char* p = 0; template T g(T x = &p) { return x; } template int g(int); // OK even though &p isn’t an int.

— end example ]

14.7.3
1

Explicit specialization

[temp.expl.spec]

An explicit specialization of any of the following: — function template — class template — member function of a class template — static data member of a class template — member class of a class template — member enumeration of a class template — member class template of a class or class template — member function template of a class or class template can be declared by a declaration introduced by template; that is: explicit-specialization: template < > declaration

[ Example: template class stream; template class stream { /∗ ... ∗/ }; template class Array { /∗ ... ∗/ }; template void sort(Array& v) { /∗ ... ∗/ } template void sort(Array&) ;

§ 14.7.3

351

c ISO/IEC

N3337

2

3

Given these declarations, stream will be used as the deﬁnition of streams of chars; other streams will be handled by class template specializations instantiated from the class template. Similarly, sort will be used as the sort function for arguments of type Array; other Array types will be sorted by functions generated from the template. — end example ] An explicit specialization shall be declared in a namespace enclosing the specialized template. An explicit specialization whose declarator-id is not qualiﬁed shall be declared in the nearest enclosing namespace of the template, or, if the namespace is inline (7.3.1), any namespace from its enclosing namespace set. Such a declaration may also be a deﬁnition. If the declaration is not a deﬁnition, the specialization may be deﬁned later (7.3.1.2). A declaration of a function template or class template being explicitly specialized shall precede the declaration of the explicit specialization. [ Note: A declaration, but not a deﬁnition of the template is required. — end note ] The deﬁnition of a class or class template shall precede the declaration of an explicit specialization for a member template of the class or class template. [ Example: template class X { /∗ ... ∗/ }; template class X; template class X { /∗ ... ∗/ }; // OK: X is a template // error: X not a template

4

5

— end example ] A member function, a member function template, a member class, a member enumeration, a member class template, or a static data member of a class template may be explicitly specialized for a class specialization that is implicitly instantiated; in this case, the deﬁnition of the class template shall precede the explicit specialization for the member of the class template. If such an explicit specialization for the member of a class template names an implicitly-declared special member function (Clause 12), the program is ill-formed. A member of an explicitly specialized class is not implicitly instantiated from the member declaration of the class template; instead, the member of the class template specialization shall itself be explicitly deﬁned if its deﬁnition is required. In this case, the deﬁnition of the class template explicit specialization shall be in scope at the point at which the member is deﬁned. The deﬁnition of an explicitly specialized class is unrelated to the deﬁnition of a generated specialization. That is, its members need not have the same names, types, etc. as the members of a generated specialization. Members of an explicitly specialized class template are deﬁned in the same manner as members of normal classes, and not using the template syntax. The same is true when deﬁning a member of an explicitly specialized member class. However, template is used in deﬁning a member of an explicitly specialized member class template that is specialized as a class template. [ Example: template struct A { struct B { }; template struct C { }; }; template struct A { void f(int); }; void h() { A a; a.f(16); }

// A::f must be deﬁned somewhere

// template not used for a member of an // explicitly specialized class template void A::f(int) { /∗ ... ∗/ }

§ 14.7.3

352

c ISO/IEC

N3337

template struct A::B { void f(); }; // template also not used when deﬁning a member of // an explicitly specialized member class void A::B::f() { /∗ ... ∗/ } template template struct A::C { void f(); }; // template is used when deﬁning a member of an explicitly // specialized member class template specialized as a class template template template void A::C::f() { /∗ ... ∗/ } template struct A::B { void f(); }; template void A::B::f() { /∗ ... ∗/ }

// error: template not permitted

template template struct A::C { void f(); }; template void A::C::f() { /∗ ... ∗/ }
6

// error: template required

— end example ] If a template, a member template or a member of a class template is explicitly specialized then that specialization shall be declared before the ﬁrst use of that specialization that would cause an implicit instantiation to take place, in every translation unit in which such a use occurs; no diagnostic is required. If the program does not provide a deﬁnition for an explicit specialization and either the specialization is used in a way that would cause an implicit instantiation to take place or the member is a virtual member function, the program is ill-formed, no diagnostic required. An implicit instantiation is never generated for an explicit specialization that is declared but not deﬁned. [ Example: class String { }; template class Array { /∗ ... ∗/ }; template void sort(Array& v) { /∗ ... ∗/ } void f(Array& v) { sort(v); // use primary template // sort(Array&), T is String } template void sort(Array& v); // error: specialization // after use of primary template template void sort(Array& v); // OK: sort not yet used template struct A { enum E : T; enum class S : T; }; template enum A::E : int { eint }; // OK template enum class A::S : int { sint }; // OK template enum A::E : T { eT }; template enum class A::S : T { sT }; template enum A::E : int { echar }; // ill-formed, A::E was instantiated

§ 14.7.3

353

c ISO/IEC

N3337

// when A was instantiated template enum class A::S : int { schar }; // OK
7

8

— end example ] The placement of explicit specialization declarations for function templates, class templates, member functions of class templates, static data members of class templates, member classes of class templates, member enumerations of class templates, member class templates of class templates, member function templates of class templates, member functions of member templates of class templates, member functions of member templates of non-template classes, member function templates of member classes of class templates, etc., and the placement of partial specialization declarations of class templates, member class templates of non-template classes, member class templates of class templates, etc., can aﬀect whether a program is well-formed according to the relative positioning of the explicit specialization declarations and their points of instantiation in the translation unit as speciﬁed above and below. When writing a specialization, be careful about its location; or to make it compile will be such a trial as to kindle its self-immolation. A template explicit specialization is in the scope of the namespace in which the template was deﬁned. [ Example: namespace N { template class X { /∗ ... ∗/ }; template class Y { /∗ ... ∗/ }; template class X { /∗ ... ∗/ }; template class Y; } template class N::Y { /∗ ... ∗/ }; // OK: specialization // in same namespace // OK: specialization // in same namespace // forward declare intent to // specialize for double

9

— end example ] A simple-template-id that names a class template explicit specialization that has been declared but not deﬁned can be used exactly like the names of other incompletely-deﬁned classes (3.9). [ Example: template class X; template class X; X* p; X x; // X is a class template

// OK: pointer to declared class X // error: object of incomplete class X

10

— end example ] A trailing template-argument can be left unspeciﬁed in the template-id naming an explicit function template specialization provided it can be deduced from the function argument type. [ Example: template class Array { /∗ ... ∗/ }; template void sort(Array& v); // explicit specialization for sort(Array&) // with deduced template-argument of type int template void sort(Array&);

11

12

— end example ] A function with the same name as a template and a type that exactly matches that of a template specialization is not an explicit specialization (14.5.6). An explicit specialization of a function template is inline only if it is declared with the inline speciﬁer or deﬁned as deleted, and independently of whether its function template is inline. [ Example: § 14.7.3 354

c ISO/IEC

N3337

template void f(T) { /∗ ... ∗/ } template inline T g(T) { /∗ ... ∗/ } template inline void f(int) { /∗ ... ∗/ } template int g(int) { /∗ ... ∗/ }
13

// OK: inline // OK: not inline

— end example ] An explicit specialization of a static data member of a template is a deﬁnition if the declaration includes an initializer; otherwise, it is a declaration. [ Note: The deﬁnition of a static data member of a template that requires default initialization must use a braced-init-list: template X Q::x; template X Q::x (); template X Q::x { }; // declaration // error: declares a function // deﬁnition

14

— end note ] A member or a member template of a class template may be explicitly specialized for a given implicit instantiation of the class template, even if the member or member template is deﬁned in the class template deﬁnition. An explicit specialization of a member or member template is speciﬁed using the syntax for explicit specialization. [ Example: template struct A { void f(T); template void g1(T, X1); template void g2(T, X2); void h(T) { } }; // specialization template void A::f(int); // out of class member template deﬁnition template template void A::g1(T, X1) { } // member template specialization template template void A::g1(int, X1); //member template specialization template template void A::g1(int, char); template template void A::g2(int, char);

// X1 deduced as char // X2 speciﬁed as char

// member specialization even if deﬁned in class deﬁnition template void A::h(int) { }
15

— end example ] A member or a member template may be nested within many enclosing class templates. In an explicit specialization for such a member, the member declaration shall be preceded by a template for each enclosing class template that is explicitly specialized. [ Example: template class A { template class B { void mf(); }; }; template template class A::B;

§ 14.7.3

355

c ISO/IEC

N3337

template template void A::B::mf();
16

— end example ] In an explicit specialization declaration for a member of a class template or a member template that appears in namespace scope, the member template and some of its enclosing class templates may remain unspecialized, except that the declaration shall not explicitly specialize a class member template if its enclosing class templates are not explicitly specialized as well. In such explicit specialization declaration, the keyword template followed by a template-parameter-list shall be provided instead of the template preceding the explicit specialization declaration of the member. The types of the template-parameters in the template-parameter-list shall be the same as those speciﬁed in the primary template deﬁnition. [ Example: template class A { template class B { template void mf1(T3); void mf2(); }; }; template template class A::B { template void mf1(T); }; template template template void A::B::mf1(T t) { } template template void A::B::mf2() { } // ill-formed; B is specialized but // its enclosing class template A is not

17

18 19

— end example ] A specialization of a member function template or member class template of a non-specialized class template is itself a template. An explicit specialization declaration shall not be a friend declaration. Default function arguments shall not be speciﬁed in a declaration or a deﬁnition for one of the following explicit specializations: — the explicit specialization of a function template; — the explicit specialization of a member function template; — the explicit specialization of a member function of a class template where the class template specialization to which the member function specialization belongs is implicitly instantiated. [ Note: Default function arguments may be speciﬁed in the declaration or deﬁnition of a member function of a class template specialization that is explicitly specialized. — end note ]

14.8
1

Function template specializations

[temp.fct.spec]

2

A function instantiated from a function template is called a function template specialization; so is an explicit specialization of a function template. Template arguments can be explicitly speciﬁed when naming the function template specialization, deduced from the context (e.g., deduced from the function arguments in a call to the function template specialization, see 14.8.2), or obtained from default template arguments. Each function template specialization instantiated from a template has its own copy of any static variable. [ Example: template void f(T* p) { static T s; };

§ 14.8

356

c ISO/IEC

N3337

void g(int a, char* b) { f(&a); // calls f(int*) f(&b); // calls f(char**) }

Here f(int*) has a static variable s of type int and f(char**) has a static variable s of type char*. — end example ]

14.8.1
1

Explicit template argument speciﬁcation

[temp.arg.explicit]

Template arguments can be speciﬁed when referring to a function template specialization by qualifying the function template name with the list of template-arguments in the same way as template-arguments are speciﬁed in uses of a class template specialization. [ Example: template void sort(Array& v); void f(Array& cv, Array& ci) { sort(cv); // sort(Array&) sort(ci); // sort(Array&) }

and template U convert(V v); void g(double d) { int i = convert(d); char c = convert(d); }
2

// int convert(double) // char convert(double)

— end example ] A template argument list may be speciﬁed when referring to a specialization of a function template — when a function is called, — when the address of a function is taken, when a function initializes a reference to function, or when a pointer to member function is formed, — in an explicit specialization, — in an explicit instantiation, or — in a friend declaration.

3

Trailing template arguments that can be deduced (14.8.2) or obtained from default template-arguments may be omitted from the list of explicit template-arguments. A trailing template parameter pack (14.5.3) not otherwise deduced will be deduced to an empty sequence of template arguments. If all of the template arguments can be deduced, they may all be omitted; in this case, the empty template argument list itself may also be omitted. In contexts where deduction is done and fails, or in contexts where deduction is not done, if a template argument list is speciﬁed and it, along with any default template arguments, identiﬁes a single function template specialization, then the template-id is an lvalue for the function template specialization. [ Example: template X f(Y); template X g(Y); void h() { int i = f(5.6); // Y is deduced to be double int j = f(5.6); // ill-formed: X cannot be deduced f(f); // Y for outer f deduced to be // int (*)(bool) f(f); // ill-formed: f does not denote a

§ 14.8.1

357

c ISO/IEC

N3337

int k = g(5.6); f(g); }
4

// // // //

single function template specialization Y is deduced to be double, Z is deduced to an empty sequence Y for outer f is deduced to be int (*)(bool), Z is deduced to an empty sequence

— end example ] [ Note: An empty template argument list can be used to indicate that a given use refers to a specialization of a function template even when a normal (i.e., non-template) function is visible that would otherwise be used. For example: template int f(T); int f(int); int k = f(1); int l = f(1); // // // // #1 #2 uses #2 uses #1

5

— end note ] Template arguments that are present shall be speciﬁed in the declaration order of their corresponding template-parameters. The template argument list shall not specify more template-arguments than there are corresponding template-parameters unless one of the template-parameters is a template parameter pack. [ Example: template X f(Y,Z); template void f2(); void g() { f("aa",3.0); f("aa",3.0); // Z is deduced to be double f("aa",3.0); // Y is deduced to be const char*, and // Z is deduced to be double f("aa",3.0); // error: X cannot be deduced f2(); // OK }

6

— end example ] Implicit conversions (Clause 4) will be performed on a function argument to convert it to the type of the corresponding function parameter if the parameter type contains no template-parameters that participate in template argument deduction. [ Note: Template parameters do not participate in template argument deduction if they are explicitly speciﬁed. For example, template void f(T); class Complex { Complex(double); }; void g() { f(1); }

// OK, means f(Complex(1))

7

8

— end note ] [ Note: Because the explicit template argument list follows the function template name, and because conversion member function templates and constructor member function templates are called without using a function name, there is no way to provide an explicit template argument list for these function templates. — end note ] [ Note: For simple function names, argument dependent lookup (3.4.2) applies even when the function name is not visible within the scope of the call. This is because the call still has the syntactic form of a function call (3.4.1). But when a function template with explicit template arguments is used, the call does not have § 14.8.1 358

c ISO/IEC

N3337

the correct syntactic form unless there is a function template with that name visible at the point of the call. If no such name is visible, the call is not syntactically well-formed and argument-dependent lookup does not apply. If some such name is visible, argument dependent lookup applies and additional function templates may be found in other namespaces. [ Example: namespace A { struct B { }; template void f(B); } namespace C { template void f(T t); } void g(A::B b) { f(b); // A::f(b); // C::f(b); // // using C::f; f(b); // // }
9

ill-formed: not a function call well-formed ill-formed; argument dependent lookup applies only to unqualiﬁed names well-formed because C::f is visible; then A::f is found by argument dependent lookup

— end example ] — end note ] Template argument deduction can extend the sequence of template arguments corresponding to a template parameter pack, even when the sequence contains explicitly speciﬁed template arguments. [ Example: template void f(Types ... values); void g() { f(0, 0, 0); }

// Types is deduced to the sequence int*, float*, int

— end example ]

14.8.2
1

Template argument deduction

[temp.deduct]

When a function template specialization is referenced, all of the template arguments shall have values. The values can be explicitly speciﬁed or, in some cases, be deduced from the use or obtained from default template-arguments. [ Example: void f(Array& cv, Array& ci) { sort(cv); // calls sort(Array&) sort(ci); // calls sort(Array&) }

and void g(double d) { int i = convert(d); int c = convert(d); }
2

// calls convert(double) // calls convert(double)

— end example ] When an explicit template argument list is speciﬁed, the template arguments must be compatible with the template parameter list and must result in a valid function type as described below; otherwise type deduction fails. Speciﬁcally, the following steps are performed when evaluating an explicitly speciﬁed template argument list with respect to a given function template: — The speciﬁed template arguments must match the template parameters in kind (i.e., type, non-type, template). There must not be more arguments than there are parameters unless at least one parameter § 14.8.2 359

c ISO/IEC

N3337

is a template parameter pack, and there shall be an argument for each non-pack parameter. Otherwise, type deduction fails. — Non-type arguments must match the types of the corresponding non-type template parameters, or must be convertible to the types of the corresponding non-type parameters as speciﬁed in 14.3.2, otherwise type deduction fails. — The speciﬁed template argument values are substituted for the corresponding template parameters as speciﬁed below.
3

After this substitution is performed, the function parameter type adjustments described in 8.3.5 are performed. [ Example: A parameter type of “void ()(const int, int[5])” becomes “void(*)(int,int*)”. — end example ] [ Note: A top-level qualiﬁer in a function parameter declaration does not aﬀect the function type but still aﬀects the type of the function parameter variable within the function. — end note ] [ Example: template void f(T t); template void g(const X x); template void h(Z, Z*); int main() { // #1: function type is f(int), t is non const f(1); // #2: function type is f(int), t is const f(1); // #3: function type is g(int), x is const g(1); // #4: function type is g(int), x is const g(1); // #5: function type is h(int, const int*) h(1,0); }

4

5

— end example ] [ Note: f(1) and f(1) call distinct functions even though both of the functions called have the same function type. — end note ] The resulting substituted and adjusted function type is used as the type of the function template for template argument deduction. If a template argument has not been deduced, its default template argument, if any, is used. [ Example: template void f(T t = 0, U u = 0); void g() { f(1, ’c’); f(1); f(); f(); f(); }

// // // // //

f(1,’c’) f(1,0) error: T cannot be deduced f(0,0) f(0,0)

— end example ] When all template arguments have been deduced or obtained from default template arguments, all uses of template parameters in the template parameter list of the template and the function type are replaced § 14.8.2 360

c ISO/IEC

N3337

6

7

8

with the corresponding deduced or default argument values. If the substitution results in an invalid type, as described above, type deduction fails. At certain points in the template argument deduction process it is necessary to take a function type that makes use of template parameters and replace those template parameters with the corresponding template arguments. This is done at the beginning of template argument deduction when any explicitly speciﬁed template arguments are substituted into the function type, and again at the end of template argument deduction when any template arguments that were deduced or obtained from default arguments are substituted. The substitution occurs in all types and expressions that are used in the function type and in template parameter declarations. The expressions include not only constant expressions such as those that appear in array bounds or as nontype template arguments but also general expressions (i.e., non-constant expressions) inside sizeof, decltype, and other contexts that allow non-constant expressions. [ Note: The equivalent substitution in exception speciﬁcations is done only when the function is instantiated, at which point a program is ill-formed if the substitution results in an invalid type or expression. — end note ] If a substitution results in an invalid type or expression, type deduction fails. An invalid type or expression is one that would be ill-formed if written using the substituted arguments. [ Note: Access checking is done as part of the substitution process. — end note ] Only invalid types and expressions in the immediate context of the function type and its template parameter types can result in a deduction failure. [ Note: The evaluation of the substituted types and expressions can result in side eﬀects such as the instantiation of class template specializations and/or function template specializations, the generation of implicitly-deﬁned functions, etc. Such side eﬀects are not in the “immediate context” and can result in the program being ill-formed. — end note ] [ Example: struct X { }; struct Y { Y(X){} }; template auto f(T t1, T t2) -> decltype(t1 + t2); // #1 X f(Y, Y); // #2 X x1, x2; X x3 = f(x1, x2);

// deduction fails on #1 (cannot add X+X), calls #2

— end example ] [ Note: Type deduction may fail for the following reasons: — Attempting to instantiate a pack expansion containing multiple parameter packs of diﬀering lengths. — Attempting to create an array with an element type that is void, a function type, a reference type, or an abstract class type, or attempting to create an array with a size that is zero or negative. [ Example: template int f(T[5]); int I = f(0); int j = f(0); // invalid array

— end example ] — Attempting to use a type that is not a class or enumeration type in a qualiﬁed name. [ Example: template int f(typename T::B*); int i = f(0);

— end example ]

§ 14.8.2

361

c ISO/IEC

N3337

— Attempting to use a type in a nested-name-speciﬁer of a qualiﬁed-id when that type does not contain the speciﬁed member, or — the speciﬁed member is not a type where a type is required, or — the speciﬁed member is not a template where a template is required, or — the speciﬁed member is not a non-type where a non-type is required. [ Example: template struct X { }; template struct Z { }; template void f(typename T::Y*){} template void g(X*){} template void h(Z*){} struct A {}; struct B { int Y; }; struct C { typedef int N; }; struct D { typedef int TT; }; int main() { // Deduction fails in each of these cases: f(0); // A does not contain a member Y f(0); // The Y member of B is not a type g(0); // The N member of C is not a non-type h(0); // The TT member of D is not a template }

— end example ] — Attempting to create a pointer to reference type. — Attempting to create a reference to void. — Attempting to create “pointer to member of T” when T is not a class type. [ Example: template int f(int T::*); int i = f(0);

— end example ] — Attempting to give an invalid type to a non-type template parameter. [ Example: template template struct X int i0 = struct S {}; int f(S*); {}; f(0);

— end example ] — Attempting to perform an invalid conversion in either a template argument expression, or an expression used in the function declaration. [ Example: template int f(int); int i2 = f(0); // can’t conv 1 to int*

§ 14.8.2

362

c ISO/IEC

N3337

— end example ] — Attempting to create a function type in which a parameter has a type of void, or in which the return type is a function type or array type. — Attempting to create a function type in which a parameter type or the return type is an abstract class type (10.4). — end note ] Except as described above, the use of an invalid value shall not cause type deduction to fail. [ Example: In the following example 1000 is converted to signed char and results in an implementation-deﬁned value as speciﬁed in (4.7). In other words, both templates are considered even though 1000, when converted to signed char, results in an implementation-deﬁned value. template template int i1 = int i2 = int f(int); int f(int); f(0); // ambiguous f(0); // ambiguous

9

— end example ] 14.8.2.1
1

Deducing template arguments from a function call

[temp.deduct.call]

Template argument deduction is done by comparing each function template parameter type (call it P) with the type of the corresponding argument of the call (call it A) as described below. If removing references and cv-qualiﬁers from P gives std::initializer_list for some P and the argument is an initializer list (8.5.4), then deduction is performed instead for each element of the initializer list, taking P as a function template parameter type and the initializer element as its argument. Otherwise, an initializer list argument causes the parameter to be considered a non-deduced context (14.8.2.5). [ Example: template void f(std::initializer_list); f({1,2,3}); // T deduced to int f({1,"asdf"}); // error: T deduced to both int and const char* template void g(T); g({1,2,3}); // error: no argument deduced for T

— end example ] For a function parameter pack that occurs at the end of the parameter-declaration-list, the type A of each remaining argument of the call is compared with the type P of the declarator-id of the function parameter pack. Each comparison deduces template arguments for subsequent positions in the template parameter packs expanded by the function parameter pack. For a function parameter pack that does not occur at the end of the parameter-declaration-list, the type of the parameter pack is a non-deduced context. [ Example: template void f(Types& ...); template void g(T1, Types ...); void h(int x, float& y) { const int z = x; f(x, y, z); // Types is deduced to int, float, const int g(x, y, z); // T1 is deduced to int; Types is deduced to float, int }
2

— end example ] If P is not a reference type: — If A is an array type, the pointer type produced by the array-to-pointer standard conversion (4.2) is used in place of A for type deduction; otherwise, § 14.8.2.1 363

c ISO/IEC

N3337

— If A is a function type, the pointer type produced by the function-to-pointer standard conversion (4.3) is used in place of A for type deduction; otherwise, — If A is a cv-qualiﬁed type, the top level cv-qualiﬁers of A’s type are ignored for type deduction.
3

If P is a cv-qualiﬁed type, the top level cv-qualiﬁers of P’s type are ignored for type deduction. If P is a reference type, the type referred to by P is used for type deduction. If P is an rvalue reference to a cvunqualiﬁed template parameter and the argument is an lvalue, the type “lvalue reference to A” is used in place of A for type deduction. [ Example: template template int i; int n1 = int n2 = int n3 = int f(T&&); int g(const T&&); f(i); f(0); g(i); // // // // calls f(int&) calls f(int&&) error: would call g(const int&&), which would bind an rvalue reference to an lvalue

4

— end example ] In general, the deduction process attempts to ﬁnd template argument values that will make the deduced A identical to A (after the type A is transformed as described above). However, there are three cases that allow a diﬀerence: — If the original P is a reference type, the deduced A (i.e., the type referred to by the reference) can be more cv-qualiﬁed than the transformed A. — The transformed A can be another pointer or pointer to member type that can be converted to the deduced A via a qualiﬁcation conversion (4.4). — If P is a class and P has the form simple-template-id, then the transformed A can be a derived class of the deduced A. Likewise, if P is a pointer to a class of the form simple-template-id, the transformed A can be a pointer to a derived class pointed to by the deduced A. [ Note: as speciﬁed in 14.8.1, implicit conversions will be performed on a function argument to convert it to the type of the corresponding function parameter if the parameter contains no template-parameters that participate in template argument deduction. Such conversions are also allowed, in addition to the ones described in the preceding list. — end note ] These alternatives are considered only if type deduction would otherwise fail. If they yield more than one possible deduced A, the type deduction fails. [ Note: If a template-parameter is not used in any of the function parameters of a function template, or is used only in a non-deduced context, its corresponding template-argument cannot be deduced from a function call and the template-argument must be explicitly speciﬁed. — end note ] When P is a function type, pointer to function type, or pointer to member function type: — If the argument is an overload set containing one or more function templates, the parameter is treated as a non-deduced context. — If the argument is an overload set (not containing function templates), trial argument deduction is attempted using each of the members of the set. If deduction succeeds for only one of the overload set members, that member is used as the argument value for the deduction. If deduction succeeds for more than one member of the overload set the parameter is treated as a non-deduced context.

5

6

7

[ Example:

§ 14.8.2.1

364

c ISO/IEC

N3337

// Only one function of an overload set matches the call so the function // parameter is a deduced context. template int f(T (*p)(T)); int g(int); int g(char); int i = f(g); // calls f(int (*)(int))

— end example ]
8

[ Example:
// Ambiguous deduction causes the second function parameter to be a // non-deduced context. template int f(T, T (*p)(T)); int g(int); char g(char); int i = f(1, g); // calls f(int, int (*)(int))

— end example ]
9

[ Example:
// The overload set contains a template, causing the second function // parameter to be a non-deduced context. template int f(T, T (*p)(T)); char g(char); template T g(T); int i = f(1, g); // calls f(int, int (*)(int))

— end example ] 14.8.2.2
1

Deducing template arguments taking the address of a function template [temp.deduct.funcaddr]

Template arguments can be deduced from the type speciﬁed when taking the address of an overloaded function (13.4). The function template’s function type and the speciﬁed type are used as the types of P and A, and the deduction is done as described in 14.8.2.5. 14.8.2.3 Deducing conversion function template arguments [temp.deduct.conv] Template argument deduction is done by comparing the return type of the conversion function template (call it P; see 8.5, 13.3.1.5, and 13.3.1.6 for the determination of that type) with the type that is required as the result of the conversion (call it A) as described in 14.8.2.5. If P is a reference type, the type referred to by P is used in place of P for type deduction and for any further references to or transformations of P in the remainder of this section. If A is not a reference type: — If P is an array type, the pointer type produced by the array-to-pointer standard conversion (4.2) is used in place of P for type deduction; otherwise, — If P is a function type, the pointer type produced by the function-to-pointer standard conversion (4.3) is used in place of P for type deduction; otherwise, — If P is a cv-qualiﬁed type, the top level cv-qualiﬁers of P’s type are ignored for type deduction.

1

2

3

4

5

If A is a cv-qualiﬁed type, the top level cv-qualiﬁers of A’s type are ignored for type deduction. If A is a reference type, the type referred to by A is used for type deduction. In general, the deduction process attempts to ﬁnd template argument values that will make the deduced A identical to A. However, there are two cases that allow a diﬀerence: § 14.8.2.3 365

c ISO/IEC

N3337

— If the original A is a reference type, A can be more cv-qualiﬁed than the deduced A (i.e., the type referred to by the reference) — The deduced A can be another pointer or pointer to member type that can be converted to A via a qualiﬁcation conversion.
6

7

These alternatives are considered only if type deduction would otherwise fail. If they yield more than one possible deduced A, the type deduction fails. When the deduction process requires a qualiﬁcation conversion for a pointer or pointer to member type as described above, the following process is used to determine the deduced template argument values: If A is a type cv 1,0 “pointer to . . .” cv 1,n−1 “pointer to” cv 1,n T1 and P is a type cv 2,0 “pointer to . . .” cv 2,n−1 “pointer to” cv 2,n T2 The cv-unqualiﬁed T1 and T2 are used as the types of A and P respectively for type deduction. [ Example: struct A { template operator T***(); }; A a; const int * const * const * p1 = a;

// T is deduced as int, not const int

— end example ] 14.8.2.4
1

Deducing template arguments during partial ordering

[temp.deduct.partial]

2

3

Template argument deduction is done by comparing certain types associated with the two function templates being compared. Two sets of types are used to determine the partial ordering. For each of the templates involved there is the original function type and the transformed function type. [ Note: The creation of the transformed type is described in 14.5.6.2. — end note ] The deduction process uses the transformed type as the argument template and the original type of the other template as the parameter template. This process is done twice for each type involved in the partial ordering comparison: once using the transformed template-1 as the argument template and template-2 as the parameter template and again using the transformed template-2 as the argument template and template-1 as the parameter template. The types used to determine the ordering depend on the context in which the partial ordering is done: — In the context of a function call, the types used are those function parameter types for which the function call has arguments.143 — In the context of a call to a conversion operator, the return types of the conversion function templates are used. — In other contexts (14.5.6.2) the function template’s function type is used.

4

5

Each type nominated above from the parameter template and the corresponding type from the argument template are used as the types of P and A. Before the partial ordering is done, certain transformations are performed on the types used for partial ordering: — If P is a reference type, P is replaced by the type referred to.
143) Default arguments are not considered to be arguments in this context; they only become arguments after a function has been selected.

§ 14.8.2.4

366

c ISO/IEC

N3337

— If A is a reference type, A is replaced by the type referred to.
6

7

If both P and A were reference types (before being replaced with the type referred to above), determine which of the two types (if any) is more cv-qualiﬁed than the other; otherwise the types are considered to be equally cv-qualiﬁed for partial ordering purposes. The result of this determination will be used below. Remove any top-level cv-qualiﬁers: — If P is a cv-qualiﬁed type, P is replaced by the cv-unqualiﬁed version of P. — If A is a cv-qualiﬁed type, A is replaced by the cv-unqualiﬁed version of A.

8

If A was transformed from a function parameter pack and P is not a parameter pack, type deduction fails. Otherwise, using the resulting types P and A, the deduction is then done as described in 14.8.2.5. If P is a function parameter pack, the type A of each remaining parameter type of the argument template is compared with the type P of the declarator-id of the function parameter pack. Each comparison deduces template arguments for subsequent positions in the template parameter packs expanded by the function parameter pack. If deduction succeeds for a given type, the type from the argument template is considered to be at least as specialized as the type from the parameter template. [ Example: template void f(Args... args); template void f(T1 a1, Args... args); template void f(T1 a1, T2 a2); f(); f(1, 2, 3); f(1, 2); // // // // // #1 // #2 // #3

calls #1 calls #2 calls #3; non-variadic template #3 is more specialized than the variadic templates #1 and #2

9

— end example ] If, for a given type, deduction succeeds in both directions (i.e., the types are identical after the transformations above) and both P and A were reference types (before being replaced with the type referred to above): — if the type from the argument template was an lvalue reference and the type from the parameter template was not, the argument type is considered to be more specialized than the other; otherwise, — if the type from the argument template is more cv-qualiﬁed than the type from the parameter template (as described above), the argument type is considered to be more specialized than the other; otherwise, — neither type is more specialized than the other.

10

11

If for each type being considered a given template is at least as specialized for all types and more specialized for some set of types and the other template is not more specialized for any types or is not at least as specialized for any types, then the given template is more specialized than the other template. Otherwise, neither template is more specialized than the other. In most cases, all template parameters must have values in order for deduction to succeed, but for partial ordering purposes a template parameter may remain without a value provided it is not used in the types being used for partial ordering. [ Note: A template parameter used in a non-deduced context is considered used. — end note ] [ Example: template T f(int); // #1 template T f(U); // #2 void g() { f(1); // calls #1 }

§ 14.8.2.4

367

c ISO/IEC

N3337

12

— end example ] [ Note: Partial ordering of function templates containing template parameter packs is independent of the number of deduced arguments for those template parameter packs. — end note ] [ Example: template void g(Tuple); // // // // calls calls calls calls #1 #2 #3 #3 // #1 // #2 // #3

g(Tuple()); g(Tuple()); g(Tuple()); g(Tuple());

— end example ] 14.8.2.5
1

Deducing template arguments from a type

[temp.deduct.type]

2

3

Template arguments can be deduced in several diﬀerent contexts, but in each case a type that is speciﬁed in terms of template parameters (call it P) is compared with an actual type (call it A), and an attempt is made to ﬁnd template argument values (a type for a type parameter, a value for a non-type parameter, or a template for a template parameter) that will make P, after substitution of the deduced values (call it the deduced A), compatible with A. In some cases, the deduction is done using a single set of types P and A, in other cases, there will be a set of corresponding types P and A. Type deduction is done independently for each P/A pair, and the deduced template argument values are then combined. If type deduction cannot be done for any P/A pair, or if for any pair the deduction leads to more than one possible set of deduced values, or if diﬀerent pairs yield diﬀerent deduced values, or if any template argument remains neither deduced nor explicitly speciﬁed, template argument deduction fails. A given type P can be composed from a number of other types, templates, and non-type values: — A function type includes the types of each of the function parameters and the return type. — A pointer to member type includes the type of the class object pointed to and the type of the member pointed to. — A type that is a specialization of a class template (e.g., A) includes the types, templates, and non-type values referenced by the template argument list of the specialization. — An array type includes the array element type and the value of the array bound.

4

5

In most cases, the types, templates, and non-type values that are used to compose P participate in template argument deduction. That is, they may be used to determine the value of a template argument, and the value so determined must be consistent with the values determined elsewhere. In certain contexts, however, the value does not participate in type deduction, but instead uses the values of template arguments that were either deduced elsewhere or explicitly speciﬁed. If a template parameter is used only in non-deduced contexts and is not explicitly speciﬁed, template argument deduction fails. The non-deduced contexts are: — The nested-name-speciﬁer of a type that was speciﬁed using a qualiﬁed-id. — A non-type template argument or an array bound in which a subexpression references a template parameter. — A template parameter used in the parameter type of a function parameter that has a default argument that is being used in the call for which argument deduction is being done. § 14.8.2.5 368

c ISO/IEC

N3337

— A function parameter for which argument deduction cannot be done because the associated function argument is a function, or a set of overloaded functions (13.4), and one or more of the following apply: — more than one function matches the function parameter type (resulting in an ambiguous deduction), or — no function matches the function parameter type, or — the set of functions supplied as an argument contains one or more function templates. — A function parameter for which the associated argument is an initializer list (8.5.4) but the parameter does not have std::initializer_list or reference to possibly cv-qualiﬁed std::initializer_list type. [ Example: template void g(T); g({1,2,3}); // error: no argument deduced for T

— end example ] — A function parameter pack that does not occur at the end of the parameter-declaration-clause.
6

7

When a type name is speciﬁed in a way that includes a non-deduced context, all of the types that comprise that type name are also non-deduced. However, a compound type can include both deduced and non-deduced types. [ Example: If a type is speciﬁed as A::B, both T and T2 are non-deduced. Likewise, if a type is speciﬁed as A::X, I, J, and T are non-deduced. If a type is speciﬁed as void f(typename A::B, A), the T in A::B is non-deduced but the T in A is deduced. — end example ] [ Example: Here is an example in which diﬀerent parameter/argument pairs produce inconsistent template argument deductions: template void f(T x, T y) { /∗ ... ∗/ } struct A { /∗ ... ∗/ }; struct B : A { /∗ ... ∗/ }; void g(A a, B b) { f(a,b); // error: T could be A or B f(b,a); // error: T could be A or B f(a,a); // OK: T is A f(b,b); // OK: T is B }

Here is an example where two template arguments are deduced from a single function parameter/argument pair. This can lead to conﬂicts that cause type deduction to fail: template void f( int g1( int, float, float); char g2( int, float, float); int g3( int, char, float); void r() { f(g1); f(g2); f(g3); } T (*)( T, U, U ) );

// OK: T is int and U is float // error: T could be char or int // error: U could be char or float

Here is an example where a qualiﬁcation conversion applies between the argument type on the function call and the deduced template argument type:

§ 14.8.2.5

369

c ISO/IEC

N3337

template void f(const T*) { } int *p; void s() { f(p); // f(const int*) }

Here is an example where the template argument is used to instantiate a derived class type of the corresponding function parameter type: template template struct D2 : public template void t() { D d; D2 d2; f(d); f(d2); }
8

struct B { }; struct D : public B {}; B {}; void f(B&){}

// calls f(B&) // calls f(B&)

— end example ] A template type argument T, a template template argument TT or a template non-type argument i can be deduced if P and A have one of the following forms:
T cv-list T T* T& T&& T[integer-constant ] template-name (where template-name type (T) T() T(T) T type ::* type T::* T T::* T (type ::*)() type (T::*)() type (type ::*)(T) type (T::*)(T) T (type ::*)(T) T (T::*)() T (T::*)(T) type [i] template-name (where template-name TT TT TT

refers to a class template)

refers to a class template)

9

where (T) represents a parameter-type-list where at least one parameter type contains a T, and () represents a parameter-type-list where no parameter type contains a T. Similarly, represents template argument lists where at least one argument contains a T, represents template argument lists where at least one argument contains an i and represents template argument lists where no argument contains a T or an i. If P has a form that contains or , then each argument Pi of the respective template argument list P is compared with the corresponding argument Ai of the corresponding template argument list of A. If § 14.8.2.5 370

c ISO/IEC

N3337

the template argument list of P contains a pack expansion that is not the last template argument, the entire template argument list is a non-deduced context. If Pi is a pack expansion, then the pattern of Pi is compared with each remaining argument in the template argument list of A. Each comparison deduces template arguments for subsequent positions in the template parameter packs expanded by Pi . During partial ordering (14.8.2.4), if Ai was originally a pack expansion: — if P does not contain a template argument corresponding to Ai then Ai is ignored; — otherwise, if Pi is not a pack expansion, template argument deduction fails. [ Example: template class s; // both S; // #1 S { }; // #2 S { }; // #3 #2 and #3 match; #3 is more specialized

template struct A { }; // #1 template struct A { }; // #2 template struct A { }; // #3 template struct A; // selects #2
10

— end example ] Similarly, if P has a form that contains (T), then each parameter type Pi of the respective parameter-typelist of P is compared with the corresponding parameter type Ai of the corresponding parameter-type-list of A. If P and A are function types that originated from deduction when taking the address of a function template (14.8.2.2) or when deducing template arguments from a function declaration (14.8.2.6) and Pi and Ai are parameters of the top-level parameter-type-list of P and A, respectively, Pi is adjusted if it is an rvalue reference to a cv-unqualiﬁed template parameter and Ai is an lvalue reference, in which case the type of Pi is changed to be the template parameter type (i.e., T&& is changed to simply T). [ Note: As a result, when Pi is T&& and Ai is X&, the adjusted Pi will be T, causing T to be deduced as X&. — end note ] [ Example: template void f(T&&); template void f(int&) { } // template void f(int&&) { } // void g(int i) { f(i); // f(0); // } #1 #2 calls f(int&), i.e., #1 calls f(int&&), i.e., #2

— end example ] If the parameter-declaration corresponding to Pi is a function parameter pack, then the type of its declarator-id is compared with each remaining parameter type in the parameter-type-list of A. Each comparison deduces template arguments for subsequent positions in the template parameter packs expanded by the function parameter pack. During partial ordering (14.8.2.4), if Ai was originally a function parameter pack: — if P does not contain a function parameter type corresponding to Ai then Ai is ignored; — otherwise, if Pi is not a function parameter pack, template argument deduction fails. [ Example: template void f(T*, U...) { } template void f(T) { } template void f(int*); // selects #1 // #1 // #2

§ 14.8.2.5

371

c ISO/IEC

N3337

11

— end example ] These forms can be used in the same way as T is for further composition of types. [ Example:
X (*)(char[6])

is of the form template-name (*)(type [i])

which is a variant of type 12

(*)(T)

13 14

where type is X and T is char[6]. — end example ] Template arguments cannot be deduced from function arguments involving constructs other than the ones speciﬁed above. A template type argument cannot be deduced from the type of a non-type template-argument. [ Example: template void f(double a[10][i]); int v[10][20]; f(v); // error: argument for template-parameter T cannot be deduced

15

— end example ] [ Note: Except for reference and pointer types, a major array bound is not part of a function parameter type and cannot be deduced from an argument: template void f1(int a[10][i]); template void f2(int a[i][20]); template void f3(int (&a)[i][20]); void g() { int v[10][20]; f1(v); f1(v); f2(v); f2(v); f3(v); }

// // // // //

OK: i deduced to be 20 OK error: cannot deduce template-argument i OK OK: i deduced to be 10

16

If, in the declaration of a function template with a non-type template parameter, the non-type template parameter is used in a subexpression in the function parameter list, the expression is a non-deduced context as speciﬁed above. [ Example: template class A { /∗ ... ∗/ }; template void g(A); template void f(A, A); void k() { A a1; A a2; g(a1); // error: deduction fails for expression i+1 g(a1); // OK f(a1, a2); // OK }

— end example ] — end note ] [ Note: Template parameters do not participate in template argument deduction if they are used only in non-deduced contexts. For example, template T deduce(typename A::X x, // T is not deduced here

§ 14.8.2.5

372

c ISO/IEC

N3337

T t, typename B::Y y); A a; B b;

// but T is deduced here // i is not deduced here

int x = deduce(a.xm, 62, b.ym); // T is deduced to be int, a.xm must be convertible to // A::X // i is explicitly speciﬁed to be 77, b.ym must be convertible // to B::Y
17

— end note ] If, in the declaration of a function template with a non-type template-parameter, the non-type templateparameter is used in an expression in the function parameter-list and, if the corresponding template-argument is deduced, the template-argument type shall match the type of the template-parameter exactly, except that a template-argument deduced from an array bound may be of any integral type.144 [ Example: template class A { /∗ ... ∗/ }; template void f(A); void k1() { A a; f(a); // error: deduction fails for conversion from int to short f(a); // OK } template class B { }; template void g(B); void k2() { B b; g(b); // OK: cv-qualiﬁers are ignored on template parameter types }

18

— end example ] A template-argument can be deduced from a function, pointer to function, or pointer to member function type. [ Example: template void f(void(*)(T,int)); template void foo(T,int); void g(int,int); void g(char,int); void h(int,int,int); void h(char,int); int m() { f(&g); // error: ambiguous f(&h); // OK: void h(char,int) is a unique match f(&foo); // error: type deduction fails because foo is a template }

19

— end example ] A template type-parameter cannot be deduced from the type of a function default argument. [ Example: template void f(T = 5, T = 7);
144) Although the template-argument corresponding to a template-parameter of type bool may be deduced from an array bound, the resulting value will always be true because the array bound will be non-zero.

§ 14.8.2.5

373

c ISO/IEC

N3337

void g() { f(1); f(); f(); }
20

// OK: call f(1,7) // error: cannot deduce T // OK: call f(5,7)

— end example ] The template-argument corresponding to a template template-parameter is deduced from the type of the template-argument of a class template specialization used in the argument list of a function call. [ Example: template struct A { }; template void f(A) { } template struct B { }; A ab; f(ab); // calls f(A)

21

— end example ] [ Note: Template argument deduction involving parameter packs (14.5.3) can deduce zero or more arguments for each parameter pack. — end note ] [ Example: template struct X { }; template struct X { }; template struct Y { }; template struct Y { }; template int f(void (*)(Types ...)); void g(int, float); X x1; X x2; X x3; Y y1; Y y2; Y y3; int fv = f(g); // // // // // // // uses primary template uses partial specialization; ArgTypes contains float, double uses primary template use primary template; Types is empty uses partial specialization; T is int&, Types contains float, double uses primary template; Types contains int, float, double OK; Types contains int, float

— end example ] 14.8.2.6
1

Deducing template arguments from a function declaration

[temp.deduct.decl]

2

In a declaration whose declarator-id refers to a specialization of a function template, template argument deduction is performed to identify the specialization to which the declaration refers. Speciﬁcally, this is done for explicit instantiations (14.7.2), explicit specializations (14.7.3), and certain friend declarations (14.5.4). This is also done to determine whether a deallocation function template specialization matches a placement operator new (3.7.4.2, 5.3.4). In all these cases, P is the type of the function template being considered as a potential match and A is either the function type from the declaration or the type of the deallocation function that would match the placement operator new as described in 5.3.4. The deduction is done as described in 14.8.2.5. If, for the set of function templates so considered, there is either no match or more than one match after partial ordering has been considered (14.5.6.2), deduction fails and, in the declaration cases, the program is ill-formed.

14.8.3
1

Overload resolution

[temp.over]

A function template can be overloaded either by (non-template) functions of its name or by (other) function templates of the same name. When a call to that name is written (explicitly, or implicitly using the operator notation), template argument deduction (14.8.2) and checking of any explicit template arguments (14.3) are performed for each function template to ﬁnd the template argument values (if any) that can be used with § 14.8.3 374

c ISO/IEC

N3337

that function template to instantiate a function template specialization that can be invoked with the call arguments. For each function template, if the argument deduction and checking succeeds, the templatearguments (deduced and/or explicit) are used to synthesize the declaration of a single function template specialization which is added to the candidate functions set to be used in overload resolution. If, for a given function template, argument deduction fails, no such function is added to the set of candidate functions for that template. The complete set of candidate functions includes all the synthesized declarations and all of the non-template overloaded functions of the same name. The synthesized declarations are treated like any other functions in the remainder of overload resolution, except as explicitly noted in 13.3.3.145 [ Example: template T max(T a, T b) { return a>b?a:b; } void f(int a, int b, char c, char d) { int m1 = max(a,b); // max(int a, int b) char m2 = max(c,d); // max(char a, char b) int m3 = max(a,c); // error: cannot generate max(int,char) }
2

Adding the non-template function int max(int,int);

3

to the example above would resolve the third call, by providing a function that could be called for max(a,c) after using the standard conversion of char to int for c. Here is an example involving conversions on a function argument involved in template-argument deduction: template struct B { /∗ ... ∗/ }; template struct D : public B { /∗ ... ∗/ }; template void f(B&); void g(B& bi, D& di) { f(bi); // f(bi) f(di); // f((B&)di) }

4

Here is an example involving conversions on a function argument not involved in template-parameter deduction: template void f(T*,int); template void f(T,char); void h(int* pi, int i, char c) { f(pi,i); // #1: f(pi,i) f(pi,c); // #2: f(pi,c) f(i,c); f(i,i); } // #2: f(i,c); // #2: f(i,char(i)) // #1 // #2

5

— end example ] Only the signature of a function template specialization is needed to enter the specialization in a set of candidate functions. Therefore only the function template declaration is needed to resolve a call for which a template specialization is a candidate. [ Example:
145) The parameters of function template specializations contain no template parameter types. The set of conversions allowed on deduced arguments is limited, because the argument deduction process produces function templates with parameters that either match the call arguments exactly or diﬀer only in ways that can be bridged by the allowed limited conversions. Nondeduced arguments allow the full range of conversions. Note also that 13.3.3 speciﬁes that a non-template function will be given preference over a template specialization if the two functions are otherwise equally good candidates for an overload match.

§ 14.8.3

375

c ISO/IEC

N3337

template void f(T); void g() { f("Annemarie"); }
6

// declaration

// call of f

The call of f is well-formed even if the template f is only declared and not deﬁned at the point of the call. The program will be ill-formed unless a specialization for f, either implicitly or explicitly generated, is present in some translation unit. — end example ]

§ 14.8.3

376

c ISO/IEC

N3337

15
1

Exception handling

[except]

Exception handling provides a way of transferring control and information from a point in the execution of a thread to an exception handler associated with a point previously passed by the execution. A handler will be invoked only by a throw-expression invoked in code executed in the handler’s try block or in functions called from the handler’s try block . try-block: try compound-statement handler-seq function-try-block: try ctor-initializeropt compound-statement handler-seq handler-seq: handler handler-seqopt handler: catch ( exception-declaration ) compound-statement exception-declaration: attribute-speciﬁer-seqopt type-speciﬁer-seq declarator attribute-speciﬁer-seqopt type-speciﬁer-seq abstract-declaratoropt ... throw-expression: throw assignment-expressionopt

2

3

The optional attribute-speciﬁer-seq in an exception-declaration appertains to the formal parameter of the catch clause (15.3). A try-block is a statement (Clause 6). A throw-expression is of type void. Code that executes a throwexpression is said to “throw an exception;” code that subsequently gets control is called a “handler.” [ Note: Within this Clause “try block” is taken to mean both try-block and function-try-block. — end note ] A goto or switch statement shall not be used to transfer control into a try block or into a handler. [ Example: void f() { goto l1; goto l2; try { goto l1; goto l2; l1: ; } catch (...) { l2: ; goto l1; goto l2; } } // Ill-formed // Ill-formed // OK // Ill-formed

// Ill-formed // OK

— end example ] A goto, break, return, or continue statement can be used to transfer control out of a try block or handler. When this happens, each variable declared in the try block will be destroyed in the context that directly contains its declaration. [ Example: lab: try { T1 t1; try { T2 t2; if (condition )

Exception handling

377

c ISO/IEC

N3337

goto lab; } catch(...) { /∗ handler 2 ∗/ } } catch(...) { /∗ handler 1 ∗/ }

4

Here, executing goto lab; will destroy ﬁrst t2, then t1, assuming the condition does not declare a variable. Any exception raised while destroying t2 will result in executing handler 2 ; any exception raised while destroying t1 will result in executing handler 1. — end example ] A function-try-block associates a handler-seq with the ctor-initializer, if present, and the compound-statement. An exception thrown during the execution of the compound-statement or, for constructors and destructors, during the initialization or destruction, respectively, of the class’s subobjects, transfers control to a handler in a function-try-block in the same way as an exception thrown during the execution of a try-block transfers control to other handlers. [ Example: int f(int); class C { int i; double d; public: C(int, double); }; C::C(int ii, double id) try : i(f(ii)), d(id) { // constructor statements } catch (...) { // handles exceptions thrown from the ctor-initializer // and from the constructor statements }

— end example ]

15.1
1

Throwing an exception

[except.throw]

Throwing an exception transfers control to a handler. An object is passed and the type of that object determines which handlers can catch it. [ Example: throw "Help!";

can be caught by a handler of const char* type: try { // ... } catch(const char* p) { // handle character string exceptions here }

and class Overflow { public: Overflow(char,double,double); }; void f(double x) { throw Overflow(’+’,x,3.45e107); }

can be caught by a handler for exceptions of type Overflow § 15.1 378

c ISO/IEC

N3337

try { f(1.2); } catch(Overflow& oo) { // handle exceptions of type Overflow here }
2

3

4

5

6

7

— end example ] When an exception is thrown, control is transferred to the nearest handler with a matching type (15.3); “nearest” means the handler for which the compound-statement or ctor-initializer following the try keyword was most recently entered by the thread of control and not yet exited. A throw-expression initializes a temporary object, called the exception object, the type of which is determined by removing any top-level cv-qualiﬁers from the static type of the operand of throw and adjusting the type from “array of T” or “function returning T” to “pointer to T” or “pointer to function returning T”, respectively. The temporary is an lvalue and is used to initialize the variable named in the matching handler (15.3). If the type of the exception object would be an incomplete type or a pointer to an incomplete type other than (possibly cv-qualiﬁed) void the program is ill-formed. Except for these restrictions and the restrictions on type matching mentioned in 15.3, the operand of throw is treated exactly as a function argument in a call (5.2.2) or the operand of a return statement. The memory for the exception object is allocated in an unspeciﬁed way, except as noted in 3.7.4.1. If a handler exits by rethrowing, control is passed to another handler for the same exception. The exception object is destroyed after either the last remaining active handler for the exception exits by any means other than rethrowing, or the last object of type std::exception_ptr (18.8.5) that refers to the exception object is destroyed, whichever is later. In the former case, the destruction occurs when the handler exits, immediately after the destruction of the object declared in the exception-declaration in the handler, if any. In the latter case, the destruction occurs before the destructor of std::exception_ptr returns. The implementation may then deallocate the memory for the exception object; any such deallocation is done in an unspeciﬁed way. [ Note: an exception thrown by a throw-expression does not propagate to other threads unless caught, stored, and rethrown using appropriate library functions; see 18.8.5 and 30.6. — end note ] When the thrown object is a class object, the copy/move constructor and the destructor shall be accessible, even if the copy/move operation is elided (12.8). An exception is considered caught when a handler for that exception becomes active (15.3). [ Note: An exception can have active handlers and still be considered uncaught if it is rethrown. — end note ] If the exception handling mechanism, after completing evaluation of the expression to be thrown but before the exception is caught, calls a function that exits via an exception, std::terminate is called (15.5.1). [ Example: struct C { C() { } C(const C&) { throw 0; } }; int main() { try { throw C(); } catch(C) { } }

// calls std::terminate()

8

— end example ] A throw-expression with no operand rethrows the currently handled exception (15.3). The exception is reactivated with the existing temporary; no new temporary exception object is created. The exception is no longer considered to be caught; therefore, the value of std::uncaught_exception() will again be true. [ Example: code that must be executed because of an exception yet cannot completely handle the exception can be written like this: § 15.1 379

c ISO/IEC

N3337

try { // ... } catch (...) { // catch all exceptions // respond (partially) to exception throw; // pass the exception to some // other handler }
9

— end example ] If no exception is presently being handled, executing a throw-expression with no operand calls std:: terminate() (15.5.1).

15.2
1

Constructors and destructors

[except.ctor]

2

3

As control passes from a throw-expression to a handler, destructors are invoked for all automatic objects constructed since the try block was entered. The automatic objects are destroyed in the reverse order of the completion of their construction. An object of any storage duration whose initialization or destruction is terminated by an exception will have destructors executed for all of its fully constructed subobjects (excluding the variant members of a union-like class), that is, for subobjects for which the principal constructor (12.6.2) has completed execution and the destructor has not yet begun execution. Similarly, if the non-delegating constructor for an object has completed execution and a delegating constructor for that object exits with an exception, the object’s destructor will be invoked. If the object was allocated in a new-expression, the matching deallocation function (3.7.4.2, 5.3.4, 12.5), if any, is called to free the storage occupied by the object. The process of calling destructors for automatic objects constructed on the path from a try block to a throw-expression is called “stack unwinding.” If a destructor called during stack unwinding exits with an exception, std::terminate is called (15.5.1). [ Note: So destructors should generally catch exceptions and not let them propagate out of the destructor. — end note ]

15.3
1

Handling an exception

[except.handle]

2

3

The exception-declaration in a handler describes the type(s) of exceptions that can cause that handler to be entered. The exception-declaration shall not denote an incomplete type, an abstract class type, or an rvalue reference type. The exception-declaration shall not denote a pointer or reference to an incomplete type, other than void*, const void*, volatile void*, or const volatile void*. A handler of type “array of T” or “function returning T” is adjusted to be of type “pointer to T” or “pointer to function returning T”, respectively. A handler is a match for an exception object of type E if — The handler is of type cv T or cv T& and E and T are the same type (ignoring the top-level cv-qualiﬁers), or — the handler is of type cv T or cv T& and T is an unambiguous public base class of E, or — the handler is of type cv1 T* cv2 and E is a pointer type that can be converted to the type of the handler by either or both of — a standard pointer conversion (4.10) not involving conversions to pointers to private or protected or ambiguous classes — a qualiﬁcation conversion — the handler is a pointer or pointer to member type and E is std::nullptr_t. [ Note: A throw-expression whose operand is an integral constant expression of integer type that evaluates to zero does not match a handler of pointer or pointer to member type. — end note ] [ Example:

§ 15.3

380

c ISO/IEC

N3337

class class class class

Matherr { /∗ ... ∗/ virtual void vf(); }; Overflow: public Matherr { /∗ ... ∗/ }; Underflow: public Matherr { /∗ ... ∗/ }; Zerodivide: public Matherr { /∗ ... ∗/ };

void f() { try { g(); } catch (Overflow oo) { // ... } catch (Matherr mm) { // ... } }

4

5

6

7

8

9

10

11

12

13

14 15

Here, the Overflow handler will catch exceptions of type Overflow and the Matherr handler will catch exceptions of type Matherr and of all types publicly derived from Matherr including exceptions of type Underflow and Zerodivide. — end example ] The handlers for a try block are tried in order of appearance. That makes it possible to write handlers that can never be executed, for example by placing a handler for a derived class after a handler for a corresponding base class. A ... in a handler’s exception-declaration functions similarly to ... in a function parameter declaration; it speciﬁes a match for any exception. If present, a ... handler shall be the last handler for its try block. If no match is found among the handlers for a try block, the search for a matching handler continues in a dynamically surrounding try block of the same thread. A handler is considered active when initialization is complete for the formal parameter (if any) of the catch clause. [ Note: The stack will have been unwound at that point. — end note ] Also, an implicit handler is considered active when std::terminate() or std::unexpected() is entered due to a throw. A handler is no longer considered active when the catch clause exits or when std::unexpected() exits after being entered due to a throw. The exception with the most recently activated handler that is still active is called the currently handled exception. If no matching handler is found, the function std::terminate() is called; whether or not the stack is unwound before this call to std::terminate() is implementation-deﬁned (15.5.1). Referring to any non-static member or base class of an object in the handler for a function-try-block of a constructor or destructor for that object results in undeﬁned behavior. The fully constructed base classes and members of an object shall be destroyed before entering the handler of a function-try-block of a constructor for that object. Similarly, if a delegating constructor for an object exits with an exception after the non-delegating constructor for that object has completed execution, the object’s destructor shall be executed before entering the handler of a function-try-block of a constructor for that object. The base classes and non-variant members of an object shall be destroyed before entering the handler of a function-try-block of a destructor for that object (12.4). The scope and lifetime of the parameters of a function or constructor extend into the handlers of a functiontry-block. Exceptions thrown in destructors of objects with static storage duration or in constructors of namespacescope objects with static storage duration are not caught by a function-try-block on main(). Exceptions thrown in destructors of objects with thread storage duration or in constructors of namespace-scope objects with thread storage duration are not caught by a function-try-block on the initial function of the thread. If a return statement appears in a handler of the function-try-block of a constructor, the program is ill-formed. The currently handled exception is rethrown if control reaches the end of a handler of the function-try-block of a constructor or destructor. Otherwise, a function returns when control reaches the end of a handler for

§ 15.3

381

c ISO/IEC

N3337

16

17

the function-try-block (6.6.3). Flowing oﬀ the end of a function-try-block is equivalent to a return with no value; this results in undeﬁned behavior in a value-returning function (6.6.3). If the exception-declaration speciﬁes a name, it declares a variable which is copy-initialized (8.5) from the exception object. If the exception-declaration denotes an object type but does not specify a name, a temporary (12.2) is copy-initialized (8.5) from the exception object. The lifetime of the variable or temporary ends when the handler exits, after the destruction of any automatic objects initialized within the handler. When the handler declares a non-constant object, any changes to that object will not aﬀect the temporary object that was initialized by execution of the throw-expression. When the handler declares a reference to a non-constant object, any changes to the referenced object are changes to the temporary object initialized when the throw-expression was executed and will have eﬀect should that object be rethrown.

15.4
1

Exception speciﬁcations

[except.spec]

A function declaration lists exceptions that its function might directly or indirectly throw by using an exception-speciﬁcation as a suﬃx of its declarator. exception-speciﬁcation: dynamic-exception-speciﬁcation noexcept-speciﬁcation dynamic-exception-speciﬁcation: throw ( type-id-listopt ) type-id-list: type-id ...opt type-id-list , type-id ...opt noexcept-speciﬁcation: noexcept ( constant-expression ) noexcept

2

In a noexcept-speciﬁcation, the constant-expression, if supplied, shall be a constant expression (5.19) that is contextually converted to bool (Clause 4). A noexcept-speciﬁcation noexcept is equivalent to noexcept( true). An exception-speciﬁcation shall appear only on a function declarator for a function type, pointer to function type, reference to function type, or pointer to member function type that is the top-level type of a declaration or deﬁnition, or on such a type appearing as a parameter or return type in a function declarator. An exception-speciﬁcation shall not appear in a typedef declaration or alias-declaration. [ Example: void f() throw(int); void (*fp)() throw (int); void g(void pfa() throw(int)); typedef int (*pf)() throw(int); // // // // OK OK OK ill-formed

3

— end example ] A type denoted in an exception-speciﬁcation shall not denote an incomplete type. A type denoted in an exception-speciﬁcation shall not denote a pointer or reference to an incomplete type, other than void*, const void*, volatile void*, or const volatile void*. A type cv T, “array of T”, or “function returning T” denoted in an exception-speciﬁcation is adjusted to type T, “pointer to T”, or “pointer to function returning T”, respectively. Two exception-speciﬁcations are compatible if: — both are non-throwing (see below), regardless of their form, — both have the form noexcept(constant-expression) and the constant-expressions are equivalent, or — both are dynamic-exception-speciﬁcations that have the same set of adjusted types.

4

If any declaration of a function has an exception-speciﬁcation that is not a

Similar Documents

Popular Essays