INTERNATIONAL                                                 ISO/IEC
STANDARD                                                        14882

                                                                          First edition
                                                                          1998-09-01




Programming languages -- C++
Langages de programmation -- C++




      Processed and adopted by ASC X3 and approved by ANSI
      as an American National Standard.

      Date of ANSI Approval: 7/27/98

      Published by American National Standards Institute,
      11 West 42nd Street, New York, New York 10036

      Copyright ©1998 by Information Technology Industry Council
      (ITI). All rights reserved.

      These materials are subject to copyright claims of International
      Standardization Organization (ISO), International
      Electrotechnical Commission (IEC), American National
      Standards Institute (ANSI), and Information Technology
      Industry Council (ITI). Not for resale. No part of this
      publication may be reproduced in any form, including an
      electronic retrieval system, without the prior written permission
      of ITI. All requests pertaining to this standard should be
      submitted to ITI, 1250 Eye Street NW, Washington, DC 20005.

      Printed in the United States of America




BC                                                             Reference number
                                                          ISO/IEC 14882:1998(E)
ISO/IEC 14882:1998(E)




Contents


1 General ...................................................................................................................................................... 1

1.1 Scope ...................................................................................................................................................... 1

1.2 Normative references ............................................................................................................................. 1

1.3 Definitions.............................................................................................................................................. 1
1.3.1 argument.............................................................................................................................................. 1
1.3.2 diagnostic message .............................................................................................................................. 2
1.3.3 dynamic type ....................................................................................................................................... 2
1.3.4 ill-formed program .............................................................................................................................. 2
1.3.5 implementation-defined behavior........................................................................................................ 2
1.3.6 implementation limits.......................................................................................................................... 2
1.3.7 locale-specific behavior....................................................................................................................... 2
1.3.8 multibyte character .............................................................................................................................. 2
1.3.9 parameter............................................................................................................................................. 2
1.3.10 signature ............................................................................................................................................ 2
1.3.11 static type........................................................................................................................................... 2
1.3.12 undefined behavior............................................................................................................................ 2
1.3.13 unspecificed behavior........................................................................................................................ 3
1.3.14 well-formed program......................................................................................................................... 3

1.4 Implementation compliance ................................................................................................................... 3

1.5 Structure of this International Standard.................................................................................................. 4

1.6 Syntax notation....................................................................................................................................... 4

1.7 The C++ memory model ........................................................................................................................ 4

1.8 The C++ object model..............................................................................................................................

1.9 Program execution.................................................................................................................................. 5




© ISO/IEC 1998
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any
means, electronic or mechanical, including photocopying and microfilm, without permission in writing from the publisher.
    ISO/IEC Copyright Office · Case postale 56 · CH-1211 Genève 20 · Switzerland
Printed in Switzerland



ii
© ISO/IEC                                                                                                                 ISO/IEC 14882:1998(E)




1.10 Acknowledgments .................................................................................................................................8

2 Lexical conventions ....................................................................................................................................9

2.1 Phases of translation ................................................................................................................................9

2.2 Character sets .........................................................................................................................................10

2.3 Trigraph sequences ................................................................................................................................11

2.4 Preprocessing tokens .............................................................................................................................11

2.5 Alternative tokens ..................................................................................................................................12

2.6 Tokens....................................................................................................................................................12

2.7     Comments ..............................................................................................................................................12

2.8 Header names .........................................................................................................................................13

2.9 Preprocessing numbers ..........................................................................................................................13

2.10 Identifiers .............................................................................................................................................13

2.11 Keywords .............................................................................................................................................14

2.12 Operators and punctuators ...................................................................................................................15

2.13 Literals .................................................................................................................................................15
2.13.1 Integer literals ...................................................................................................................................15
2.13.2 Character literals ...............................................................................................................................16
2.13.3 Floating literals .................................................................................................................................18
2.13.4 String literals .....................................................................................................................................19
2.13.5 Boolean literals .................................................................................................................................19

3 Basic concepts ..........................................................................................................................................21

3.1 Declarations and definitions ..................................................................................................................21

3.2 One definition rule .................................................................................................................................22

3.3 Declarative regions and scopes ..............................................................................................................24
3.3.1 Point of declaration .............................................................................................................................25
3.3.2 Local scope .........................................................................................................................................26
3.3.3 Function prototype scope ....................................................................................................................26
3.3.4 Function scope ....................................................................................................................................27
3.3.5 Namespace scope ................................................................................................................................27
3.3.6 Class scope..........................................................................................................................................27
3.3.7 Name hiding........................................................................................................................................28

3.4 Name lookup ..........................................................................................................................................29
3.4.1 Unqualified name lookup ...................................................................................................................29
3.4.2 Argument-dependent name lookup .....................................................................................................32
3.4.3 Qualified name lookup .......................................................................................................................33



                                                                                                                                                             iii
ISO/IEC 14882:1998(E)                                                                                                                           © ISO/IEC




3.4.3.1 Class members .................................................................................................................................35
3.4.3.2 Namespace members .......................................................................................................................35
3.4.4 Elaborated type specifiers ...................................................................................................................38
3.4.5 Class member access ..........................................................................................................................39
3.4.6 Using-directives and namespace aliases .............................................................................................40

3.5 Program and linkage ..............................................................................................................................41

3.6 Start and termination..............................................................................................................................43
3.6.1 Main function......................................................................................................................................43
3.6.2 Initialization of non-local objects .......................................................................................................44
3.6.3 Termination.........................................................................................................................................45

3.7 Storage duration .....................................................................................................................................45
3.7.1 Static storage duration ........................................................................................................................46
3.7.2 Automatic storage duration.................................................................................................................46
3.7.3 Dynamic storage duration ...................................................................................................................46
3.7.3.1 Allocation functions.........................................................................................................................47
3.7.3.2 Deallocation functions .....................................................................................................................47
3.7.4 Duration of sub-objects.......................................................................................................................48

3.8 Object Lifetime ......................................................................................................................................48

3.9 Types......................................................................................................................................................51
3.9.1 Fundamental types ..............................................................................................................................53
3.9.2 Compound types .................................................................................................................................54
3.9.3 CV-qualifiers ......................................................................................................................................55

3.10 Lvalues and rvalues .............................................................................................................................55

4 Standard conversions ................................................................................................................................57

4.1 Lvalue-to-rvalue conversion ..................................................................................................................57

4.2 Array-to-pointer conversion ..................................................................................................................58

4.3 Function-to-pointer conversion .............................................................................................................58

4.4 Qualification conversions ......................................................................................................................58

4.5 Integral promotions ................................................................................................................................59

4.6     Floating point promotion .......................................................................................................................59

4.7 Integral conversions ...............................................................................................................................60

4.8     Floating point conversions .....................................................................................................................60

4.9 Floating-integral conversions ................................................................................................................60

4.10      Pointer conversions ..............................................................................................................................60

4.11      Pointer to member conversions ...........................................................................................................61




iv
© ISO/IEC                                                                                                                  ISO/IEC 14882:1998(E)




4.12 Boolean conversions ............................................................................................................................61

5 Expressions ...............................................................................................................................................63

5.1 Primary expressions ...............................................................................................................................64

5.2 Postfix expressions ................................................................................................................................66
5.2.1 Subscripting ........................................................................................................................................66
5.2.2 Function call .......................................................................................................................................66
5.2.3 Explicit type conversion (functional notation) ...................................................................................68
5.2.4 Pseudo destructor call .........................................................................................................................68
5.2.5 Class member access ..........................................................................................................................68
5.2.6 Increment and decrement ....................................................................................................................69
5.2.7 Dynamic cast ......................................................................................................................................70
5.2.8 Type identification ..............................................................................................................................71
5.2.9 Static cast ............................................................................................................................................72
5.2.10 Reinterpret cast .................................................................................................................................73
5.2.11 Const cast ..........................................................................................................................................74

5.3 Unary expressions ..................................................................................................................................76
5.3.1 Unary operators...................................................................................................................................76
5.3.2 Increment and decrement ....................................................................................................................77
5.3.3 Sizeof ..................................................................................................................................................77
5.3.4 New .....................................................................................................................................................78
5.3.5 Delete ..................................................................................................................................................81

5.4     Explicit type conversion (cast notation) ................................................................................................82

5.5 Pointer-to-member operators .................................................................................................................83

5.6     Multiplicative operators .........................................................................................................................83

5.7     Additive operators .................................................................................................................................84

5.8     Shift operators ........................................................................................................................................85

5.9 Relational operators ...............................................................................................................................85

5.10      Equality operators ................................................................................................................................86

5.11      Bitwise AND operator ..........................................................................................................................87

5.12      Bitwise exclusive OR operator .............................................................................................................87

5.13      Bitwise inclusive OR operator .............................................................................................................87

5.14 Logical AND operator ..........................................................................................................................87

5.15 Logical OR operator .............................................................................................................................88

5.16      Conditional operator ............................................................................................................................88

5.17      Assignment operators ..........................................................................................................................89




                                                                                                                                                               v
ISO/IEC 14882:1998(E)                                                                                                                             © ISO/IEC




5.18      Comma operator ..................................................................................................................................90

5.19      Constant expressions ...........................................................................................................................90

6     Statements .................................................................................................................................................93

6.1 Labeled statement ..................................................................................................................................93

6.2 Expression statement .............................................................................................................................93

6.3     Compound statement or block ...............................................................................................................93

6.4 Selection statements...............................................................................................................................94
6.4.1 The if statement ................................................................................................................................95
6.4.2 The switch statement ......................................................................................................................95

6.5 Iteration statements ................................................................................................................................95
6.5.1 The while statement .........................................................................................................................96
6.5.2 The do statement ................................................................................................................................96
6.5.3 The for statement..............................................................................................................................97

6.6 Jump statements .....................................................................................................................................97
6.6.1 The break statement .........................................................................................................................97
6.6.2 The continue statement..................................................................................................................98
6.6.3 The return statement ......................................................................................................................98
6.6.4 The goto statement ...........................................................................................................................98

6.7 Declaration statement ............................................................................................................................98

6.8     Ambiguity resolution .............................................................................................................................99

7 Declarations ............................................................................................................................................101

7.1 Specifiers .............................................................................................................................................102
7.1.1 Storage class specifiers .....................................................................................................................103
7.1.2 Function specifiers ............................................................................................................................104
7.1.3 The typedef specifier....................................................................................................................105
7.1.4 The friend specifier ......................................................................................................................106
7.1.5 Type specifiers ..................................................................................................................................106
7.1.5.1 The cv-qualifiers............................................................................................................................107
7.1.5.2 Simple type specifiers ....................................................................................................................108
7.1.5.3 Elaborated type specifiers ..............................................................................................................109

7.2 Enumeration declarations ....................................................................................................................110

7.3 Namespaces .........................................................................................................................................112
7.3.1 Namespace definition .......................................................................................................................112
7.3.1.1 Unnamed namespaces ....................................................................................................................113
7.3.1.2 Namespace member definitions .....................................................................................................113
7.3.2 Namespace alias ................................................................................................................................115
7.3.3 The using declaration ....................................................................................................................115
7.3.4 Using directive ..................................................................................................................................120

7.4 The asm declaration ............................................................................................................................123



vi
© ISO/IEC                                                                                                                     ISO/IEC 14882:1998(E)




7.5 Linkage specifications .........................................................................................................................123

8 Declarators ..............................................................................................................................................127

8.1 Type names ..........................................................................................................................................128

8.2     Ambiguity resolution ...........................................................................................................................128

8.3 Meaning of declarators ........................................................................................................................130
8.3.1 Pointers .............................................................................................................................................131
8.3.2 References .........................................................................................................................................132
8.3.3 Pointers to members .........................................................................................................................133
8.3.4 Arrays ...............................................................................................................................................133
8.3.5 Functions...........................................................................................................................................135
8.3.6 Default arguments .............................................................................................................................137

8.4     Function definitions .............................................................................................................................140

8.5 Initializers ............................................................................................................................................141
8.5.1 Aggregates ........................................................................................................................................144
8.5.2 Character arrays ................................................................................................................................146
8.5.3 References .........................................................................................................................................147

9     Classes ....................................................................................................................................................149

9.1     Class names .........................................................................................................................................149

9.2     Class members .....................................................................................................................................151

9.3 Member functions ................................................................................................................................153
9.3.1 Nonstatic member functions .............................................................................................................154
9.3.2 The this pointer .............................................................................................................................155

9.4 Static members.....................................................................................................................................156
9.4.1 Static member functions ...................................................................................................................157
9.4.2 Static data members ..........................................................................................................................157

9.5     Unions ..................................................................................................................................................158

9.6     Bit-fields ..............................................................................................................................................159

9.7 Nested class declarations .....................................................................................................................160

9.8 Local class declarations .......................................................................................................................161

9.9 Nested type names ...............................................................................................................................161

10 Derived classes .....................................................................................................................................163

10.1      Multiple base classes .........................................................................................................................164

10.2 Member name lookup ........................................................................................................................165

10.3 Virtual functions ................................................................................................................................168



                                                                                                                                                                vii
ISO/IEC 14882:1998(E)                                                                                                                             © ISO/IEC




10.4 Abstract classes ..................................................................................................................................172

11 Member access control .........................................................................................................................175

11.1 Access specifiers ................................................................................................................................176

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

11.3 Access declarations ............................................................................................................................178

11.4      Friends ...............................................................................................................................................179

11.5 Protected member access ...................................................................................................................182

11.6 Access to virtual functions.................................................................................................................183

11.7      Multiple access ..................................................................................................................................183

11.8 Nested classes ....................................................................................................................................184

12 Special member functions.....................................................................................................................185

12.1 Constructors .......................................................................................................................................185

12.2 Temporary objects .............................................................................................................................187

12.3 Conversions .......................................................................................................................................188
12.3.1 Conversion by constructor ..............................................................................................................189
12.3.2 Conversion functions ......................................................................................................................190

12.4 Destructors .........................................................................................................................................191

12.5 Free store ...........................................................................................................................................194

12.6 Initialization .......................................................................................................................................195
12.6.1 Explicit initialization ......................................................................................................................196
12.6.2 Initializing bases and members .......................................................................................................197

12.7      Construction and destruction .............................................................................................................200

12.8      Copying class objects ........................................................................................................................203

13 Overloading ..........................................................................................................................................209

13.1 Overloadable declarations..................................................................................................................209

13.2 Declaration matching .........................................................................................................................211

13.3 Overload resolution ...........................................................................................................................212
13.3.1 Candidate functions and argument lists ..........................................................................................213
13.3.1.1 Function call syntax .....................................................................................................................214
13.3.1.1.1 Call to named function..............................................................................................................214
13.3.1.1.2 Call to object of class type ........................................................................................................215
13.3.1.2 Operators in expressions ..............................................................................................................216



viii
© ISO/IEC                                                                                                                ISO/IEC 14882:1998(E)




13.3.1.3 Initialization by constructor .........................................................................................................218
13.3.1.4 Copy-initialization of class by user-defined conversion..............................................................218
13.3.1.5 Initialization by conversion function ...........................................................................................218
13.3.1.6 Initialization by conversion function for direct reference binding ..............................................219
13.3.2 Viable functions ..............................................................................................................................219
13.3.3 Best Viable Function ......................................................................................................................219
13.3.3.1 Implicit conversion sequences .....................................................................................................221
13.3.3.1.1 Standard conversion sequences ................................................................................................222
13.3.3.1.2 User-defined conversion sequences ..........................................................................................223
13.3.3.1.3 Ellipsis conversion sequences...................................................................................................223
13.3.3.1.4 Reference binding .....................................................................................................................224
13.3.3.2 Ranking implicit conversion sequences.......................................................................................224

13.4 Address of overloaded function .........................................................................................................226

13.5 Overloaded operators .........................................................................................................................227
13.5.1 Unary operators...............................................................................................................................228
13.5.2 Binary operators..............................................................................................................................229
13.5.3 Assignment .....................................................................................................................................229
13.5.4 Function call ...................................................................................................................................229
13.5.5 Subscripting ....................................................................................................................................230
13.5.6 Class member access ......................................................................................................................230
13.5.7 Increment and decrement ................................................................................................................230

13.6      Built-in operators ...............................................................................................................................231

14 Templates ..............................................................................................................................................235

14.1 Template parameters ..........................................................................................................................236

14.2 Names of template specializations .....................................................................................................238

14.3 Template arguments...........................................................................................................................239
14.3.1 Template type arguments ................................................................................................................241
14.3.2 Template non-type arguments ........................................................................................................242
14.3.3 Template template arguments .........................................................................................................243

14.4 Type equivalence ...............................................................................................................................244

14.5 Template declarations ........................................................................................................................244
14.5.1 Class templates ...............................................................................................................................244
14.5.1.1 Member functions of class templates...........................................................................................245
14.5.1.2 Member classes of class templates ..............................................................................................246
14.5.1.3 Static data members of class templates........................................................................................246
14.5.2 Member templates ..........................................................................................................................246
14.5.3 Friends ............................................................................................................................................248
14.5.4 Class template partial specializations .............................................................................................250
14.5.4.1 Matching of class template partial specializations ......................................................................252
14.5.4.2 Partial ordering of class template specializations ........................................................................252
14.5.4.3 Members of class template specializations ..................................................................................253
14.5.5 Function templates ..........................................................................................................................254
14.5.5.1 Function template overloading ....................................................................................................254
14.5.5.2 Partial ordering of function templates .........................................................................................256




                                                                                                                                                           ix
ISO/IEC 14882:1998(E)                                                                                                                     © ISO/IEC




14.6 Name resolution .................................................................................................................................257
14.6.1 Locally declared names ..................................................................................................................260
14.6.2 Dependent names ............................................................................................................................262
14.6.2.1 Dependent types...........................................................................................................................263
14.6.2.2 Type-dependent expressions ........................................................................................................263
14.6.2.3 Value-dependent expressions ......................................................................................................264
14.6.2.4 Dependent template arguments ....................................................................................................264
14.6.3 Non-dependent names.....................................................................................................................265
14.6.4 Dependent name resolution ............................................................................................................265
14.6.4.1 Point of instantiation ....................................................................................................................265
14.6.4.2 Candidate functions .....................................................................................................................266
14.6.5 Friend names declared within a class template ...............................................................................266

14.7 Template instantiation and specialization ..........................................................................................267
14.7.1 Implicit instantiation .......................................................................................................................268
14.7.2 Explicit instantiation .......................................................................................................................271
14.7.3 Explicit specialization .....................................................................................................................272

14.8 Function template specializations ......................................................................................................277
14.8.1 Explicit template argument specification .......................................................................................278
14.8.2 Template argument deduction ........................................................................................................280
14.8.2.1 Deducing template arguments from a function call .....................................................................282
14.8.2.2 Deducing template arguments taking the address of a function template ...................................283
14.8.2.3 Deducing conversion function template arguments.....................................................................283
14.8.2.4 Deducing template arguments from a type ..................................................................................283
14.8.3 Overload resolution ........................................................................................................................288

15 Exception handling ...............................................................................................................................291

15.1 Throwing an exception ......................................................................................................................292

15.2 Constructors and destructors..............................................................................................................294

15.3 Handling an exception .......................................................................................................................294

15.4 Exception specifications ....................................................................................................................296

15.5 Special functions ................................................................................................................................298
15.5.1 The terminate() function ........................................................................................................298
15.5.2 The unexpected() function ......................................................................................................299
15.5.3 The uncaught_exception() function ...................................................................................299

15.6 Exceptions and access ........................................................................................................................299

16 Preprocessing directives .......................................................................................................................301

16.1     Conditional inclusion .........................................................................................................................302

16.2 Source file inclusion ..........................................................................................................................303

16.3 Macro replacement ............................................................................................................................304
16.3.1 Argument substitution ....................................................................................................................305
16.3.2 The # operator ................................................................................................................................305
16.3.3 The ## operator ..............................................................................................................................306



x
© ISO/IEC                                                                                                                 ISO/IEC 14882:1998(E)




16.3.4 Rescanning and further replacement...............................................................................................306
16.3.5 Scope of macro definitions .............................................................................................................306

16.4 Line control ........................................................................................................................................308

16.5 Error directive ....................................................................................................................................308

16.6 Pragma directive ................................................................................................................................308

16.7      Null directive .....................................................................................................................................308

16.8 Predefined macro names ....................................................................................................................309

17 Library introduction ..............................................................................................................................311

17.1 Definitions .........................................................................................................................................311
17.1.1 arbitrary-positional stream ..............................................................................................................311
17.1.2 character ..........................................................................................................................................311
17.1.3 character container type ..................................................................................................................311
17.1.4 comparison function .......................................................................................................................311
17.1.5 component.......................................................................................................................................312
17.1.6 default behavior ..............................................................................................................................312
17.1.7 handler function ..............................................................................................................................312
17.1.8 iostream class templates .................................................................................................................312
17.1.9 modifier function ............................................................................................................................312
17.1.10 object state ....................................................................................................................................312
17.1.11 narrow-oriented iostream classes ..................................................................................................312
17.1.12 NTCTS ..........................................................................................................................................312
17.1.13 observer function ..........................................................................................................................312
17.1.14 replacement function.....................................................................................................................312
17.1.15 required behavior ..........................................................................................................................312
17.1.16 repositional stream ........................................................................................................................313
17.1.17 reserved function...........................................................................................................................313
17.1.18 traits class......................................................................................................................................313
17.1.19 wide-oriented iostream classes .....................................................................................................313

17.2      Additional definitions ........................................................................................................................313

17.3 Method of description (Informative) .................................................................................................313
17.3.1 Structure of each subclause.............................................................................................................313
17.3.1.1 Summary ......................................................................................................................................314
17.3.1.2 Requirements ...............................................................................................................................314
17.3.1.3 Specifications ...............................................................................................................................314
17.3.1.4 C Library ......................................................................................................................................315
17.3.2 Other conventions ...........................................................................................................................315
17.3.2.1 Type descriptions .........................................................................................................................315
17.3.2.1.1 Enumerated types......................................................................................................................316
17.3.2.1.2 Bitmask types............................................................................................................................316
17.3.2.1.3 Character sequences ..................................................................................................................317
17.3.2.1.3.1 Byte strings ............................................................................................................................317
17.3.2.1.3.2 Multibyte strings ....................................................................................................................318
17.3.2.1.3.3 Wide-character sequences ......................................................................................................318
17.3.2.2 Functions within classes ..............................................................................................................318
17.3.2.3 Private members ..........................................................................................................................318



                                                                                                                                                             xi
ISO/IEC 14882:1998(E)                                                                                                                         © ISO/IEC




17.4 Library-wide requirements ................................................................................................................318
17.4.1 Library contents and organization ..................................................................................................319
17.4.1.1 Library contents ...........................................................................................................................319
17.4.1.2 Headers ........................................................................................................................................319
17.4.1.3 Freestanding implementations .....................................................................................................320
17.4.2 Using the library .............................................................................................................................320
17.4.2.1 Headers ........................................................................................................................................320
17.4.2.2 Linkage ........................................................................................................................................321
17.4.3 Constraints on programs .................................................................................................................321
17.4.3.1 Reserved names ...........................................................................................................................321
17.4.3.1.1 Macro names .............................................................................................................................321
17.4.3.1.2 Global names ............................................................................................................................321
17.4.3.1.3 External linkage ........................................................................................................................322
17.4.3.1.4 Types.........................................................................................................................................322
17.4.3.2 Headers ........................................................................................................................................322
17.4.3.3 Derived classes ............................................................................................................................322
17.4.3.4 Replacement functions.................................................................................................................322
17.4.3.5 Handler functions.........................................................................................................................323
17.4.3.6 Other functions ............................................................................................................................323
17.4.3.7 Function arguments .....................................................................................................................324
17.4.3.8 Required paragraph ......................................................................................................................324
17.4.4 Conforming implementations .........................................................................................................324
17.4.4.1 Headers ........................................................................................................................................324
17.4.4.2 Restrictions on macro definitions ................................................................................................324
17.4.4.3 Global functions...........................................................................................................................324
17.4.4.4 Member functions ........................................................................................................................325
17.4.4.5 Reentrancy ...................................................................................................................................325
17.4.4.6 Protection within classes..............................................................................................................325
17.4.4.7 Derived classes ............................................................................................................................325
17.4.4.8 Restrictions on exception handling ..............................................................................................325

18 Language support library ......................................................................................................................327

18.1 Types..................................................................................................................................................327

18.2 Implementation properties .................................................................................................................328
18.2.1 Numeric limits ................................................................................................................................328
18.2.1.1 Template class numeric_limits...........................................................................................328
18.2.1.2 numeric_limits members ....................................................................................................329
18.2.1.3 Type float_round_style ...................................................................................................333
18.2.1.4 Type float_denorm_style.................................................................................................334
18.2.1.5 numeric_limits specializations ...........................................................................................334
18.2.2 C Library .........................................................................................................................................335

18.3      Start and termination..........................................................................................................................336

18.4 Dynamic memory management .........................................................................................................337
18.4.1 Storage allocation and deallocation ................................................................................................337
18.4.1.1 Single-object forms ......................................................................................................................337
18.4.1.2 Array forms ..................................................................................................................................338
18.4.1.3 Placement forms ..........................................................................................................................339
18.4.2 Storage allocation errors .................................................................................................................340
18.4.2.1 Class bad_alloc ......................................................................................................................340
18.4.2.2 Type new_handler..................................................................................................................340



xii
© ISO/IEC                                                                                                                 ISO/IEC 14882:1998(E)




18.4.2.3       set_new_handler .................................................................................................................341

18.5 Type identification .............................................................................................................................341
18.5.1 Class type_info .........................................................................................................................341
18.5.2 Class bad_cast ...........................................................................................................................342
18.5.3 Class bad_typeid.......................................................................................................................342

18.6 Exception handling ............................................................................................................................343
18.6.1 Class exception .........................................................................................................................343
18.6.2 Violating exception-specifications...............................................................................344
18.6.2.1 Class bad_exception ............................................................................................................344
18.6.2.2 Type unexpected_handler.................................................................................................345
18.6.2.3 set_unexpected....................................................................................................................345
18.6.2.4 unexpected .............................................................................................................................345
18.6.3 Abnormal termination .....................................................................................................................345
18.6.3.1 Type terminate_handler ...................................................................................................345
18.6.3.2 set_terminate ......................................................................................................................345
18.6.3.3 terminate................................................................................................................................345
18.6.4 uncaught_exception .............................................................................................................346

18.7 Other runtime support ........................................................................................................................346

19 Diagnostics library ................................................................................................................................349

19.1 Exception classes ...............................................................................................................................349
19.1.1 Class logic_error ....................................................................................................................349
19.1.2 Class domain_error..................................................................................................................350
19.1.3 Class invalid_argument ........................................................................................................350
19.1.4 Class length_error..................................................................................................................350
19.1.5 Class out_of_range..................................................................................................................351
19.1.6 Class runtime_error ...............................................................................................................351
19.1.7 Class range_error ....................................................................................................................351
19.1.8 Class overflow_error .............................................................................................................351
19.1.9 Class underflow_error...........................................................................................................352

19.2 Assertions ..........................................................................................................................................352

19.3 Error numbers ....................................................................................................................................352

20 General utilities library .........................................................................................................................353

20.1 Requirements .....................................................................................................................................353
20.1.1 Equality comparison .......................................................................................................................353
20.1.2 Less than comparison .....................................................................................................................353
20.1.3 Copy construction ...........................................................................................................................354
20.1.4 Default construction........................................................................................................................354
20.1.5 Allocator requirements ...................................................................................................................354

20.2 Utility components.............................................................................................................................357
20.2.1 Operators.........................................................................................................................................357
20.2.2 Pairs ................................................................................................................................................358

20.3 Function objects .................................................................................................................................359
20.3.1 Base.................................................................................................................................................361



                                                                                                                                                          xiii
ISO/IEC 14882:1998(E)                                                                                                                           © ISO/IEC




20.3.2 Arithmetic operations .....................................................................................................................361
20.3.3 Comparisons ...................................................................................................................................362
20.3.4 Logical operations ..........................................................................................................................363
20.3.5 Negators ..........................................................................................................................................363
20.3.6 Binders ............................................................................................................................................364
20.3.6.1 Template class binder1st.......................................................................................................364
20.3.6.2 bind1st.....................................................................................................................................364
20.3.6.3 Template class binder2nd.......................................................................................................364
20.3.6.4 bind2nd.....................................................................................................................................365
20.3.7 Adaptors for pointers to functions ..................................................................................................365
20.3.8 Adaptors for pointers to members ..................................................................................................366

20.4 Memory..............................................................................................................................................368
20.4.1 The default allocator .......................................................................................................................368
20.4.1.1 allocator members ................................................................................................................369
20.4.1.2 allocator globals ...................................................................................................................370
20.4.2 Raw storage iterator ........................................................................................................................370
20.4.3 Temporary buffers ..........................................................................................................................371
20.4.4 Specialized algorithms ....................................................................................................................371
20.4.4.1 uninitialized_copy ..........................................................................................................371
20.4.4.2 uninitialized_fill ..........................................................................................................372
20.4.4.3 uninitialized_fill_n .....................................................................................................372
20.4.5 Template class auto_ptr ............................................................................................................372
20.4.5.1 auto_ptr constructors..............................................................................................................373
20.4.5.2 auto_ptr members ..................................................................................................................373
20.4.5.3 auto_ptr conversions ..............................................................................................................374
20.4.6 C Library .........................................................................................................................................374

20.5 Date and time .....................................................................................................................................375

21     Strings library .......................................................................................................................................377

21.1 Character traits ...................................................................................................................................377
21.1.1 Character traits requirements ..........................................................................................................377
21.1.2 traits typedefs ..................................................................................................................................379
21.1.3 char_traits specializations .....................................................................................................379
21.1.3.1 struct char_traits<char>............................................................................................379
21.1.3.2 struct char_traits<wchar_t>.....................................................................................380

21.2      String classes .....................................................................................................................................381

21.3 Template class basic_string......................................................................................................383
21.3.1 basic_string constructors .......................................................................................................387
21.3.2 basic_string iterator support ..................................................................................................390
21.3.3 basic_string capacity .............................................................................................................390
21.3.4 basic_string element access ...................................................................................................391
21.3.5 basic_string modifiers ...........................................................................................................392
21.3.5.1 basic_string::operator+=............................................................................................392
21.3.5.2 basic_string::append .....................................................................................................392
21.3.5.3 basic_string::assign .....................................................................................................393
21.3.5.4 basic_string::insert .....................................................................................................393
21.3.5.5 basic_string::erase........................................................................................................394
21.3.5.6 basic_string::replace...................................................................................................395
21.3.5.7 basic_string::copy ..........................................................................................................396



xiv
© ISO/IEC                                                                                                                ISO/IEC 14882:1998(E)




21.3.5.8 basic_string::swap ..........................................................................................................397
21.3.6 basic_string string operations ................................................................................................397
21.3.6.1 basic_string::find ..........................................................................................................397
21.3.6.2 basic_string::rfind........................................................................................................398
21.3.6.3 basic_string::find_first_of.....................................................................................398
21.3.6.4 basic_string::find_last_of.......................................................................................399
21.3.6.5 basic_string::find_first_not_of...........................................................................399
21.3.6.6 basic_string::find_last_not_of .............................................................................400
21.3.6.7 basic_string::substr .....................................................................................................400
21.3.6.8 basic_string::compare...................................................................................................400
21.3.7 basic_string non-member functions ......................................................................................401
21.3.7.1 operator+................................................................................................................................401
21.3.7.2 operator== .............................................................................................................................402
21.3.7.3 operator!= .............................................................................................................................402
21.3.7.4 operator<................................................................................................................................403
21.3.7.5 operator>................................................................................................................................403
21.3.7.6 operator<= .............................................................................................................................403
21.3.7.7 operator>= .............................................................................................................................404
21.3.7.8 swap............................................................................................................................................404
21.3.7.9 Inserters and extractors ................................................................................................................404

21.4 Null-terminated sequence utilities .....................................................................................................405

22 Localization library ...............................................................................................................................409

22.1 Locales ...............................................................................................................................................409
22.1.1 Class locale ................................................................................................................................410
22.1.1.1 locale types .............................................................................................................................412
22.1.1.1.1 Type locale::category...................................................................................................412
22.1.1.1.2 Class locale::facet .........................................................................................................414
22.1.1.1.3 Class locale::id.................................................................................................................414
22.1.1.2 locale constructors and destructor ...........................................................................................415
22.1.1.3 locale members .......................................................................................................................416
22.1.1.4 locale operators .......................................................................................................................416
22.1.1.5 locale static members ..............................................................................................................416
22.1.2 locale globals .............................................................................................................................417
22.1.3 Convenience interfaces ...................................................................................................................417
22.1.3.1 Character classification ................................................................................................................417
22.1.3.2 Character conversions ..................................................................................................................417

22.2 Standard locale categories.............................................................................................................418
22.2.1 The ctype category ......................................................................................................................418
22.2.1.1 Template class ctype ................................................................................................................418
22.2.1.1.1 ctype members .......................................................................................................................419
22.2.1.1.2 ctype virtual functions ...........................................................................................................420
22.2.1.2 Template class ctype_byname................................................................................................421
22.2.1.3 ctype specializations .................................................................................................................422
22.2.1.3.1 ctype<char> destructor .......................................................................................................423
22.2.1.3.2 ctype<char> members ........................................................................................................423
22.2.1.3.3 ctype<char> static members ...............................................................................................424
22.2.1.3.4 ctype<char> virtual functions.............................................................................................424
22.2.1.4 Class ctype_byname<char> .........................................................................................................425
22.2.1.5 Template class codecvt............................................................................................................425
22.2.1.5.1 codecvt members ..................................................................................................................426



                                                                                                                                                          xv
ISO/IEC 14882:1998(E)                                                                                                                      © ISO/IEC




22.2.1.5.2 codecvt virtual functions ......................................................................................................427
22.2.1.6 Template class codecvt_byname...........................................................................................429
22.2.2 The numeric category .....................................................................................................................429
22.2.2.1 Template class num_get............................................................................................................429
22.2.2.1.1 num_get members ..................................................................................................................431
22.2.2.1.2 num_get virtual functions ......................................................................................................431
22.2.2.2 Template class num_put............................................................................................................433
22.2.2.2.1 num_put members ..................................................................................................................434
22.2.2.2.2 num_put virtual functions ......................................................................................................434
22.2.3 The numeric punctuation facet .......................................................................................................437
22.2.3.1 Template class numpunct .........................................................................................................437
22.2.3.1.1 numpunct members ...............................................................................................................438
22.2.3.1.2 numpunct virtual functions ....................................................................................................439
22.2.3.2 Template class numpunct_byname ........................................................................................439
22.2.4 The collate category ........................................................................................................................439
22.2.4.1 Template class collate............................................................................................................439
22.2.4.1.1 collate members ..................................................................................................................440
22.2.4.1.2 collate virtual functions ......................................................................................................440
22.2.4.2 Template class collate_byname...........................................................................................441
22.2.5 The time category ...........................................................................................................................441
22.2.5.1 Template class time_get .........................................................................................................441
22.2.5.1.1 time_get members ...............................................................................................................442
22.2.5.1.2 time_get virtual functions ....................................................................................................443
22.2.5.2 Template class time_get_byname ........................................................................................444
22.2.5.3 Template class time_put .........................................................................................................444
22.2.5.3.1 time_put members ...............................................................................................................445
22.2.5.3.2 time_put virtual functions ....................................................................................................445
22.2.5.4 Template class time_put_byname ........................................................................................445
22.2.6 The monetary category ...................................................................................................................446
22.2.6.1 Template class money_get.......................................................................................................446
22.2.6.1.1 money_get members .............................................................................................................446
22.2.6.1.2 money_get virtual functions .................................................................................................446
22.2.6.2 Template class money_put.......................................................................................................448
22.2.6.2.1 money_put members .............................................................................................................448
22.2.6.2.2 money_put virtual functions .................................................................................................448
22.2.6.3 Template class moneypunct ....................................................................................................449
22.2.6.3.1 moneypunct members ...........................................................................................................450
22.2.6.3.2 moneypunct virtual functions ...............................................................................................450
22.2.6.4 Template class moneypunct_byname....................................................................................451
22.2.7 The message retrieval category.......................................................................................................452
22.2.7.1 Template class messages .........................................................................................................452
22.2.7.1.1 messages members ...............................................................................................................452
22.2.7.1.2 messages virtual functions ....................................................................................................453
22.2.7.2 Template class messages_byname ........................................................................................453
22.2.8 Program-defined facets ...................................................................................................................453

22.3     C Library Locales ..............................................................................................................................457

23 Containers library .................................................................................................................................459

23.1 Container requirements ......................................................................................................................459
23.1.1 Sequences .......................................................................................................................................462
23.1.2 Associative containers ....................................................................................................................464




xvi
© ISO/IEC                                                                                                              ISO/IEC 14882:1998(E)




23.2 Sequences ..........................................................................................................................................467
23.2.1 Template class deque ...................................................................................................................470
23.2.1.1 deque constructors, copy, and assignment ................................................................................472
23.2.1.2 deque capacity ...........................................................................................................................473
23.2.1.3 deque modifiers .........................................................................................................................473
23.2.1.4 deque specialized algorithms ....................................................................................................473
23.2.2 Template class list......................................................................................................................474
23.2.2.1 list constructors, copy, and assignment ...................................................................................476
23.2.2.2 list capacity .............................................................................................................................477
23.2.2.3 list modifiers ...........................................................................................................................477
23.2.2.4 list operations ..........................................................................................................................477
23.2.2.5 list specialized algorithms .......................................................................................................479
23.2.3 Container adaptors ..........................................................................................................................479
23.2.3.1 Template class queue ................................................................................................................479
23.2.3.2 Template class priority_queue...........................................................................................480
23.2.3.2.1 priority_queue constructors ............................................................................................481
23.2.3.2.2 priority_queue members .................................................................................................481
23.2.3.3 Template class stack ................................................................................................................481
23.2.4 Template class vector .................................................................................................................482
23.2.4.1 vector constructors, copy, and assignment ..............................................................................484
23.2.4.2 vector capacity.........................................................................................................................485
23.2.4.3 vector modifiers.......................................................................................................................485
23.2.4.4 vector specialized algorithms ..................................................................................................486
23.2.5 Class vector<bool>..................................................................................................................486

23.3 Associative containers .......................................................................................................................488
23.3.1 Template class map ........................................................................................................................490
23.3.1.1 map constructors, copy, and assignment .....................................................................................492
23.3.1.2 map element access .....................................................................................................................493
23.3.1.3 map operations ............................................................................................................................493
23.3.1.4 map specialized algorithms .........................................................................................................493
23.3.2 Template class multimap ............................................................................................................493
23.3.2.1 multimap constructors..............................................................................................................496
23.3.2.2 multimap operations ................................................................................................................496
23.3.2.3 multimap specialized algorithms .............................................................................................496
23.3.3 Template class set ........................................................................................................................496
23.3.3.1 set constructors, copy, and assignment .....................................................................................498
23.3.3.2 set specialized algorithms .........................................................................................................499
23.3.4 Template class multiset ............................................................................................................499
23.3.4.1 multiset constructors..............................................................................................................501
23.3.4.2 multiset specialized algorithms .............................................................................................501
23.3.5 Template class bitset .................................................................................................................502
23.3.5.1 bitset constructors ..................................................................................................................503
23.3.5.2 bitset members .......................................................................................................................504
23.3.5.3 bitset operators .......................................................................................................................506

24 Iterators library .....................................................................................................................................509

24.1 Iterator requirements ..........................................................................................................................509
24.1.1 Input iterators ..................................................................................................................................510
24.1.2 Output iterators ...............................................................................................................................511
24.1.3 Forward iterators .............................................................................................................................512
24.1.4 Bidirectional iterators .....................................................................................................................513
24.1.5 Random access iterators..................................................................................................................513



                                                                                                                                                      xvii
ISO/IEC 14882:1998(E)                                                                                                                       © ISO/IEC




24.2 Header <iterator> synopsis ........................................................................................................514

24.3 Iterator primitives ..............................................................................................................................516
24.3.1 Iterator traits....................................................................................................................................516
24.3.2 Basic iterator ...................................................................................................................................517
24.3.3 Standard iterator tags ......................................................................................................................518
24.3.4 Iterator operations ...........................................................................................................................519

24.4 Predefined iterators ............................................................................................................................519
24.4.1 Reverse iterators .............................................................................................................................519
24.4.1.1 Template class reverse_iterator ......................................................................................520
24.4.1.2 reverse_iterator requirements .........................................................................................521
24.4.1.3 reverse_iterator operations .............................................................................................521
24.4.1.3.1 reverse_iterator constructor .........................................................................................521
24.4.1.3.2 Conversion ................................................................................................................................521
24.4.1.3.3 operator*.............................................................................................................................521
24.4.1.3.4 operator-> ..........................................................................................................................522
24.4.1.3.5 operator++ ..........................................................................................................................522
24.4.1.3.6 operator-- ..........................................................................................................................522
24.4.1.3.7 operator+.............................................................................................................................522
24.4.1.3.8 operator+= ..........................................................................................................................522
24.4.1.3.9 operator-.............................................................................................................................523
24.4.1.3.10 operator-= ........................................................................................................................523
24.4.1.3.11 operator[] ........................................................................................................................523
24.4.1.3.12 operator== ........................................................................................................................523
24.4.1.3.13 operator<...........................................................................................................................523
24.4.1.3.14 operator!= ........................................................................................................................523
24.4.1.3.15 operator>...........................................................................................................................523
24.4.1.3.16 operator>= ........................................................................................................................524
24.4.1.3.17 operator<= ........................................................................................................................524
24.4.1.3.18 operator-...........................................................................................................................524
24.4.1.3.19 operator+...........................................................................................................................524
24.4.2 Insert iterators .................................................................................................................................524
24.4.2.1 Template class back_insert_iterator ............................................................................525
24.4.2.2 back_insert_iterator operations ....................................................................................525
24.4.2.2.1 back_insert_iterator constructor ...............................................................................525
24.4.2.2.2 back_insert_iterator::operator=........................................................................525
24.4.2.2.3 back_insert_iterator::operator*........................................................................525
24.4.2.2.4 back_insert_iterator::operator++......................................................................525
24.4.2.2.5 back_inserter ...................................................................................................................526
24.4.2.3 Template class front_insert_iterator ..........................................................................526
24.4.2.4 front_insert_iterator operations .................................................................................526
24.4.2.4.1 front_insert_iterator constructor .............................................................................526
24.4.2.4.2 front_insert_iterator::operator=......................................................................526
24.4.2.4.3 front_insert_iterator::operator*......................................................................526
24.4.2.4.4 front_insert_iterator::operator++ ...................................................................527
24.4.2.4.5 front_inserter.................................................................................................................527
24.4.2.5 Template class insert_iterator ........................................................................................527
24.4.2.6 insert_iterator operations ................................................................................................527
24.4.2.6.1 insert_iterator constructor ...........................................................................................527
24.4.2.6.2 insert_iterator::operator=....................................................................................527
24.4.2.6.3 insert_iterator::operator*....................................................................................528
24.4.2.6.4 insert_iterator::operator++..................................................................................528
24.4.2.6.5 inserter ...............................................................................................................................528



xviii
© ISO/IEC                                                                                                                  ISO/IEC 14882:1998(E)




24.5 Stream iterators ..................................................................................................................................528
24.5.1 Template class istream_iterator .........................................................................................528
24.5.1.1 istream_iterator constructors and destructor ...................................................................529
24.5.1.2 istream_iterator operations .............................................................................................529
24.5.2 Template class ostream_iterator .........................................................................................530
24.5.2.1 ostream_iterator constructors and destructor ...................................................................531
24.5.2.2 ostream_iterator operations .............................................................................................531
24.5.3 Template class istreambuf_iterator..................................................................................531
24.5.3.1 Template class istreambuf_iterator::proxy ..............................................................532
24.5.3.2 istreambuf_iterator constructors ...................................................................................533
24.5.3.3 istreambuf_iterator::operator* .............................................................................533
24.5.3.4 istreambuf_iterator::operator++...........................................................................533
24.5.3.5 istreambuf_iterator::equal.......................................................................................533
24.5.3.6 operator== .............................................................................................................................533
24.5.3.7 operator!= .............................................................................................................................534
24.5.4 Template class ostreambuf_iterator..................................................................................534
24.5.4.1 ostreambuf_iterator constructors ...................................................................................534
24.5.4.2 ostreambuf_iterator operations ......................................................................................534

25     Algorithms library ................................................................................................................................537

25.1 Non-modifying sequence operations .................................................................................................545
25.1.1 For each ..........................................................................................................................................545
25.1.2 Find .................................................................................................................................................546
25.1.3 Find End..........................................................................................................................................546
25.1.4 Find First.........................................................................................................................................546
25.1.5 Adjacent find ..................................................................................................................................547
25.1.6 Count...............................................................................................................................................547
25.1.7 Mismatch ........................................................................................................................................547
25.1.8 Equal ...............................................................................................................................................548
25.1.9 Search .............................................................................................................................................548

25.2 Mutating sequence operations ...........................................................................................................549
25.2.1 Copy ................................................................................................................................................549
25.2.2 Swap ...............................................................................................................................................549
25.2.3 Transform .......................................................................................................................................550
25.2.4 Replace ...........................................................................................................................................550
25.2.5 Fill ...................................................................................................................................................551
25.2.6 Generate ..........................................................................................................................................551
25.2.7 Remove ...........................................................................................................................................551
25.2.8 Unique.............................................................................................................................................552
25.2.9 Reverse ...........................................................................................................................................552
25.2.10 Rotate ............................................................................................................................................553
25.2.11 Random shuffle .............................................................................................................................553
25.2.12 Partitions .......................................................................................................................................554

25.3 Sorting and related operations ...........................................................................................................554
25.3.1 Sorting.............................................................................................................................................555
25.3.1.1 sort............................................................................................................................................555
25.3.1.2 stable_sort...........................................................................................................................555
25.3.1.3 partial_sort.........................................................................................................................555
25.3.1.4 partial_sort_copy.............................................................................................................556
25.3.2 Nth element .....................................................................................................................................556
25.3.3 Binary search ..................................................................................................................................556



                                                                                                                                                            xix
ISO/IEC 14882:1998(E)                                                                                                                        © ISO/IEC




25.3.3.1 lower_bound...........................................................................................................................556
25.3.3.2 upper_bound...........................................................................................................................557
25.3.3.3 equal_range...........................................................................................................................557
25.3.3.4 binary_search ......................................................................................................................557
25.3.4 Merge ..............................................................................................................................................558
25.3.5 Set operations on sorted structures .................................................................................................558
25.3.5.1 includes ..................................................................................................................................559
25.3.5.2 set_union................................................................................................................................559
25.3.5.3 set_intersection...............................................................................................................559
25.3.5.4 set_difference....................................................................................................................560
25.3.5.5 set_symmetric_difference............................................................................................560
25.3.6 Heap operations ..............................................................................................................................560
25.3.6.1 push_heap................................................................................................................................561
25.3.6.2 pop_heap ..................................................................................................................................561
25.3.6.3 make_heap................................................................................................................................561
25.3.6.4 sort_heap................................................................................................................................561
25.3.7 Minimum and maximum ................................................................................................................562
25.3.8 Lexicographical comparison ...........................................................................................................562
25.3.9 Permutation generators ...................................................................................................................563

25.4      C library algorithms ...........................................................................................................................563

26 Numerics library ...................................................................................................................................565

26.1 Numeric type requirements ................................................................................................................565

26.2 Complex numbers ..............................................................................................................................566
26.2.1 Header <complex> synopsis .......................................................................................................566
26.2.2 Template class complex...............................................................................................................567
26.2.3 complex specializations ...............................................................................................................569
26.2.4 complex member functions..........................................................................................................570
26.2.5 complex member operators..........................................................................................................570
26.2.6 complex non-member operations ................................................................................................571
26.2.7 complex value operations ............................................................................................................572
26.2.8 complex transcendentals ..............................................................................................................573

26.3 Numeric arrays ...................................................................................................................................574
26.3.1 Header <valarray> synopsis .....................................................................................................574
26.3.2 Template class valarray ............................................................................................................577
26.3.2.1 valarray constructors..............................................................................................................578
26.3.2.2 valarray assignment ...............................................................................................................579
26.3.2.3 valarray element access .........................................................................................................580
26.3.2.4 valarray subset operations .....................................................................................................580
26.3.2.5 valarray unary operators ........................................................................................................580
26.3.2.6 valarray computed assignment ..............................................................................................581
26.3.2.7 valarray member functions ....................................................................................................581
26.3.3 valarray non-member operations ..............................................................................................583
26.3.3.1 valarray binary operators .......................................................................................................583
26.3.3.2 valarray logical operators ......................................................................................................584
26.3.3.3 valarray transcendentals.........................................................................................................585
26.3.4 Class slice...................................................................................................................................585
26.3.4.1 slice constructors .....................................................................................................................585
26.3.4.2 slice access functions ..............................................................................................................586
26.3.5 Template class slice_array .....................................................................................................586



xx
© ISO/IEC                                                                                                                   ISO/IEC 14882:1998(E)




26.3.5.1 slice_array constructors ......................................................................................................587
26.3.5.2 slice_array assignment ........................................................................................................587
26.3.5.3 slice_array computed assignment .......................................................................................587
26.3.5.4 slice_array fill function .......................................................................................................587
26.3.6 The gslice class ..........................................................................................................................587
26.3.6.1 gslice constructors........................................................................................................588
26.3.6.2 gslice access functions ............................................................................................................589
26.3.7 Template class gslice_array...................................................................................................589
26.3.7.1 gslice_array constructors ....................................................................................................589
26.3.7.2 gslice_array assignment......................................................................................................590
26.3.7.3 gslice_array computed assignment.........................................................................590
26.3.7.4 gslice_array fill function.....................................................................................................590
26.3.8 Template class mask_array .......................................................................................................590
26.3.8.1 mask_array constructors .........................................................................................................591
26.3.8.2 mask_array assignment ..........................................................................................................591
26.3.8.3 mask_array computed assignment..........................................................................................591
26.3.8.4 mask_array fill function .........................................................................................................592
26.3.9 Template class indirect_array..............................................................................................592
26.3.9.1 indirect_array constructors ...............................................................................................592
26.3.9.2 indirect_array assignment .................................................................................................593
26.3.9.3 indirect_array computed assignment ................................................................................593
26.3.9.4 indirect_array fill function ................................................................................................593

26.4 Generalized numeric operations ........................................................................................................593
26.4.1 Accumulate .....................................................................................................................................594
26.4.2 Inner product ...................................................................................................................................595
26.4.3 Partial sum ......................................................................................................................................595
26.4.4 Adjacent difference .........................................................................................................................595

26.5      C Library ............................................................................................................................................596

27     Input/output library ...............................................................................................................................599

27.1 Iostreams requirements ......................................................................................................................599
27.1.1 Imbue Limitations ...........................................................................................................................599
27.1.2 Positioning Type Limitations .........................................................................................................599

27.2 Forward declarations..........................................................................................................................599

27.3 Standard iostream objects ..................................................................................................................602
27.3.1 Narrow stream objects ....................................................................................................................602
27.3.2 Wide stream objects ........................................................................................................................603

27.4 Iostreams base classes ........................................................................................................................604
27.4.1 Types...............................................................................................................................................604
27.4.2 Class ios_base ...........................................................................................................................605
27.4.2.1 Types............................................................................................................................................607
27.4.2.1.1 Class ios_base::failure................................................................................................607
27.4.2.1.2 Type ios_base::fmtflags..............................................................................................607
27.4.2.1.3 Type ios_base::iostate ................................................................................................608
27.4.2.1.4 Type ios_base::openmode..............................................................................................609
27.4.2.1.5 Type ios_base::seekdir ................................................................................................609
27.4.2.1.6 Class ios_base::Init .......................................................................................................609
27.4.2.2 ios_base fmtflags state functions ....................................................................................610



                                                                                                                                                             xxi
ISO/IEC 14882:1998(E)                                                                                                                      © ISO/IEC




27.4.2.3 ios_base locale functions .................................................................................................611
27.4.2.4 ios_base static members .........................................................................................................611
27.4.2.5 ios_base storage functions ......................................................................................................611
27.4.2.6 ios_base callbacks ..................................................................................................................612
27.4.2.7 ios_base constructors/destructors ...........................................................................................612
27.4.3 Template class fpos......................................................................................................................612
27.4.3.1 fpos Members............................................................................................................................612
27.4.3.2 fpos requirements ......................................................................................................................612
27.4.4 Template class basic_ios..........................................................................................................613
27.4.4.1 basic_ios constructors ...........................................................................................................614
27.4.4.2 Member functions ........................................................................................................................615
27.4.4.3 basic_ios iostate flags functions ....................................................................................616
27.4.5 ios_base manipulators ...............................................................................................................617
27.4.5.1 fmtflags manipulators ............................................................................................................617
27.4.5.2 adjustfield manipulators .....................................................................................................618
27.4.5.3 basefield manipulators ..........................................................................................................619
27.4.5.4 floatfield manipulators .......................................................................................................619

27.5 Stream buffers ....................................................................................................................................619
27.5.1 Stream buffer requirements ............................................................................................................620
27.5.2 Template class basic_streambuf<charT,traits>..........................................................620
27.5.2.1 basic_streambuf constructors .............................................................................................622
27.5.2.2 basic_streambuf public member functions ........................................................................623
27.5.2.2.1 Locales ......................................................................................................................................623
27.5.2.2.2 Buffer management and positioning .........................................................................................623
27.5.2.2.3 Get area .....................................................................................................................................623
27.5.2.2.4 Putback .....................................................................................................................................624
27.5.2.2.5 Put area .....................................................................................................................................624
27.5.2.3 basic_streambuf protected member functions....................................................................624
27.5.2.3.1 Get area access ..........................................................................................................................624
27.5.2.3.2 Put area access ..........................................................................................................................625
27.5.2.4 basic_streambuf virtual functions ......................................................................................625
27.5.2.4.1 Locales ......................................................................................................................................625
27.5.2.4.2 Buffer management and positioning .........................................................................................625
27.5.2.4.3 Get area .....................................................................................................................................626
27.5.2.4.4 Putback .....................................................................................................................................627
27.5.2.4.5 Put area .....................................................................................................................................628

27.6 Formatting and manipulators .............................................................................................................629
27.6.1 Input streams ...................................................................................................................................630
27.6.1.1 Template class basic_istream .............................................................................................630
27.6.1.1.1 basic_istream constructors...............................................................................................632
27.6.1.1.2 Class basic_istream::sentry ......................................................................................632
27.6.1.2 Formatted input functions ............................................................................................................633
27.6.1.2.1 Common requirements..............................................................................................................633
27.6.1.2.2 Arithmetic Extractors................................................................................................................633
27.6.1.2.3 basic_istream::operator>> ......................................................................................634
27.6.1.3 Unformatted input functions ........................................................................................................635
27.6.1.4 Standard basic_istream manipulators .................................................................................639
27.6.1.5 Template class basic_iostream...........................................................................................639
27.6.1.5.1 basic_iostream constructors ............................................................................................640
27.6.1.5.2 basic_iostream destructor ................................................................................................640
27.6.2 Output streams ................................................................................................................................640
27.6.2.1 Template class basic_ostream .............................................................................................640



xxii
© ISO/IEC                                                                                                              ISO/IEC 14882:1998(E)




27.6.2.2 basic_ostream constructors..................................................................................................642
27.6.2.3 Class basic_ostream::sentry .........................................................................................642
27.6.2.4 basic_ostream seek members ..............................................................................................643
27.6.2.5 Formatted output functions ..........................................................................................................643
27.6.2.5.1 Common requirements..............................................................................................................643
27.6.2.5.2 Arithmetic Inserters ..................................................................................................................643
27.6.2.5.3 basic_ostream::operator<< ......................................................................................644
27.6.2.5.4 Character inserter template functions .......................................................................................645
27.6.2.6 Unformatted output functions ......................................................................................................645
27.6.2.7 Standard basic_ostream manipulators .................................................................................646
27.6.3 Standard manipulators ....................................................................................................................646

27.7 String-based streams ..........................................................................................................................648
27.7.1 Template class basic_stringbuf ...........................................................................................649
27.7.1.1 basic_stringbuf constructors .............................................................................................650
27.7.1.2 Member functions ........................................................................................................................650
27.7.1.3 Overridden virtual functions ........................................................................................................651
27.7.2 Template class basic_istringstream..................................................................................653
27.7.2.1 basic_istringstream constructors ...................................................................................653
27.7.2.2 Member functions ........................................................................................................................654
27.7.3 Class basic_ostringstream .................................................................................................654
27.7.3.1 basic_ostringstream constructors ...................................................................................655
27.7.3.2 Member functions ........................................................................................................................655
27.7.4 Template class basic_stringstream ....................................................................................655
27.7.5 basic_stringstream constructors ......................................................................................................656
27.7.6 Member functions ...........................................................................................................................656

27.8 File-based streams .............................................................................................................................657
27.8.1 File streams .....................................................................................................................................657
27.8.1.1 Template class basic_filebuf .............................................................................................657
27.8.1.2 basic_filebuf constructors..................................................................................................658
27.8.1.3 Member functions ........................................................................................................................659
27.8.1.4 Overridden virtual functions ........................................................................................................660
27.8.1.5 Template class basic_ifstream...........................................................................................662
27.8.1.6 basic_ifstream constructors ...............................................................................................663
27.8.1.7 Member functions ........................................................................................................................663
27.8.1.8 Template class basic_ofstream...........................................................................................664
27.8.1.9 basic_ofstream constructors ...............................................................................................664
27.8.1.10 Member functions ......................................................................................................................665
27.8.1.11 Template class basic_fstream ...........................................................................................665
27.8.1.12 basic_fstream constructors................................................................................................666
27.8.1.13 Member functions ......................................................................................................................666
27.8.2 C Library files .................................................................................................................................666

Annex A (informative) Grammar summary ..............................................................................................667

A.1 Keywords ............................................................................................................................................667

A.2 Lexical conventions ............................................................................................................................667

A.3 Basic concepts.....................................................................................................................................671

A.4 Expressions .........................................................................................................................................671




                                                                                                                                                    xxiii
ISO/IEC 14882:1998(E)                                                                                                                         © ISO/IEC




A.5 Statements ...........................................................................................................................................674

A.6 Declarations ........................................................................................................................................675

A.7 Declarators ..........................................................................................................................................677

A.8 Classes ................................................................................................................................................679

A.9 Derived classes....................................................................................................................................680

A.10 Special member functions .................................................................................................................680

A.11 Overloading ......................................................................................................................................680

A.12 Templates ..........................................................................................................................................681

A.13 Exception handling ...........................................................................................................................681

A.14 Preprocessing directives....................................................................................................................682

Annex B (informative) Implementation quantities ....................................................................................685

Annex C (informative)                Compatibility .......................................................................................................687

C.1 C++ and ISO C ....................................................................................................................................687
C.1.1 Clause 2: lexical conventions ...........................................................................................................687
C.1.2 Clause 3: basic concepts ..................................................................................................................688
C.1.3 Clause 5: expressions .......................................................................................................................690
C.1.4 Clause 6: statements .........................................................................................................................690
C.1.5 Clause 7: declarations ......................................................................................................................691
C.1.6 Clause 8: declarators ........................................................................................................................693
C.1.7 Clause 9: classes...............................................................................................................................694
C.1.8 Clause 12: special member functions...............................................................................................695
C.1.9 Clause 16: preprocessing directives .................................................................................................696

C.2 Standard C library ...............................................................................................................................696
C.2.1 Modifications to headers ..................................................................................................................698
C.2.2 Modifications to definitions .............................................................................................................698
C.2.2.1 Type wchar_t.............................................................................................................................698
C.2.2.2 Header <iso646.h> ..................................................................................................................699
C.2.2.3 Macro NULL..................................................................................................................................699
C.2.3 Modifications to declarations ...........................................................................................................699
C.2.4 Modifications to behavior ................................................................................................................699
C.2.4.1 Macro offsetof(type, member-designator) ............................................................699
C.2.4.2 Memory allocation functions ........................................................................................................699

Annex D (normative)                Compatibility features ............................................................................................701

D.1      Postfix increment operator ..................................................................................................................701

D.2 static keyword .....................................................................................................................................701

D.3 Access declarations .............................................................................................................................701




xxiv
© ISO/IEC                                                                                                                     ISO/IEC 14882:1998(E)




D.4      Implicit conversion from const strings ...............................................................................................701

D.5 Standard C library headers ..................................................................................................................701

D.6 Old iostreams members ......................................................................................................................701

D.7 char* streams ...................................................................................................................................703
D.7.1 Class strstreambuf ...................................................................................................................703
D.7.1.1 strstreambuf constructors .....................................................................................................705
D.7.1.2 Member functions .........................................................................................................................706
D.7.1.3 strstreambuf overridden virtual functions ............................................................................706
D.7.2 Class istrstream........................................................................................................................709
D.7.2.1 istrstream constructors ..........................................................................................................709
D.7.2.2 Member functions .........................................................................................................................709
D.7.3 Class ostrstream........................................................................................................................710
D.7.3.1 ostrstream constructors ..........................................................................................................710
D.7.3.2 Member functions .........................................................................................................................710
D.7.4 Class strstream ..........................................................................................................................711
D.7.4.1 strstream constructors ............................................................................................................711
D.7.4.2 strstream destructor ................................................................................................................712
D.7.4.3 strstream operations ...............................................................................................................712

Annex E (normative) Universal-character-names .....................................................................................713

Index .............................................................................................................................................................715




                                                                                                                                                               xxv
ISO/IEC 14882:1998(E)                                                   ©   ISO/IEC




Foreword
ISO (the International Organization for Standardization) and IEC (the Inter-
national Electrotechnical Commission) form the specialized system for worldwide
standardization. National bodies that are members of ISO or IEC participate in the
development of International Standards through technical committees established
by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other
international organizations, governmental and non-governmental, in liaison with
ISO and IEC, also take part in the work.

In the field of information technology, ISO and IEC have established a joint
technical committee, ISO/IEC JTC 1. Draft International Standards adopted by the
joint technical committee are circulated to national bodies for voting. Publication
as an International Standard requires approval by at least 75 % of the national
bodies casting a vote.

International Standard ISO/IEC 14882 was prepared by Joint Technical
Committee ISO/IEC JTC 1, Information technology, Subcommittee SC 22,
Programming languages, their environments and system software interfaces.

Annexes D and E form an integral part of this International Standard. Annexes A
to C are for information only.




xxvi
    _
    ______________________________________________________________________________________
    INTERNATIONAL STANDARD                 ©ISO/IEC              ISO/IEC 14882:1998(E)
    _
    ______________________________________________________________________________________




    Programming languages ­ C++

    1 General                                                                                                                   [intro]

    1.1 Scope                                                                                                                [intro.scope]
1   This International Standard specifies requirements for implementations of the C++ programming language.
    The first such requirement is that they implement the language, and so this International Standard also
    defines C++. Other requirements and relaxations of the first requirement appear at various places within
    this International Standard.
2   C++ is a general purpose programming language based on the C programming language as described in
    ISO/IEC 9899:1990 Programming languages ­ C (1.2). In addition to the facilities provided by C, C++
    provides additional data types, classes, templates, exceptions, namespaces, inline functions, operator over-
    loading, function name overloading, references, free store management operators, and additional library
    facilities.

    1.2 Normative references                                                                                                   [intro.refs]
1   The following standards contain provisions which, through reference in this text, constitute provisions of
    this International Standard. At the time of publication, the editions indicated were valid. All standards are
    subject to revision, and parties to agreements based on this International Standard are encouraged to investi-
    gate the possibility of applying the most recent editions of the standards indicated below. Members of IEC
    and ISO maintain registers of currently valid International Standards.
    -- ISO/IEC 2382 (all parts), Information technology ­ Vocabulary
    -- ISO/IEC 9899:1990, Programming languages ­ C
    -- ISO/IEC 9899/Amd.1:1995, Programming languages ­ C, AMENDMENT 1: C Integrity
    -- ISO/IEC 10646-1:1993 Information technology ­ Universal Multiple-Octet Coded Character Set
       (UCS) ­ Part 1: Architecture and Basic Multilingual Plane
2   The library described in clause 7 of ISO/IEC 9899:1990 and clause 7 of ISO/IEC 9899/Amd.1:1995 is here-
    inafter called the Standard C Library.1)

    1.3 Definitions                                                                                                            [intro.defs]
1   For the purposes of this International Standard, the definitions given in ISO/IEC 2382 and the following
    definitions apply. 17.1 defines additional terms that are used only in clauses 17 through 27.
2   Terms that are used only in a small portion of this International Standard are defined where they are used
    and italicized where they are defined.

    1.3.1 argument                                                                           [defns.argument]
    an expression in the comma-separated list bounded by the parentheses in a function call expression, a
    sequence of preprocessing tokens in the comma-separated list bounded by the parentheses in a function-like
    macro invocation, the operand of throw, or an expression, type-id or template-name in the comma-
    separated list bounded by the angle brackets in a template instantiation. Also known as an actual argument
    or actual parameter.

    __________________
    1) With the qualifications noted in clauses 17 through 27, and in C.2, the Standard C library is a subset of the Standard C++ library.




                                                                                                                                             1
ISO/IEC 14882:1998(E)                                                                                                 © ISO/IEC

1.3.2 diagnostic message                                                                                                1 General



1.3.2 diagnostic message                                                              [defns.diagnostic]
a message belonging to an implementation-defined subset of the implementation's output messages.

1.3.3 dynamic type                                                                        [defns.dynamic.type]
the type of the most derived object (1.8) to which the lvalue denoted by an lvalue expression refers. [Exam-
ple: 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. ]
The dynamic type of an rvalue expression is its static type.

1.3.4 ill-formed program                                                                                       [defns.ill.formed]
input to a C++ implementation that is not a well-formed program (1.3.14).

1.3.5 implementation-defined behavior                                              [defns.impl.defined]
behavior, for a well-formed program construct and correct data, that depends on the implementation and
that each implementation shall document.

1.3.6 implementation limits                                                                                    [defns.impl.limits]
restrictions imposed upon programs by the implementation.

1.3.7 locale-specific behavior                                                      [defns.locale.specific]
behavior that depends on local conventions of nationality, culture, and language that each implementation
shall document.

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

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

1.3.10 signature                                                                               [defns.signature]
the information about a function that participates in overload resolution (13.3): the types of its parameters
and, if the function is a class member, the cv- qualifiers (if any) on the function itself and the class in which
                                  2)
the member function is declared. The signature of a template function specialization includes the types of
its template arguments (14.5.5.1).

1.3.11 static type                                                                       [defns.static.type]
the type of an expression (3.9), which type results from analysis of the program without considering execu-
tion semantics. 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.

1.3.12 undefined behavior                                                                  [defns.undefined]
behavior, such as might arise upon use of an erroneous program construct or erroneous data, for which this
International Standard imposes no requirements. Undefined behavior may also be expected when this
International Standard omits the description of any explicit definition of behavior. [Note: permissible unde-
fined 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 with-
out the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a
diagnostic message). Many erroneous program constructs do not engender undefined behavior; they are
__________________
2) Function signatures do not include return type, because that does not participate in overload resolution.




2
    © ISO/IEC                                                                                             ISO/IEC 14882:1998(E)

    1 General                                                                                             1.3.12 undefined behavior



    required to be diagnosed. ]

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

    1.3.14 well-formed program                                                           [defns.well.formed]
    a C++ program constructed according to the syntax rules, diagnosable semantic rules, and the One Defini-
    tion Rule (3.2).

    1.4 Implementation compliance                                                                                [intro.compliance]
1   The set of diagnosable rules consists of all syntactic and semantic rules in this International Standard
    except for those rules containing an explicit notation that "no diagnostic is required" or which are described
    as resulting in "undefined behavior."
2   Although this International Standard states only requirements on C++ implementations, those requirements
    are often easier to understand if they are phrased as requirements on programs, parts of programs, or execu-
    tion of programs. Such requirements have the following meaning:
    -- If a program contains no violations of the rules in this International Standard, a conforming implemen-
       tation shall, within its resource limits, accept and correctly execute3) that program.
    -- If a program contains a violation of any diagnosable rule, a conforming implementation shall issue at
       least one diagnostic message, except that
    -- If a program contains a violation of a rule for which no diagnostic is required, this International Stan-
       dard places no requirement on implementations with respect to that program.
3   For classes and class templates, the library clauses specify partial definitions. Private members (clause 11)
    are not specified, but each implementation shall supply them to complete the definitions according to the
    description in the library clauses.
4   For functions, function templates, objects, and values, the library clauses specify declarations. Implementa-
    tions shall supply definitions consistent with the descriptions in the library clauses.
5   The names defined in the library have namespace scope (7.3). A C++ translation unit (2.1) obtains access
    to these names by including the appropriate standard library header (16.2).
6   The templates, classes, functions, and objects in the library have external linkage (3.5). The implementa-
    tion provides definitions for standard library entities, as necessary, while combining translation units to
    form a complete C++ program (2.1).
7   Two kinds of implementations are defined: hosted and freestanding. For a hosted implementation, this
    International Standard defines the set of available libraries. A freestanding implementation is one in which
    execution may take place without the benefit of an operating system, and has an implementation-defined set
    of libraries that includes certain language-support libraries (17.4.1.3).
8   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, how-
    ever, they can compile and execute such programs.




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




                                                                                                                                 3
    ISO/IEC 14882:1998(E)                                                                              © ISO/IEC

    1.5 Structure of this International Standard                                                        1 General



    1.5 Structure of this International Standard                                                 [intro.structure]
1   Clauses 2 through 16 describe the C++ programming language. That description includes detailed syntactic
    specifications in a form described in 1.6. For convenience, Annex A repeats all such syntactic specifica-
    tions.
2   Clauses 17 through 27 (the library clauses) describe the Standard C++ library, which provides definitions
    for the following kinds of entities: macros (16.3), values (clause 3), types (8.1, 8.3), templates (clause 14),
    classes (clause 9), functions (8.3.5), and objects (clause 7).
3   Annex B recommends lower bounds on the capacity of conforming implementations.
4   Annex C summarizes the evolution of C++ since its first published description, and explains in detail the
    differences between C++ and C. Certain features of C++ exist solely for compatibility purposes; Annex D
    describes those features.
5   Finally, Annex E says what characters are valid in universal-character names in C++ identifiers (2.10).
6   Throughout this International Standard, each example is introduced by "[Example:" and terminated by "]".
    Each note is introduced by "[Note:" and terminated by "]". Examples and notes may be nested.

    1.6 Syntax notation                                                                                   [syntax]
1   In the syntax notation used in this International Standard, syntactic categories are indicated by italic type,
    and literal words and characters in constant width type. Alternatives are listed on separate lines
    except in a few cases where a long set of alternatives is presented on one line, marked by the phrase "one
    of." An optional terminal or nonterminal symbol is indicated by the subscript "opt," so
         { expressionopt }

    indicates an optional expression enclosed in braces.
2   Names for syntactic categories have generally been chosen according to the following rules:
    -- X-name is a use of an identifier in a context that determines its meaning (e.g. class-name, typedef-
       name).
    -- X-id is an identifier with no context-dependent meaning (e.g. qualified-id).
    -- X-seq is one or more X's without intervening delimiters (e.g. declaration-seq is a sequence of declara-
       tions).
    -- X-list is one or more X's separated by intervening commas (e.g. expression-list is a sequence of expres-
       sions separated by commas).

    1.7 The C++ memory model                                                                      [intro.memory]
1   The fundamental storage unit in the C++ memory model is the byte. A byte is at least large enough to con-
    tain any member of the basic execution character set and is composed of a contiguous sequence of bits, the
    number of which is implementation-defined. The least significant bit is called the low-order bit; the most
    significant bit is called the high-order bit. The memory available to a C++ program consists of one or more
    sequences of contiguous bytes. Every byte has a unique address.
2   [Note: the representation of types is described in 3.9. ]

    1.8 The C++ object model                                                                        [intro.object]
1   The constructs in a C++ program create, destroy, refer to, access, and manipulate objects. An object is 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. ] An object is created by a definition (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 influences 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.


    4
    © ISO/IEC                                                                                                ISO/IEC 14882:1998(E)

    1 General                                                                                                 1.8 The C++ object model



    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.
2   Objects can contain other objects, called sub-objects. A sub-object can be a member sub-object (9.2), a
    base class sub-object (clause 10), or an array element. An object that is not a sub-object of any other object
    is called a complete object.
3   For every object x, there is some object called the complete object of x, determined as follows:
    -- If x is a complete object, then x is the complete object of x.
    -- Otherwise, the complete object of x is the complete object of the (unique) object that contains x.
4   If a complete object, a data member (9.2), or an array element is of class type, its type is considered the
    most derived class, to distinguish it from the class type of any base class subobject; an object of a most
    derived class type is called a most derived object.
5   Unless it is a bit-field (9.6), a most derived object shall have a non-zero size and shall occupy one or more
    bytes of storage. Base class sub-objects may have zero size. An object of POD4) type (3.9) shall occupy
    contiguous bytes of storage.
6   [Note: C++ provides a variety of built-in types and several ways of composing new types from existing
    types (3.9). ]

    1.9 Program execution                                                                                              [intro.execution]
1   The semantic descriptions in this International Standard define a parameterized nondeterministic abstract
    machine. This International Standard places no requirement on the structure of conforming implementa-
    tions. In particular, they need not copy or emulate the structure of the abstract machine. Rather, conform-
    ing implementations are required to emulate (only) the observable behavior of the abstract machine as
    explained below.5)
2   Certain aspects and operations of the abstract machine are described in this International Standard as
    implementation-defined (for example, sizeof(int)). These constitute the parameters of the abstract
    machine. Each implementation shall include documentation describing its characteristics and behavior in
    these respects. Such documentation shall define the instance of the abstract machine that corresponds to
    that implementation (referred to as the ``corresponding instance'' below).
3   Certain other aspects and operations of the abstract machine are described in this International Standard as
    unspecified (for example, order of evaluation of arguments to a function). Where possible, this Interna-
    tional Standard defines a set of allowable behaviors. These define the nondeterministic aspects of the
    abstract machine. An instance of the abstract machine can thus have more than one possible execution
    sequence for a given program and a given input.
4   Certain other operations are described in this International Standard as undefined (for example, the effect of
    dereferencing the null pointer). [Note: this International Standard imposes no requirements on the behavior
    of programs that contain undefined behavior. ]
5   A conforming implementation executing a well-formed program shall produce the same observable behav-
    ior as one of the possible execution sequences of the corresponding instance of the abstract machine with
    the same program and the same input. However, if any such execution sequence contains an undefined
    operation, this International Standard places no requirement on the implementation executing that program
    __________________
    4) The acronym POD stands for "plain old data."
    5) This provision is sometimes called the "as-if" rule, because an implementation is free to disregard any requirement of this Interna-
    tional Standard as long as the result is as if the requirement had been obeyed, as far as can be determined from the observable behavior
    of the program. For instance, an actual implementation need not evaluate part of an expression if it can deduce that its value is not used
    and that no side effects affecting the observable behavior of the program are produced.




                                                                                                                                            5
     ISO/IEC 14882:1998(E)                                                                                                    © ISO/IEC

     1.9 Program execution                                                                                                      1 General



     with that input (not even with regard to operations preceding the first undefined operation).
6    The observable behavior of the abstract machine is its sequence of reads and writes to volatile data and
     calls to library I/O functions.6)
7    Accessing an object designated by a volatile lvalue (3.10), modifying an object, calling a library I/O
     function, or calling a function that does any of those operations are all side effects, which are changes in the
     state of the execution environment. Evaluation of an expression might produce side effects. At certain
     specified points in the execution sequence called sequence points, all side effects of previous evaluations
     shall be complete and no side effects of subsequent evaluations shall have taken place.7)
8    Once the execution of a function begins, no expressions from the calling function are evaluated until execu-
     tion of the called function has completed.8)
9    When the processing of the abstract machine is interrupted by receipt of a signal, the values of objects with
     type other than volatile sig_atomic_t are unspecified, and the value of any object not of
     volatile sig_atomic_t that is modified by the handler becomes undefined.
10   An instance of each object with automatic storage duration (3.7.2) 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).
11   The least requirements on a conforming implementation are:
     -- At sequence points, volatile objects are stable in the sense that previous evaluations are complete and
        subsequent evaluations have not yet occurred.
     -- At program termination, all data written into files shall be identical to one of the possible results that
        execution of the program according to the abstract semantics would have produced.
     -- The input and output dynamics of interactive devices shall take place in such a fashion that prompting
        messages actually appear prior to a program waiting for input. What constitutes an interactive device is
        implementation-defined.
     [Note: more stringent correspondences between abstract and actual semantics may be defined by each
     implementation. ]
12   A full-expression is an expression that is not a subexpression of another expression. If a language construct
     is defined 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 definition.
13   [Note: certain contexts in C++ cause the evaluation of a full-expression that results from a syntactic con-
     struct other than expression (5.18). For example, in 8.5 one syntax for initializer is
           ( expression-list )

     but the resulting construct is a function call upon a constructor function with expression-list as an argument
     list; such a function call is a full-expression. For example, in 8.5, another syntax for initializer is
           = initializer-clause

     but again the resulting construct might be a function call upon a constructor function with one assignment-
     expression as an argument; again, the function call is a full-expression. ]

     __________________
     6) An implementation can offer additional library I/O functions as an extension. Implementations that do so should treat calls to those
     functions as ``observable behavior'' as well.
     7) Note that some aspects of sequencing in the abstract machine are unspecified; the preceding restriction upon side effects applies to
     that particular execution sequence in which the actual code is generated. Also note that when a call to a library I/O function returns,
     the side effect is considered complete, even though some external actions implied by the call (such as the I/O itself) may not have com-
     pleted yet.
     8) In other words, function executions do not interleave with each other.




     6
     © ISO/IEC                                                                                              ISO/IEC 14882:1998(E)

     1 General                                                                                                   1.9 Program execution



14   [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 argument expres-
     sions (8.3.6) are considered to be created in the expression that calls the function, not the expression that
     defines the default argument. ]
15   [Note: operators can be regrouped according to the usual mathematical rules only where the operators really
     are associative or commutative.9) 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 overflows 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));

     since the values for a and b might have been, respectively, 4 and ­ 8 or ­ 17 and 12. However on a
     machine in which overflows do not produce an exception and in which the results of overflows are
     reversible, the above expression statement can be rewritten by the implementation in any of the above ways
     because the same result will occur. ]
16   There is a sequence point at the completion of evaluation of each full-expression10).
17   When calling a function (whether or not the function is inline), there is a sequence point after the evaluation
     of all function arguments (if any) which takes place before execution of any expressions or statements in
     the function body. There is also a sequence point after the copying of a returned value and before the exe-
     cution of any expressions outside the function11). Several contexts in C++ cause evaluation of a function
     call, even though no corresponding function call syntax appears in the translation unit. [Example: evalua-
     tion 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. ] The sequence points at function-entry and function-exit (as described above) are features of the
     function calls as evaluated, whatever the syntax of the expression that calls the function might be.
18   In the evaluation of each of the expressions
           a   && b
           a   || b
           a   ? b : c
           a   , b
     using the built-in meaning of the operators in these expressions (5.14, 5.15, 5.16, 5.18), there is a sequence
     __________________
     9) Overloaded operators are never assumed to be associative or commutative.
     10) As specified in 12.2, after the "end-of-full-expression" sequence point, a sequence of zero or more invocations of destructor func-
     tions for temporary objects takes place, usually in reverse order of the construction of each temporary object.
     11) The sequence point at the function return is not explicitly specified in ISO C, and can be considered redundant with sequence
     points at full-expressions, but the extra clarity is important in C++. In C++, there are more ways in which a called function can termi-
     nate its execution, such as the throw of an exception.




                                                                                                                                           7
    ISO/IEC 14882:1998(E)                                                                                                      © ISO/IEC

    1.9 Program execution                                                                                                        1 General



    point after the evaluation of the first expression12).

    1.10 Acknowledgments                                                                                                       [intro.ack]
1   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 edi-
    tion, Addison-Wesley Publishing Company, ISBN 0­ 201­ 53992­ 6, copyright © 1991 AT&T). That, in
    turn, is based on the C programming language as described in Appendix A of Kernighan and Ritchie: The C
    Programming Language (Prentice-Hall, 1978, ISBN 0­ 13­ 110163­ 3, copyright © 1978 AT&T).
2   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 © 1995
    P.J. Plauger).
3   All rights in these originals are reserved.




    __________________
    12) The operators indicated in this paragraph are the built-in operators, as described in clause 5. When one of these operators is over-
    loaded (clause 13) in a valid context, thus designating a user-defined operator function, the expression designates a function invocation,
    and the operands form an argument list, without an implied sequence point between them.




    8
    © ISO/IEC                                                                                                 ISO/IEC 14882:1998(E)




    2 Lexical conventions                                                                                                             [lex]
1   The text of the program is kept in units called source files in this International Standard. A source file
    together with all the headers (17.4.1.2) and source files included (16.2) via the preprocessing directive
    #include, less any source lines skipped by any of the conditional inclusion (16.1) preprocessing direc-
    tives, is called a translation unit. [Note: a C++ program need not all be translated at the same time. ]
2   [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 identifiers have external linkage, manipulation of objects whose identifiers have external linkage, or
    manipulation of data files. Translation units can be separately translated and then later linked to produce an
    executable program. (3.5). ]

    2.1 Phases of translation                                                                                                  [lex.phases]
                                                                                                                        13)
1   The precedence among the syntax rules of translation is specified by the following phases.
    1 Physical source file characters are mapped, in an implementation-defined manner, to the basic source
      character set (introducing new-line characters for end-of-line indicators) if necessary. Trigraph
      sequences (2.3) are replaced by corresponding single-character internal representations. Any source file
      character not in the basic source character set (2.2) is replaced by the universal-character-name that des-
      ignates that character. (An implementation may use any internal encoding, so long as an actual
      extended character encountered in the source file, and the same extended character expressed in the
      source file as a universal-character-name (i.e. using the \uXXXX notation), are handled equivalently.)
    2 Each instance of a new-line character and an immediately preceding backslash character is deleted,
      splicing physical source lines to form logical source lines. If, as a result, a character sequence that
      matches the syntax of a universal-character-name is produced, the behavior is undefined. If a source
      file that is not empty does not end in a new-line character, or ends in a new-line character immediately
      preceded by a backslash character, the behavior is undefined.
    3 The source file is decomposed into preprocessing tokens (2.4) and sequences of white-space characters
      (including comments). A source file shall not end in a partial preprocessing token or partial com-
      ment14). 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 implementation-defined. The process of dividing a source file's characters into pre-
      processing tokens is context-dependent. [Example: see the handling of < within a #include prepro-
      cessing directive. ]
    4 Preprocessing directives are executed and macro invocations are expanded. If a character sequence that
      matches the syntax of a universal-character-name is produced by token concatenation (16.3.3), the
      behavior is undefined. A #include preprocessing directive causes the named header or source file to
      be processed from phase 1 through phase 4, recursively.
    5 Each source character set member, escape sequence, or universal-character-name in character literals
      and string literals is converted to a member of the execution character set (2.13.2, 2.13.4).
    6 Adjacent ordinary string literal tokens are concatenated. Adjacent wide string literal tokens are concate-
      nated.
    7 White-space characters separating tokens are no longer significant. Each preprocessing token is
    __________________
    13) Implementations must behave as if these separate phases occur, although in practice different phases might be folded together.
    14) A partial preprocessing token would arise from a source file ending in the first portion of a multi-character token that requires a ter-
    minating sequence of characters, such as a header-name that is missing the closing " or >. A partial comment would arise from a
    source file ending with an unclosed /* comment.




                                                                                                                                              9
    ISO/IEC 14882:1998(E)                                                                                                  © ISO/IEC

    2.1 Phases of translation                                                                                 2 Lexical conventions



         converted into a token. (2.6). The resulting tokens are syntactically and semantically analyzed and
         translated. [Note: Source files, translation units and translated translation units need not necessarily be
         stored as files, nor need there be any one-to-one correspondence between these entities and any external
         representation. The description is conceptual only, and does not specify any particular implementation.
         ]
    8 Translated translation units and instantiation units are combined as follows: [Note: some or all of these
      may be supplied from a library. ] 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). ] The definitions of the required templates are located. It is implementation-defined whether
      the source of the translation units containing these definitions is required to be available. [Note: an
      implementation could encode sufficient information into the translated translation unit so as to ensure
      the source is not required here. ] All the required instantiations are performed to produce instantiation
      units. [Note: these are similar to translated translation units, but contain no references to uninstantiated
      templates and no template definitions. ] The program is ill-formed if any instantiation fails.
    9 All external object and function references are resolved. Library components are linked to satisfy exter-
      nal references to functions and objects not defined in the current translation. All such translator output
      is collected into a program image which contains information needed for execution in its execution
      environment.

    2.2 Character sets                                                                                                  [lex.charset]
1   The basic source character set consists of 96 characters: the space character, the control characters repre-
    senting horizontal tab, vertical tab, form feed, and new-line, plus the following 91 graphical characters:15)
          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

          universal-character-name:
                      \u hex-quad
                      \U hex-quad hex-quad
    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 is less than 0x20 or in the range 0x7F-0x9F (inclusive), or if the uni-
    versal character name designates a character in the basic source character set, then the program is ill-
    formed.
3   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 car-
    riage 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. The execution character set and the execution wide-character set are 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 are implementation-defined, and any additional members are locale-specific.
    __________________
    15) The glyphs for the members of the basic source character set are intended to identify characters from the subset of ISO/IEC 10646
    which corresponds to the ASCII character set. However, because the mapping from source file characters to the source character set
    (described in translation phase 1) is specified as implementation-defined, an implementation is required to document how the basic
    source characters are represented in source files.




    10
    © ISO/IEC                                                                           ISO/IEC 14882:1998(E)

    2 Lexical conventions                                                                  2.3 Trigraph sequences



    2.3 Trigraph sequences                                                                         [lex.trigraph]
1   Before any other processing takes place, each occurrence of one of the following sequences of three charac-
    ters ("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]

    --end example]
3   No other trigraph sequence exists. Each ? that does not begin one of the trigraphs listed above is not
    changed.

    2.4 Preprocessing tokens                                                                       [lex.pptoken]
         preprocessing-token:
                    header-name
                    identifier
                    pp-number
                    character-literal
                    string-literal
                    preprocessing-op-or-punc
                    each non-white-space character that cannot be one of the above

1   Each preprocessing token that is converted to a token (2.6) shall have the lexical form of a keyword, an
    identifier, a literal, an operator, or a punctuator.
2   A preprocessing token is the minimal lexical element of the language in translation phases 3 through 6.
    The categories of preprocessing token are: header names, identifiers, preprocessing numbers, character
    literals, string literals, preprocessing-op-or-punc, and single non-white-space characters that do not lexi-
    cally match the other preprocessing token categories. If a ' or a " character matches the last category, the
    behavior is undefined. Preprocessing tokens can be separated by white space; this consists of comments
    (2.7), 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 preprocess-
    ing token only as part of a header name or between the quotation characters in a character literal or string
    literal.
3   If the input stream has been parsed into preprocessing tokens up to a given character, the next preprocessing
    token is the longest sequence of characters that could constitute a preprocessing token, even if that would
    cause further lexical analysis to fail.
4   [Example: The program fragment 1Ex is parsed as a preprocessing number token (one that is not a valid
    floating or integer literal token), even though a parse as the pair of preprocessing tokens 1 and Ex might
    produce a valid expression (for example, if Ex were a macro defined as +1). Similarly, the program frag-
    ment 1E1 is parsed as a preprocessing number (one that is a valid floating literal token), whether or not E is
    a macro name. ]


                                                                                                               11
    ISO/IEC 14882:1998(E)                                                                                                     © ISO/IEC

    2.4 Preprocessing tokens                                                                                       2 Lexical conventions



5   [Example: The program fragment x+++++y is parsed as x ++ ++ + y, which, if x and y are of built-in
    types, violates a constraint on increment operators, even though the parse x ++ + ++ y might yield a
    correct expression. ]

    2.5 Alternative tokens                                                                                                 [lex.digraph]
                                                                                                            16)
1   Alternative token representations are provided for some operators and punctuators                          .
2   In all respects of the language, each alternative token behaves the same, respectively, as its primary token,
    except for its spelling17). The set of alternative tokens is defined in Table 2.


                                                   Table 2--alternative tokens
                       _
                       ______________________________________________________________
                        alternative primary  alternative primary  alternative primary 
                       _
                       ______________________________________________________________
                       _
                       ______________________________________________________________
                                                                 
                       _
                       ______________________________________________________________
                            <%         {        and        &&     and_eq        &=
                       ______________________________________________________________
                       _    %>         }     bitor          |     or_eq         |=
                                                                  xor_eq              
                       _
                       ______________________________________________________________
                       
                            <:         [
                                            
                                                 or        ||
                                                                 
                                                                                ^=
                       _
                       ______________________________________________________________
                            :>         ]        xor         ^        not         !
                       ______________________________________________________________
                       _    %:         #     compl          ~     not_eq        !=
                                                                                      
                       _ %:%:
                       ______________________________________________________________
                                      ##     bitand         &    


    2.6 Tokens                                                                                                                [lex.token]
          token:
                        identifier
                        keyword
                        literal
                        operator
                        punctuator

1   There are five kinds of tokens: identifiers, keywords, literals,18) operators, and other separators. Blanks,
    horizontal and vertical tabs, newlines, formfeeds, and comments (collectively, "white space"), as described
    below, are ignored except as they serve to separate tokens. [Note: Some white space is required to separate
    otherwise adjacent identifiers, keywords, numeric literals, and alternative tokens containing alphabetic
    characters. ]

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




    __________________
    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 <: will be different, maintaining the source spelling, but the tokens can otherwise be
    freely interchanged.
    18) Literals include strings and character and numeric literals.




    12
    © ISO/IEC                                                                                    ISO/IEC 14882:1998(E)

    2 Lexical conventions                                                                              2.8 Header names



    2.8 Header names                                                                                       [lex.header]
          header-name:
                    <h-char-sequence>
                    "q-char-sequence"

          h-char-sequence:
                     h-char
                     h-char-sequence h-char

          h-char:
                        any member of the source character set except
                                 new-line and >

          q-char-sequence:
                     q-char
                     q-char-sequence q-char

          q-char:
                        any member of the source character set except
                                 new-line and "

1   Header name preprocessing tokens shall only appear within a #include preprocessing directive (16.2).
    The sequences in both forms of header-names are mapped in an implementation-defined manner to headers
    or to external source file names as specified in 16.2.
2   If either of the characters ' or \, or either of the character sequences /* or // appears in a q-char-
    sequence or a h-char-sequence, or the character " appears in a h-char-sequence, the behavior is unde-
    fined.19)

    2.9 Preprocessing numbers                                                                           [lex.ppnumber]
          pp-number:
                        digit
                        . digit
                        pp-number digit
                        pp-number nondigit
                        pp-number e sign
                        pp-number E sign
                        pp-number .

1   Preprocessing number tokens lexically include all integral literal tokens (2.13.1) and all floating literal
    tokens (2.13.3).
2   A preprocessing number does not have a type or a value; it acquires both after a successful conversion (as
    part of translation phase 7, 2.1) to an integral literal token or a floating literal token.

    2.10 Identifiers                                                                                        [lex.name]
          identifier:
                        nondigit
                        identifier nondigit
                        identifier digit




    __________________
    19) Thus, sequences of characters that resemble escape sequences cause undefined behavior.




                                                                                                                    13
    ISO/IEC 14882:1998(E)                                                                                                   © ISO/IEC

    2.10 Identifiers                                                                                            2 Lexical conventions



          nondigit: one of
                     universal-character-name
                     _ a b c d e f g h                i   j   k   l   m
                        n o p q r s t u               v   w   x   y   z
                        A B C D E F G H               I   J   K   L   M
                        N O P Q R S T U               V   W   X   Y   Z

          digit: one of
                     0 1 2 3 4 5 6 7 8 9

1   An identifier is an arbitrarily long sequence of letters and digits. Each universal-character-name in an iden-
    tifier shall designate a character whose encoding in ISO 10646 falls into one of the ranges specified in
    Annex E. Upper- and lower-case letters are different. All characters are significant.20)
2   In addition, some identifiers are reserved for use by C++ implementations and standard libraries (17.4.3.1.2)
    and shall not be used otherwise; no diagnostic is required.

    2.11 Keywords                                                                                                              [lex.key]
1   The identifiers shown in Table 3 are reserved for use as keywords (that is, they are unconditionally treated
    as keywords in phase 7):


                                                          Table 3--keywords
       _
       __________________________________________________________________________________
        asm            do               if                    return          typedef 
        auto           double           inline                short           typeid     
                                                                                         
        bool           dynamic_cast     int                   signed          typename 
        break          else             long                  sizeof          union      
        case           enum             mutable               static          unsigned 
        catch          explicit         namespace             static_cast     using      
        char           export           new                   struct          virtual 
                                                                                         
        class          extern           operator              switch          void       
        const          false            private               template        volatile 
        const_cast     float            protected             this            wchar_t 
        continue       for              public                throw           while      
        default        friend           register              true                       
                                                                                         
       __________________________________________________________________________________
       _delete         goto             reinterpret_cast      try

2   Furthermore, the alternative representations shown in Table 4 for certain operators and punctuators (2.5) are
    reserved and shall not be used otherwise:


                                            Table 4--alternative representations
                            _
                            _______________________________________________________
                             and       and_eq    bitand    bitor    compl     not 
                             not_eq                                                
                            _______________________________________________________
                            _          or        or_eq     xor      xor_eq



    __________________
    20) On systems in which linkers cannot accept extended characters, an encoding of the universal-character-name may be used in form-
    ing valid external identifiers. For example, some otherwise unused character or sequence of characters may be used to encode the \u
    in a universal-character-name. Extended characters may produce a long external identifier, but C++ does not place a translation limit
    on significant characters for external identifiers. In C++, upper- and lower-case letters are considered different for all identifiers,
    including external identifiers.




    14
    © ISO/IEC                                                                                                   ISO/IEC 14882:1998(E)

    2 Lexical conventions                                                                              2.12 Operators and punctuators



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

    2.13 Literals                                                                                                               [lex.literal]
1   There are several kinds of literals.21)
          literal:
                        integer-literal
                        character-literal
                        floating-literal
                        string-literal
                        boolean-literal


    2.13.1 Integer literals                                                                                                       [lex.icon]
          integer-literal:
                       decimal-literal integer-suffixopt
                       octal-literal integer-suffixopt
                       hexadecimal-literal integer-suffixopt

          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




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




                                                                                                                                         15
    ISO/IEC 14882:1998(E)                                                                                © ISO/IEC

    2.13.1 Integer literals                                                                   2 Lexical conventions



           hexadecimal-digit:      one of
                     0 1           2 3        4    5   6   7   8   9
                     a b           c d        e    f
                     A B           C D        E    F

           integer-suffix:
                        unsigned-suffix long-suffixopt
                        long-suffix unsigned-suffixopt

           unsigned-suffix: one of
                      u U

           long-suffix: one of
                       l L

1   An integer literal is a sequence of digits that has no period or exponent part. An integer literal may have a
    prefix that specifies its base and a suffix that specifies its type. The lexically first digit of the sequence of
    digits is the most significant. A decimal integer literal (base ten) begins with a digit other than 0 and con-
    sists of a sequence of decimal digits. An octal integer literal (base eight) begins with the digit 0 and con-
    sists 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 fifteen. [Example: the number twelve can be written 12,
    014, or 0XC. ]
2   The type of an integer literal depends on its form, value, and suffix. If it is decimal and has no suffix, it has
    the first of these types in which its value can be represented: int, long int; if the value cannot be repre-
    sented as a long int, the behavior is undefined. If it is octal or hexadecimal and has no suffix, it has the
    first of these types in which its value can be represented: int, unsigned int, long int, unsigned
    long int. If it is suffixed by u or U, its type is the first of these types in which its value can be repre-
    sented: unsigned int, unsigned long int. If it is suffixed by l or L, its type is the first of these
    types in which its value can be represented: long int, unsigned long int. If it is suffixed by ul,
    lu, uL, Lu, Ul, lU, UL, or LU, its type is unsigned long int.
3   A program is ill-formed if one of its translation units contains an integer literal that cannot be represented
    by any of the allowed types.

    2.13.2 Character literals                                                                             [lex.ccon]
           character-literal:
                       '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




    __________________
    22) The digits 8 and 9 are not octal digits.




    16
    © ISO/IEC                                                                                     ISO/IEC 14882:1998(E)

    2 Lexical conventions                                                                          2.13.2 Character literals



           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

1   A character literal is one or more characters enclosed in single quotes, as in 'x', optionally preceded by
    the letter L, as in L'x'. A character literal that does not begin with 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 multicharac-
    ter literal has type int and implementation-defined value.
2   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. The value of
    a wide-character literal containing multiple c-chars is implementation-defined.
3   Certain nongraphic characters, the single quote ', the double quote ", the question mark ?, and the back-
    slash \, can be represented according to Table 5.


                                                     Table 5--escape sequences
                                                 _
                                                 ______________________________
                                                  new-line        NL (LF) \n    
                                                  horizontal tab  HT      \t    
                                                                                
                                                  vertical tab    VT      \v    
                                                  backspace       BS      \b    
                                                  carriage return CR      \r    
                                                  form feed       FF      \f    
                                                  alert           BEL     \a    
                                                                                
                                                  backslash       \       \\    
                                                  question mark   ?       \?    
                                                  single quote    '       \'    
                                                  double quote    "       \"    
                                                  octal number    ooo     \ooo 
                                                                                
                                                 ______________________________
                                                 _hex number      hhh     \xhhh

    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. If the character following a backslash is not one of those specified, the
    behavior is undefined. An escape sequence specifies a single character.
    __________________
    23) They are intended for character sets where a character does not fit into a single byte.




                                                                                                                         17
    ISO/IEC 14882:1998(E)                                                                                © ISO/IEC

    2.13.2 Character literals                                                                 2 Lexical conventions



4   The escape \ooo consists of the backslash followed by one, two, or three octal digits that are taken to spec-
    ify 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 ter-
    minated by the first character that is not an octal digit or a hexadecimal digit, respectively. The value of a
    character literal is implementation-defined if it falls outside of the implementation-defined range defined
    for char (for ordinary literals) or wchar_t (for wide literals).
5   A universal-character-name is translated to the encoding, in the execution character set, of the character
    named. If there is no such encoding, the universal-character-name is translated to an implementation-
    defined encoding. [Note: in translation phase 1, a universal-character-name is introduced whenever an
    actual extended character is encountered in the source text. Therefore, all extended characters are described
    in terms of universal-character-names. However, the actual compiler implementation may use its own
    native character set, so long as the same results are obtained. ]

    2.13.3 Floating literals                                                                              [lex.fcon]
         floating-literal:
                      fractional-constant exponent-partopt floating-suffixopt
                      digit-sequence exponent-part floating-suffixopt

         fractional-constant:
                     digit-sequenceopt . digit-sequence
                     digit-sequence .

         exponent-part:
                    e signopt digit-sequence
                    E signopt digit-sequence

         sign: one of
                    +     -

         digit-sequence:
                     digit
                     digit-sequence digit

         floating-suffix: one of
                      f l F        L

1   A floating 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 suffix. 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 significant part of the floating literal. The
    exponent, if present, indicates the power of 10 by which the significant 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-defined
    manner. The type of a floating literal is double unless explicitly specified by a suffix. The suffixes f and
    F specify float, the suffixes 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.




    18
    © ISO/IEC                                                                             ISO/IEC 14882:1998(E)

    2 Lexical conventions                                                                     2.13.3 Floating literals



    2.13.4 String literals                                                                               [lex.string]
         string-literal:
                      "s-char-sequenceopt"
                      L"s-char-sequenceopt"

         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

1   A string literal is a sequence of characters (as defined in 2.13.2) surrounded by double quotes, optionally
    beginning with the letter L, as in "..." or L"...". A string literal that does not begin with L is an ordi-
    nary string literal, also referred to as a narrow string literal. An ordinary string literal has type "array of n
    const char" and static storage duration (3.7), where n is the size of the string as defined below, 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" and has static storage duration, where
    n is the size of the string as defined below, and is initialized with the given characters.
2   Whether all string literals are distinct (that is, are stored in nonoverlapping objects) is implementation-
    defined. The effect of attempting to modify a string literal is undefined.
3   In translation phase 6 (2.1), adjacent narrow string literals are concatenated and adjacent wide string literals
    are concatenated. If a narrow string literal token is adjacent to a wide string literal token, the behavior is
    undefined. Characters in concatenated strings are kept distinct. [Example:
         "\xA" "B"

    contains the two characters '\xA' and 'B' after concatenation (and not the single hexadecimal character
    '\xAB'). ]
4   After any necessary concatenation, in translation phase 7 (2.1), '\0' is appended to every string literal so
    that programs that scan a string can find its end.
5   Escape sequences and universal-character-names in string literals have the same meaning as in character lit-
    erals (2.13.2), 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-character-name may
    map to more than one char element due to multibyte encoding. The size of a wide string literal is the total
    number of escape sequences, universal-character-names, and other characters, plus one for the terminating
    L'\0'. 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.13.5 Boolean literals                                                                               [lex.bool]
         boolean-literal:
                     false
                     true

1   The Boolean literals are the keywords false and true. Such literals have type bool. They are not lval-
    ues.




                                                                                                                  19
ISO/IEC 14882:1998(E)                  ©   ISO/IEC




                        (Blank page)




20
    © ISO/IEC                                                                                             ISO/IEC 14882:1998(E)

    3 Basic concepts                                                                                                  3 Basic concepts




    3 Basic concepts                                                                                                       [basic]
1   [Note: this clause presents the basic concepts of the C++ language. It explains the difference between an
    object and a name and how they relate to the notion of an lvalue. It introduces the concepts of a declaration
    and a definition and presents C++'s notion of type, scope, linkage, and storage duration. The mechanisms
    for starting and terminating a program are discussed. Finally, this clause presents the fundamental types of
    the language and lists the ways of constructing compound types from these.
2   This clause does not cover concepts that affect only a single part of the language. Such concepts are dis-
    cussed in the relevant clauses. ]
3   An entity is a value, object, subobject, base class subobject, array element, variable, function, instance of a
    function, enumerator, type, class member, template, or namespace.
4   A name is a use of an identifier (2.10) that denotes an entity or label (6.6.4, 6.1). A variable is introduced
    by the declaration of an object. The variable's name denotes the object.
5   Every name that denotes an entity is introduced by a declaration. Every name that denotes a label is intro-
    duced either by a goto statement (6.6.4) or a labeled-statement (6.1).
6   Some names denote types, classes, enumerations, or templates. In general, it is necessary to determine
    whether or not a name denotes one of these entities before parsing the program that contains it. The process
    that determines this is called name lookup (3.4).
7   Two names are the same if
    -- they are identifiers composed of the same character sequence; or
    -- they are the names of overloaded operator functions formed with the same operator; or
    -- they are the names of user-defined conversion functions formed with the same type.
8   An identifier used in more than one translation unit can potentially refer to the same entity in these transla-
    tion units depending on the linkage (3.5) of the identifier specified in each translation unit.

    3.1 Declarations and definitions                                                                                        [basic.def]
1   A declaration (clause 7) introduces names into a translation unit or redeclares names introduced by previous
    declarations. A declaration specifies the interpretation and attributes of these names.
2   A declaration is a definition unless it declares a function without specifying the function's body (8.4), it
    contains the extern specifier (7.1.1) or a linkage-specification24) (7.5) and neither an initializer nor a
    function-body, it declares a static data member in a class declaration (9.4), it is a class name declaration
    (9.1), or it is a typedef declaration (7.1.3), a using-declaration (7.3.3), or a using-directive (7.3.4).




    __________________
    24) Appearing inside the braced-enclosed declaration-seq in a linkage-specification does not affect whether a declaration is a defini-
    tion.




                                                                                                                                      21
    ISO/IEC 14882:1998(E)                                                                                  © ISO/IEC

    3.1 Declarations and definitions                                                              3 Basic concepts



3   [Example: all but one of the following are definitions:
         int a;                                      // defines a
         extern const int c = 1;                     // defines c
         int f(int x) { return x+a; }                // defines f and defines x
         struct S { int a; int b; };                 // defines S, S::a, and S::b
         struct X {                                  // defines X
             int x;                                  // defines nonstatic data member x
             static int y;                           // declares static data member y
             X(): x(0) { }                           // defines a constructor of X
         };
         int X::y = 1;                               // defines X::y
         enum { up, down };                          // defines up and down
         namespace N { int d; }                      // defines N and N::d
         namespace N1 = N;                           // defines N1
         X anX;                                      // defines anX
    whereas these are just declarations:
         extern int a;                               // declares a
         extern const int c;                         // declares c
         int f(int);                                 // declares f
         struct S;                                   // declares S
         typedef int Int;                            // declares Int
         extern X anotherX;                          // declares anotherX
         using N::d;                                 // declares N::d
    --end example]
4   [Note: in some circumstances, C++ implementations implicitly define the default constructor (12.1), copy
    constructor (12.8), assignment operator (12.8), or destructor (12.4) member functions. [Example: given
         struct C {
             string s;                               // string is the standard library class (clause 21)
         };

         int main()
         {
             C a;
             C b = a;
             b = a;
         }
    the implementation will implicitly define functions to make the definition of C equivalent to
         struct C {
             string s;
             C(): s() { }
             C(const C& x): s(x.s) { }
             C& operator=(const C& x) { s = x.s; return *this; }
             ~C() { }
         };
    --end example] --end note]
5   [Note: a class name can also be implicitly declared by an elaborated-type-specifier (3.3.1). ]
6   A program is ill-formed if the definition of any object gives the object an incomplete type (3.9).

    3.2 One definition rule                                                                         [basic.def.odr]
1   No translation unit shall contain more than one definition of any variable, function, class type, enumeration
    type or template.




    22
    © ISO/IEC                                                                              ISO/IEC 14882:1998(E)

    3 Basic concepts                                                                           3.2 One definition rule



2   An expression is potentially evaluated unless either it is the operand of the sizeof operator (5.3.3), or it is
    the operand of the typeid operator and does not designate an lvalue of polymorphic class type (5.2.8).
    An object or non-overloaded function is used if its name appears in a potentially-evaluated expression. A
    virtual member function is used if it is not pure. An overloaded function is used if it is selected by overload
    resolution when referred to from a potentially-evaluated expression. [Note: this covers calls to named func-
    tions (5.2.2), operator overloading (clause 13), user-defined conversions (12.3.2), allocation function for
    placement new (5.3.4), as well as non-default initialization (8.5). A copy constructor is used even if the call
    is actually elided by the implementation. ] An allocation or deallocation function for a class is used by a
    new expression appearing in a potentially-evaluated expression as specified in 5.3.4 and 12.5. A dealloca-
    tion function for a class is used by a delete expression appearing in a potentially-evaluated expression as
    specified in 5.3.5 and 12.5. A copy-assignment function for a class is used by an implicitly-defined copy-
    assignment function for another class as specified in 12.8. A default constructor for a class is used by
    default initialization as specified in 8.5. A constructor for a class is used as specified in 8.5. A destructor
    for a class is used as specified in 12.4.
3   Every program shall contain exactly one definition of every non-inline function or object that is used in that
    program; no diagnostic required. The definition can appear explicitly in the program, it can be found in the
    standard or a user-defined library, or (when appropriate) it is implicitly defined (see 12.1, 12.4 and 12.8).
    An inline function shall be defined in every translation unit in which it is used.
4   Exactly one definition 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 defines X:
         struct X;                                       // declare X as a struct type
         struct X* x1;                                   // use X in pointer formation
         X* x2;                                          // use X in pointer formation
     --end example] [Note: the rules for declarations and expressions describe in which contexts complete class
    types are required. A class type T must be complete if:
    -- an object of type T is defined (3.1, 5.3.4), or
    -- an lvalue-to-rvalue conversion is applied to an lvalue 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 defined (3.1) or called (5.2.2), or
    -- an lvalue of type T is assigned to (5.17). ]
5   There can be more than one definition 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.5), static data
    member of a class template (14.5.1.3), member function template (14.5.1.1), or template specialization for
    which some template parameters are not specified (14.7, 14.5.4) in a program provided that each definition
    appears in a different translation unit, and provided the definitions satisfy the following requirements.
    Given such an entity named D defined in more than one translation unit, then
    -- each definition of D shall consist of the same sequence of tokens; and
    -- in each definition of D, corresponding names, looked up according to 3.4, shall refer to an entity defined
       within the definition 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 integral or enumeration type in all definitions of D,


                                                                                                                    23
    ISO/IEC 14882:1998(E)                                                                               © ISO/IEC

    3.2 One definition rule                                                                         3 Basic concepts



         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 definitions of D; and
    -- in each definition 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 defined within the definition of D; and
    -- in each definition of D, a default argument used by an (implicit or explicit) function call is treated as if
       its token sequence were present in the definition 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).25)
    -- if D is a class with an implicitly-declared constructor (12.1), it is as if the constructor was implicitly
       defined in every translation unit where it is used, and the implicit definition 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;                                                 // X(int) called by D()

              // translation unit 2:
              struct X {
                          X(int);
                          X(int, int);
              };
              X::X(int = 0, int = 0) { }
              class D: public X { };                                // X(int, int) called by D();
                                                                    // D()'s implicit definition
                                                                    // violates the ODR
          --end example] If D is a template, and is defined in more than one translation unit, then the last four
         requirements from the list above shall apply to names from the template's enclosing scope used in the
         template definition (14.6.3), and also to dependent names at the point of instantiation (14.6.2). If the
         definitions of D satisfy all these requirements, then the program shall behave as if there were a single
         definition of D. If the definitions of D do not satisfy these requirements, then the behavior is undefined.

    3.3 Declarative regions and scopes                                                                [basic.scope]
1   Every name is introduced in some portion of program text called a declarative region, which is the largest
    part of the program in which that name is valid, that is, in which that name may be used as an unqualified
    name to refer to the same entity. In general, each particular name is valid only within some possibly dis-
    contiguous portion of program text called its scope. To determine the scope of a declaration, it is some-
    times 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.




    __________________
    25) 8.3.6 describes how default argument names are looked up.




    24
    © ISO/IEC                                                                             ISO/IEC 14882:1998(E)

    3 Basic concepts                                                               3.3 Declarative regions and scopes



2   [Example: in
         int j = 24;
         int main()
         {
                 int i = j, j;
                 j = 42;
         }
    the identifier j is declared twice as a name (and used twice). The declarative region of the first j includes
    the entire example. The potential scope of the first j begins immediately after that j and extends to the end
    of the program, but its (actual) scope excludes the text between the , and the }. The declarative region of
    the second declaration of j (the j immediately before the semicolon) includes all the text between { and },
    but its potential scope excludes the declaration of i. The scope of the second declaration of j is the same
    as its potential scope. ]
3   The names declared by a declaration are introduced into the scope in which the declaration occurs, except
    that the presence of a friend specifier (11.4), certain uses of the elaborated-type-specifier (3.3.1), and
    using-directives (7.3.4) alter this general behavior.
4   Given a set of declarations in a single declarative region, each of which specifies the same unqualified
    name,
    -- they shall all refer to the same entity, or all refer to functions and function templates; or
    -- exactly one declaration shall declare a class name or enumeration name that is not a typedef name and
       the other declarations shall all refer to the same object or enumerator, or all refer to functions and func-
       tion templates; in this case the class name or enumeration name is hidden (3.3.7). [Note: a namespace
       name or a class template name must be unique in its declarative region (7.3.2, clause 14). ]
    [Note: these restrictions apply to the declarative region into which a name is introduced, which is not neces-
    sarily the same as the region in which the declaration occurs. In particular, elaborated-type-specifiers
    (3.3.1) and friend declarations (11.4) may introduce a (possibly not visible) name into an enclosing name-
    space; 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. ]
5   [Note: the name lookup rules are summarized in 3.4. ]

    3.3.1 Point of declaration                                                                  [basic.scope.pdecl]
1   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; }
    Here the second x is initialized with its own (indeterminate) value. ]
2   [Note: a nonlocal name remains visible up to the point of declaration of the local name that hides it.
    [Example:
         const int i = 2;
         { int i[i]; }
    declares a local array of two integers. ] ]
3   The point of declaration for an enumerator is immediately after its enumerator-definition. [Example:
         const int x = 12;
         { enum { x = x }; }
    Here, the enumerator x is initialized with the value of the constant x, namely 12. ]




                                                                                                                  25
    ISO/IEC 14882:1998(E)                                                                                 © ISO/IEC

    3.3.1 Point of declaration                                                                       3 Basic concepts



4   After the point of declaration of a class member, the member name can be looked up in the scope of its
    class. [Note: this is true even if the class is an incomplete class. For example,
          struct X {
                  enum E { z = 16 };
                  int b[X::z];                         // OK
          };
    --end note]
5   The point of declaration of a class first declared in an elaborated-type-specifier is as follows:
    -- for an elaborated-type-specifier of the form
              class-key identifier ;

         the elaborated-type-specifier declares the identifier to be a class-name in the scope that contains the
         declaration, otherwise
    -- for an elaborated-type-specifier of the form
              class-key identifier

         if the elaborated-type-specifier is used in the decl-specifier-seq or parameter-declaration-clause of a
         function defined in namespace scope, the identifier is declared as a class-name in the namespace that
         contains the declaration; otherwise, except as a friend declaration, the identifier is declared in the small-
         est non-class, non-function-prototype scope that contains the declaration. [Note: if the elaborated-
         type-specifier designates an enumeration, the identifier must refer to an already declared enum-name. If
         the identifier in the elaborated-type-specifier is a qualified-id, it must refer to an already declared
         class-name or enum-name. See 3.4.4. ]
6   [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 object declarations with the extern specifier at block scope refer to delarations that are members of
    an enclosing namespace, but they do not introduce new names into that scope. ]
7   [Note: For point of instantiation of a template, see 14.7.1. ]

    3.3.2 Local scope                                                                            [basic.scope.local]
1   A name declared in a block (6.3) is local to that block. Its potential scope begins at its point of declaration
    (3.3.1) and ends at the end of its declarative region.
2   The potential scope of a function parameter name in a function definition (8.4) begins at its point of decla-
    ration. If the function has a function try-block the potential scope of a parameter ends at the end of the last
    associated handler, else it ends at the end of the outermost block of the function definition. A parameter
    name shall not be redeclared in the outermost block of the function definition nor in the outermost block of
    any handler associated with a function try-block .
3   The name in a catch exception-declaration is local to the handler and shall not be redeclared in the outer-
    most block of the handler.
4   Names declared in the for-init-statement, 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 state-
    ment, any of the outermost blocks) of the controlled statement; see 6.4.

    3.3.3 Function prototype scope                                                               [basic.scope.proto]
1   In a function declaration, or in any function declarator except the declarator of a function definition (8.4),
    names of parameters (if supplied) have function prototype scope, which terminates at the end of the nearest
    enclosing function declarator.



    26
    © ISO/IEC                                                                                ISO/IEC 14882:1998(E)

    3 Basic concepts                                                                              3.3.4 Function scope



    3.3.4 Function scope                                                                            [basic.funscope]
1   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.5 Namespace scope                                                                    [basic.scope.namespace]
1   The declarative region of a namespace-definition 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-definitions 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.1) 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)                            // overloads N::g(int)
                 {
                         return l+a;                      // l is from unnamed namespace
                 }

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

                     int j()                              // OK: definition of N::j()
                     {
                             return g(i);                 // calls N::g(int)
                     }
                     int q();                             // error: different return type
         }
    --end example]
2   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.
3   A name declared outside all named or unnamed namespaces (7.3), blocks (6.3), function declarations
    (8.3.5), function definitions (8.4) and classes (clause 9) has global namespace scope (also called global
    scope). The potential scope of such a name begins at its point of declaration (3.3.1) and ends at the end of
    the translation unit that is its declarative region. Names declared in the global namespace scope are said to
    be global.

    3.3.6 Class scope                                                                             [basic.scope.class]
1   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 declarator, but also of all function bodies, default arguments, and constructor ctor-


                                                                                                                   27
    ISO/IEC 14882:1998(E)                                                                                  © ISO/IEC

    3.3.6 Class scope                                                                                3 Basic concepts



         initializers 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 pro-
       gram 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 definition also extends to
       the regions defined by its member definitions, even if the members are defined lexically outside the
       class (this includes static data member definitions, nested class definitions, member function definitions
       (including the member function body and, for constructor functions (12.1), the ctor-initializer (12.6.2))
       and any portion of the declarator part of such definitions which follows the identifier, including a
       parameter-declaration-clause and any default arguments (8.3.6). [Example:
              typedef int c;
              enum { i = 1 };

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

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

              typedef int I;
              class D {
                  typedef I I;                              // error, even though no reordering involved
              };
         --end example]
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,
    -- 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.7 Name hiding                                                                           [basic.scope.hiding]
1   A name can be hidden by an explicit declaration of that same name in a nested declarative region or derived
    class (10.2).
2   A class name (9.1) or enumeration name (7.2) can be hidden by the name of an object, function, or enumer-
    ator declared in the same scope. If a class or enumeration name and an object, function, or enumerator are



    28
    © ISO/IEC                                                                           ISO/IEC 14882:1998(E)

    3 Basic concepts                                                                             3.3.7 Name hiding



    declared in the same scope (in any order) with the same name, the class or enumeration name is hidden
    wherever the object, function, or enumerator name is visible.
3   In a member function definition, the declaration of a local name hides the declaration of a member of the
    class with the same name; see 3.3.6. 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.
4   During the lookup of a name qualified by a namespace name, declarations that would otherwise be made
    visible by a using-directive can be hidden by declarations with the same name in the namespace containing
    the using-directive; see (3.4.3.2).
5   If a name is in scope and is not hidden it is said to be visible.

    3.4 Name lookup                                                                                [basic.lookup]
1   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 partic-
    ular rule. Name lookup associates the use of a name with a declaration (3.1) of that name. Name lookup
    shall find an unambiguous declaration for the name (see 10.2). Name lookup may associate more than one
    declaration with a name if it finds 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 applica-
    ble) 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).
2   A name "looked up in the context of an expression" is looked up as an unqualified name in the scope where
    the expression is found.
3   Because the name of a class is inserted in its class scope (clause 9), the name of a class is also considered a
    member of that class for the purposes of name hiding and lookup.
4   [Note: 3.5 discusses linkage issues. The notions of scope, point of declaration and name hiding are dis-
    cussed in 3.3. ]

    3.4.1 Unqualified name lookup                                                          [basic.lookup.unqual]
1   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.
2   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 unqualified 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.
3   The lookup for an unqualified name used as the postfix-expression of a function call is described in 3.4.2.
    [Note: for purposes of determining (during parsing) whether an expression is a postfix-expression for a
    function call, the usual name lookup rules apply. The rules in 3.4.2 have no effect on the syntactic interpre-
    tation of an expression. For example,
         typedef int f;
         struct A {
                 friend void f(A &);
                 operator int();
                 void g(A a) {
                         f(a);
                 }
         };
    The expression f(a) is a cast-expression equivalent to int(a). Because the expression is not a function



                                                                                                                29
    ISO/IEC 14882:1998(E)                                                                                                  © ISO/IEC

    3.4.1 Unqualified name lookup                                                                                    3 Basic concepts



    call, the argument-dependent name lookup (3.4.2) does not apply and the friend function f is not found. ]
4   A name used in global scope, outside of any function, class or user-declared namespace, shall be declared
    before its use in global scope.
5   A name used in a user-declared namespace outside of the definition of any function or class shall be
    declared before its use in that namespace or before its use in a namespace enclosing its namespace.
6   A name used in the definition of a function26) that is a member of namespace N (where, only for the pur-
    pose 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 definition of A::N::f
          }
    --end example]
7   A name used in the definition of a class X outside of a member function body or nested class definition27)
    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 definition of X in Y, or shall be a member of a base class
       of Y (this lookup applies in turn to Y's enclosing classes, starting with the innermost enclosing class),28)
       or
    -- if X is a local class (9.8) or is a nested class of a local class, before the definition of class X in a block
       enclosing the definition of class X, or
    -- if X is a member of namespace N, or is a nested class of a class that is a member of N, or is a local class
       or a nested class within a local class of a function that is a member of N, before the definition of class X
       in namespace N or in one of N's enclosing namespaces.
    [Example:
          namespace M {
                  class B { };
          }




    __________________
    26) This refers to unqualified names following the function declarator; such a name may be used as a type or as a default argument
    name in the parameter-declaration-clause, or may be used in the function body.
    27) This refers to unqualified names following the class name; such a name may be used in the base-clause or may be used in the class
    definition.
    28) This lookup applies whether the definition of X is nested within Y's definition or whether X's definition appears in a namespace
    scope enclosing Y's definition (9.7).




    30
    © ISO/IEC                                                                                              ISO/IEC 14882:1998(E)

    3 Basic concepts                                                                                  3.4.1 Unqualified name lookup



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

          // The following scopes are searched for a declaration of i:
          // 1) scope of class N::Y::X, before the use of i
          // 2) scope of class N::Y, before the definition of N::Y::X
          // 3) scope of N::Y's base class M::B
          // 4) scope of namespace N, before the definition of N::Y
          // 5) global scope, before the definition of N
     --end example] [Note: when looking for a prior declaration of a class or function introduced by a friend
    declaration, scopes outside of the innermost enclosing namespace scope are not considered; see 7.3.1.2. ]
    [Note: 3.3.6 further describes the restrictions on the use of names in a class definition. 9.7 further describes
    the restrictions on the use of names in nested class definitions. 9.8 further describes the restrictions on the
    use of names in local class definitions. ]
8   A name used in the definition of a function that is a member function (9.3)29) 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),30) or
    -- if X is a local class (9.8) or is a nested class of a local class, before the definition of class X in a block
       enclosing the definition of class X, or
    -- if X is a member of namespace N, or is a nested class of a class that is a member of N, or is a local class
       or a nested class within a local class of a function that is a member of N, before the member function
       definition, in namespace N or in one of N's enclosing namespaces.
    [Example:
          class B { };
          namespace M {
                  namespace N {
                          class X : public B {
                                  void f();
                          };
                  }
          }
          void M::N::X::f() {
                  i = 16;
          }




    __________________
    29) That is, an unqualified name following the function declarator; such a name may be used as a type or as a default argument name in
    the parameter-declaration-clause, or may be used in the function body, or, if the function is a constructor, may be used in the expres-
    sion of a mem-initializer.
    30) This lookup applies whether the member function is defined within the definition of class X or whether the member function is
    defined in a namespace scope enclosing X's definition.




                                                                                                                                       31
     ISO/IEC 14882:1998(E)                                                                               © ISO/IEC

     3.4.1 Unqualified name lookup                                                                  3 Basic concepts



          // The following scopes are searched for a declaration of i:
          // 1) outermost block scope of M::N::X::f, before the use of i
          // 2) scope of class M::N::X
          // 3) scope of M::N::X's base class B
          // 4) scope of namespace M::N
          // 5) scope of namespace M
          // 6) global scope, before the definition of M::N::X::f
      --end example] [Note: 9.3 and 9.4 further describe the restrictions on the use of names in member function
     definitions. 9.7 further describes the restrictions on the use of names in the scope of nested classes. 9.8 fur-
     ther describes the restrictions on the use of names in local class definitions. ]
9    Name lookup for a name used in the definition of a friend function (11.4) defined inline in the class
     granting friendship shall proceed as described for lookup in member function definitions. If the friend
     function is not defined in the class granting friendship, name lookup in the friend function definition
     shall proceed as described for lookup in namespace member function definitions.
10   In a friend declaration naming a member function, a name used in the function declarator and not part of
     a template-argument in a template-id is first looked up in the scope of the member function's class. If it is
     not found, or if the name is part of a template-argument in a template-id, the look up is as described for
     unqualified names in the definition of the class granting friendship. [Example:
          struct A {
                  typedef int AT;
                  void f1(AT);
                  void f2(float);
          };
          struct B {
                  typedef float BT;
                  friend void A::f1(AT);               // parameter type is A::AT
                  friend void A::f2(BT);               // parameter type is B::BT
          };
     --end example]
11   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 func-
     tion 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. ]
12   A name used in the definition of a static data member of class X (9.4.2) (after the qualified-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 definition of a static data member. ]
13   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 definition. In particular, the function parameter names shall not be rede-
     clared in the exception-declaration nor in the outermost block of a handler for the function-try-block.
     Names declared in the outermost block of the function definition are not found when looked up in the scope
     of a handler for the function-try-block. [Note: but function parameter names are found. ]
14   [Note: the rules for name lookup in template definitions are described in 14.6. ]

     3.4.2 Argument-dependent name lookup                                                    [basic.lookup.koenig]
1    When an unqualified name is used as the postfix-expression in a function call (5.2.2), other namespaces not
     considered during the usual unqualified lookup (3.4.1) may be searched, and namespace-scope friend func-
     tion declarations (11.4) not otherwise visible may be found. These modifications to the search depend on
     the types of the arguments (and for template template arguments, the namespace of the template argument).




     32
    © ISO/IEC                                                                              ISO/IEC 14882:1998(E)

    3 Basic concepts                                                         3.4.2 Argument-dependent name lookup



2   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, its associated classes are the class itself and its direct and indirect base classes. Its
       associated namespaces are the namespaces in which its associated classes are defined.
    -- If T is a union or enumeration type, its associated namespace is the namespace in which it is defined. If
       it is a 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 asso-
       ciated 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 T is a template-id, its associated namespaces and classes are the namespace in which the template is
       defined; for member templates, the member template's class; the namespaces and classes associated
       with the types of the template arguments provided for template type parameters (excluding template
       template parameters); the namespaces in which any template template arguments are defined; and the
       classes in which any member templates used as template template arguments are defined. [Note: non-
       type template arguments do not contribute to the set of associated namespaces. ]
    If the ordinary unqualified lookup of the name finds the declaration of a class member function, the associ-
    ated namespaces and classes are not considered. Otherwise the set of declarations found by the lookup of
    the function name is the union of the set of declarations found using ordinary unqualified lookup and the set
    of declarations found in the namespaces and classes associated with the argument types. [Example:
         namespace NS {
             class T { };
             void f(T);
         }
         NS::T parm;
         int main() {
             f(parm);                                  // OK: calls NS::f
         }
    --end example]
3   When considering an associated namespace, the lookup is the same as the lookup performed when the asso-
    ciated namespace is used as a qualifier (3.4.3.2) except that:
    -- Any using-directives in the associated namespace are ignored.
    -- Any namespace-scope friend functions declared in associated classes are visible within their respective
       namespaces even if they are not visible during an ordinary lookup (11.4).

    3.4.3 Qualified name lookup                                                                 [basic.lookup.qual]
1   The name of a class or namespace member can be referred to after the :: scope resolution operator (5.1)
    applied to a nested-name-specifier that nominates its class or namespace. During the lookup for a name
    preceding the :: scope resolution operator, object, function, and enumerator names are ignored. If the
    name found is not a class-name (clause 9) or namespace-name (7.3.1), the program is ill-formed. [Exam-
    ple:


                                                                                                                   33
    ISO/IEC 14882:1998(E)                                                                            © ISO/IEC

    3.4.3 Qualified name lookup                                                                 3 Basic concepts



         class A {
         public:
                 static int n;
         };
         int main()
         {
                 int A;
                 A::n = 42;                          // OK
                 A b;                                // ill-formed: A does not name a type
         }
    --end example]
2   [Note: Multiply qualified names, such as N1::N2::N3::n, can be used to refer to members of nested
    classes (9.7) or members of nested namespaces. ]
3   In a declaration in which the declarator-id is a qualified-id, names used before the qualified-id being
    declared are looked up in the defining namespace scope; names following the qualified-id are looked up in
    the scope of the member's class or namespace. [Example:
         class X { };
         class C {
                 class X { };
                 static const int number = 50;
                 static X arr[number];
         };
         X C::arr[number];               // ill-formed:
                                         // equivalent to: ::X C::arr[C::number];
                                         // not to: C::X C::arr[C::number];
    --end example]
4   A name prefixed 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 declara-
    tion 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 identifier has been hidden (3.3.7).
5   If a pseudo-destructor-name (5.2.4) contains a nested-name-specifier, the type-names are looked up as
    types in the scope designated by the nested-name-specifier. In a qualified-id of the form:
         ::opt nested-name-specifier ~ class-name

    where the nested-name-specifier designates a namespace scope, and in a qualified-id of the form:
         ::opt nested-name-specifier class-name :: ~ class-name

    the class-names are looked up as types in the scope designated by the nested-name-specifier. [Example:
         struct C {
                 typedef int I;
         };
         typedef int I1, I2;
         extern int* p;
         extern int* q;
         p->C::I::~I();                              // I is looked up in the scope of C
         q->I1::~I2();                               // I2 is looked up in the scope of
                                                     // the postfix-expression




    34
    © ISO/IEC                                                                                ISO/IEC 14882:1998(E)

    3 Basic concepts                                                                       3.4.3 Qualified name lookup



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

    3.4.3.1 Class members                                                                                 [class.qual]
1   If the nested-name-specifier of a qualified-id nominates a class, the name specified after the nested-name-
    specifier is looked up in the scope of the class (10.2), except for the cases listed below. The name shall rep-
    resent 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 qualified-id at any point in its potential scope (3.3.6). ] The exceptions to the
    name lookup rule above are the following:
    -- a destructor name is looked up as specified in 3.4.3;
    -- a conversion-type-id of an operator-function-id is looked up both in the scope of the class and in the
       context in which the entire postfix-expression occurs and shall refer to the same type in both contexts;
    -- the template-arguments of a template-id are looked up in the context in which the entire postfix-
       expression occurs.
2   A class member name hidden by a name in a nested declarative region or by the name of a derived class
    member can still be found if qualified by the name of its class followed by the :: operator.

    3.4.3.2 Namespace members                                                                      [namespace.qual]
1   If the nested-name-specifier of a qualified-id nominates a namespace, the name specified after the nested-
    name-specifier is looked up in the scope of the namespace, except that the template-arguments of a
    template-id are looked up in the context in which the entire postfix-expression occurs.
2   Given X::m (where X is a user-declared namespace), or given ::m (where X is the global namespace), let
    S be the set of all declarations of m in X and in the transitive closure of all namespaces nominated by
    using-directives in X and its used namespaces, except that using-directives are ignored in any namespace,
    including X, directly containing one or more declarations of m. No namespace is searched more than once
    in the lookup of a name. If S is the empty set, the program is ill-formed. Otherwise, if S has exactly one
    member, or if the context of the reference is a using-declaration (7.3.3), S 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, the program
    is ill-formed. [Example:
         int x;
         namespace Y {
                 void f(float);
                 void h(int);
         }

         namespace Z {
                 void h(double);
         }




                                                                                                                   35
    ISO/IEC 14882:1998(E)                                                                          © ISO/IEC

    3.4.3.2 Namespace members                                                                 3 Basic concepts



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

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

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

         void h()
         {
                 AB::g();                          // g is declared directly in AB,
                                                   // therefore S is { AB::g() } and AB::g() is chosen
                   AB::f(1);                       // f is not declared directly in AB so the rules are
                                                   // applied recursively to A and B;
                                                   // namespace Y is not searched and Y::f(float)
                                                   // is not considered;
                                                   // S is { A::f(int), B::f(char) } and overload
                                                   // resolution chooses A::f(int)
                   AB::f('c');                     // as above but resolution chooses B::f(char)

                   AB::x++;                        // x is not declared directly in AB, and
                                                   // is not declared in A or B, so the rules are
                                                   // applied recursively to Y and Z,
                                                   // S is { } so the program is ill-formed
                   AB::i++;                        // i is not declared directly in AB so the rules are
                                                   // applied recursively to A and B,
                                                   // S is { A::i, B::i } so the use is ambiguous
                                                   // and the program is ill-formed
                   AB::h(16.8);                    // h is not declared directly in AB and
                                                   // not declared directly in A or B so the rules are
                                                   // applied recursively to Y and Z,
                                                   // S is { Y::h(int), Z::h(double) } and overload
                                                   // resolution chooses Z::h(double)
         }

3   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;
         }




    36
    © ISO/IEC                                                                         ISO/IEC 14882:1998(E)

    3 Basic concepts                                                                3.4.3.2 Namespace members



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

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

         namespace D {
                 using A::a;
         }

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

         void g()
         {
                 BD::a++;                          // OK: S is { A::a, A::a }
         }

4   Because each referenced namespace is searched at most once, the following is well-defined:
         namespace B {
                 int b;
         }

         namespace A {
                 using namespace B;
                 int a;
         }

         namespace B {
                 using namespace A;
         }

         void f()
         {
                 A::a++;                           // OK: a declared directly in A, S is { A::a }
                  B::a++;                          // OK: both A and B searched (once), S is { A::a }
                  A::b++;                          // OK: both A and B searched (once), S is { B::b }
                  B::b++;                          // OK: b declared directly in B, S is { B::b }
         }
    --end example]
5   During the lookup of a qualified namespace member name, if the lookup finds more than one declaration of
    the member, and if one declaration introduces a class name or enumeration name and the other declarations
    either introduce the same object, 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 dec-
    larations are from different namespaces), the program is ill-formed. [Example:
         namespace A {
                 struct x { };
                 int x;
                 int y;
         }




                                                                                                           37
    ISO/IEC 14882:1998(E)                                                                            © ISO/IEC

    3.4.3.2 Namespace members                                                                   3 Basic concepts



         namespace B {
                 struct y {};
         }

         namespace C {
                 using       namespace A;
                 using       namespace B;
                 int i       = C::x;                // OK, A::x (of type int)
                 int j       = C::y;                // ambiguous, A::y or B::y
         }
    --end example]
6   In a declaration for a namespace member in which the declarator-id is a qualified-id, given that the
    qualified-id for the namespace member has the form
         nested-name-specifier unqualified-id

    the unqualified-id shall name a member of the namespace designated by the nested-name-specifier. [Exam-
    ple:
         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-specifier may rely on
    using-directives to implicitly provide the initial part of the nested-name-specifier. [Example:
         namespace A {
                 namespace B {
                         void f1(int);
                 }
         }

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

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

    3.4.4 Elaborated type specifiers                                                         [basic.lookup.elab]
1   An elaborated-type-specifier may be used to refer to a previously declared class-name or enum-name even
    though the name has been hidden by a non-type declaration (3.3.7). The class-name or enum-name in the
    elaborated-type-specifier may either be a simple identifer or be a qualified-id.
2   If the name in the elaborated-type-specifier is a simple identifer, and unless the elaborated-type-specifier
    has the following form:
         class-key identifier ;

    the identifier is looked up according to 3.4.1 but ignoring any non-type names that have been declared. If
    this name lookup finds a typedef-name, the elaborated-type-specifier is ill-formed. If the elaborated-type-
    specifier refers to an enum-name and this lookup does not find a previously declared enum-name, the


    38
    © ISO/IEC                                                                              ISO/IEC 14882:1998(E)

    3 Basic concepts                                                                  3.4.4 Elaborated type specifiers



    elaborated-type-specifier is ill-formed. If the elaborated-type-specifier refers to an class-name and this
    lookup does not find a previously declared class-name, or if the elaborated-type-specifier has the form:
         class-key identifier ;

    the elaborated-type-specifier is a declaration that introduces the class-name as described in 3.3.1.
3   If the name is a qualified-id, the name is looked up according its qualifications, as described in 3.4.3, but
    ignoring any non-type names that have been declared. If this name lookup finds a typedef-name, the
    elaborated-type-specifier is ill-formed. If this name lookup does not find a previously declared class-name
    or enum-name, the elaborated-type-specifier is ill-formed. [Example:
         struct Node {
                 struct Node* Next;                   // OK: Refers to Node at global scope
                 struct Data* Data;                   // OK: Declares type Data
                                                      // at global scope and member Data
         };

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

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

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

    3.4.5 Class member access                                                                [basic.lookup.classref]
1   In a class member access expression (5.2.5), if the . or -> token is immediately followed by an identifier
    followed by a <, the identifier must be looked up to determine whether the < is the beginning of a template
    argument list (14.2) or a less-than operator. The identifier is first looked up in the class of the object
    expression. If the identifier is not found, it is then looked up in the context of the entire postfix-expression
    and shall name a class or function template. If the lookup in the class of the object expression finds a tem-
    plate, the name is also looked up in the context of the entire postfix-expression and
    -- if the name is not found, the name found in the class of the object expression is used, otherwise
    -- if the name is found in the context of the entire postfix-expression and does not name a class template,
       the name found in the class of the object expression is used, otherwise
    -- if the name found is a class template, it must refer to the same entity as the one found in the class of the
       object expression, otherwise the program is ill-formed.




                                                                                                                   39
    ISO/IEC 14882:1998(E)                                                                                 © ISO/IEC

    3.4.5 Class member access                                                                       3 Basic concepts



2   If the id-expression in a class member access (5.2.5) is an unqualified-id, and the type of the object expres-
    sion is of a class type C (or of pointer to a class type C), the unqualified-id is looked up in the scope of class
    C. If the type of the object expression is of pointer to scalar type, the unqualified-id is looked up in the con-
    text of the complete postfix-expression.
3   If the unqualified-id is ~type-name, and the type of the object expression is of a class type C (or of pointer to
    a class type C), the type-name is looked up in the context of the entire postfix-expression and in the scope of
    class C. The type-name shall refer to a class-name. If type-name is found in both contexts, the name shall
    refer to the same class type. If the type of the object expression is of scalar type, the type-name is looked
    up in the scope of the complete postfix-expression.
4   If the id-expression in a class member access is a qualified-id of the form
         class-name-or-namespace-name::...

    the class-name-or-namespace-name following the . or -> operator is looked up both in the context of the
    entire postfix-expression and in the scope of the class of the object expression. If the name is found only in
    the scope of the class of the object expression, the name shall refer to a class-name. If the name is found
    only in the context of the entire postfix-expression, the name shall refer to a class-name or namespace-
    name. If the name is found in both contexts, the class-name-or-namespace-name shall refer to the same
    entity. [Note: the result of looking up the class-name-or-namespace-name is not required to be a unique
    base class of the class type of the object expression, as long as the entity or entities named by the qualified-
    id are members of the class type of the object expression and are not ambiguous according to 10.2.
         struct A {
                 int a;
         };
         struct B: virtual A { };
         struct C: B { };
         struct D: B { };
         struct E: public C, public D { };
         struct F: public A { };

         void f() {
                 E e;
                 e.B::a = 0;                           // OK, only one A::a in E

                     F f;
                     f.A::a = 1;                       // OK, A::a is a member of F
         }
    --end note]
5   If the qualified-id has the form
         ::class-name-or-namespace-name::...

    the class-name-or-namespace-name is looked up in global scope as a class-name or namespace-name.
6   If the nested-name-specifier contains a class template-id (14.2), its template-arguments are evaluated in the
    context in which the entire postfix-expression occurs.
7   If the id-expression is a conversion-function-id, its conversion-type-id shall denote the same type in both
    the context in which the entire postfix-expression occurs and in the context of the class of the object expres-
    sion (or the class pointed to by the pointer expression).

    3.4.6 Using-directives and namespace aliases                                                [basic.lookup.udir]
1   When looking up a namespace-name in a using-directive or namespace-alias-definition, only namespace
    names are considered.




    40
    © ISO/IEC                                                                             ISO/IEC 14882:1998(E)

    3 Basic concepts                                                                       3.5 Program and linkage



    3.5 Program and linkage                                                                           [basic.link]
1   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.5) has internal linkage if it is the name of
    -- an object, reference, function or function template that is explicitly declared static or,
    -- an object or reference that is explicitly declared const and neither explicitly declared extern nor
       previously declared to have external linkage; or
    -- a data member of an anonymous union.
4   A name having namespace scope has external linkage if it is the name of
    -- an object or reference, unless it has internal linkage; or
    -- a function, unless it has internal linkage; or
    -- a named class (clause 9), or an unnamed class defined 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 defined 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 external linkage; or
    -- a template, unless it is a function template that has internal linkage (clause 14); or
    -- a namespace (7.3), unless it is declared within an unnamed namespace.
5   In addition, a member function, static data member, class or enumeration of class scope has external link-
    age if the name of the class has external linkage.
6   The name of a function declared in block scope, and the name of an object 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.




                                                                                                               41
    ISO/IEC 14882:1998(E)                                                                             © ISO/IEC

    3.5 Program and linkage                                                                       3 Basic concepts



    [Example:
         static void f();
         static int i = 0;                                      //1
         void g() {
                 extern void f();                               // internal linkage
                 int i;                                         //2: i has no linkage
                 {
                          extern void f();                      // internal linkage
                          extern int i;                         //3: external linkage
                 }
         }
    There are three objects named i in this program. The object with internal linkage introduced by the decla-
    ration 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. ]
7   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:
         namespace X {
                 void p()
                 {
                         q();                                   // error: q not yet declared
                          extern void q();                      // q is a member of namespace X
                 }

                    void middle()
                    {
                            q();                                // error: q not yet declared
                    }

                    void q() { /* ... */ }                      // definition of X::q
         }

         void q() { /* ... */ }                                 // some other, unrelated q
    --end example]
8   Names not covered by these rules have no linkage. Moreover, except as noted, a name declared in a local
    scope (3.3.2) has no linkage. A name with no linkage (notably, the name of a class or enumeration declared
    in a local scope (3.3.2)) shall not be used to declare an entity with linkage. If a declaration uses a typedef
    name, it is the linkage of the type name to which the typedef refers that is considered. [Example:
         void f()
         {
             struct A { int x; };                    // no linkage
             extern A a;                             // ill-formed
             typedef A B;
             extern B b;                             // ill-formed
         }
    --end example] This implies that names with no linkage cannot be used as template arguments (14.3).
9   Two names that are the same (clause 3) and that are declared in different scopes shall denote the same
    object, reference, 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


    42
     © ISO/IEC                                                                           ISO/IEC 14882:1998(E)

     3 Basic concepts                                                                     3.5 Program and linkage



     -- when both names denote functions, the function types are identical for purposes of overloading; and
     -- when both names denote function templates, the signatures (14.5.5.1) are the same.
10   After all adjustments of types (during which typedefs (7.1.3) are replaced by their definitions), the types
     specified by all declarations referring to a given object or function shall be identical, except that declara-
     tions for an array object can specify array types that differ 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.
11   [Note: linkage to non-C++ declarations can be achieved using a linkage-specification (7.5). ]

     3.6 Start and termination                                                                        [basic.start]

     3.6.1 Main function                                                                       [basic.start.main]
1    A program shall contain a global function called main, which is the designated start of the program. It is
     implementation-defined whether a program in a freestanding environment is required to define a main
     function. [Note: in a freestanding environment, start-up and termination is implementation-defined; start-
     up contains the execution of constructors for objects of namespace scope with static storage duration; termi-
     nation contains the execution of destructors for objects with static storage duration. ]
2    An implementation shall not predefine the main function. This function shall not be overloaded. It shall
     have a return type of type int, but otherwise its type is implementation-defined. All implementations
     shall allow both of the following definitions 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 (NTMBSs)
     (17.3.2.1.3.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 nonnegative. The value of
     argv[argc] shall be 0. [Note: it is recommended that any further (optional) parameters be added after
     argv. ]
3    The function main shall not be used (3.2) within a program. The linkage (3.5) of main is
     implementation-defined. A program that declares main to be inline or static is ill-formed. The
     name main is not otherwise reserved. [Example: member functions, classes, and enumerations can be
     called main, as can entities in other namespaces. ]
4    Calling the function
           void exit(int);

     declared in <cstdlib> (18.3) terminates the program without leaving the current block and hence with-
     out destroying any objects with automatic storage duration (12.4). If exit is called to end a program dur-
     ing the destruction of an object with static storage duration, the program has undefined behavior.
5    A return statement in main has the effect of leaving the main function (destroying any objects with auto-
     matic storage duration) and calling exit with the return value as the argument. If control reaches the end
     of main without encountering a return statement, the effect is that of executing
           return 0;




                                                                                                                43
    ISO/IEC 14882:1998(E)                                                                                                        © ISO/IEC

    3.6.2 Initialization of non-local objects                                                                             3 Basic concepts



    3.6.2 Initialization of non-local objects                                                                             [basic.start.init]
1   The storage for objects with static storage duration (3.7.1) shall be zero-initialized (8.5) before any other
    initialization takes place. Zero-initialization and initialization with a constant expression are collectively
    called static initialization; all other initialization is dynamic initialization. Objects of POD types (3.9) with
    static storage duration initialized with constant expressions (5.19) shall be initialized before any dynamic
    initialization takes place. Objects with static storage duration defined in namespace scope in the same
    translation unit and dynamically initialized shall be initialized in the order in which their definition appears
    in the translation unit. [Note: 8.5.1 describes the order in which aggregate members are initialized. The
    initialization of local static objects is described in 6.7. ]
2   An implementation is permitted to perform the initialization of an object of namespace scope with static
    storage duration as a static initialization even if such initialization is not required to be done statically, pro-
    vided that
    -- the dynamic version of the initialization does not change the value of any other object of namespace
       scope with static storage duration prior to its initialization, and
    -- the static version of the initialization produces the same value in the initialized object as would be pro-
       duced by the dynamic initialization if all objects 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 with static storage duration potentially requiring dynamic initialization and defined later in the same
    translation unit, it is unspecified 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;                 // unspecified:
                                           // may be statically initialized to 0.0 or
                                           // dynamically initialized to 1.0
           double d1 = fd();               // may be initialized statically to 1.0
    --end note]
3   It is implementation-defined whether or not the dynamic initialization (8.5, 9.4, 12.1, 12.6.1) of an object of
    namespace scope is done before the first statement of main. If the initialization is deferred to some point
    in time after the first statement of main, it shall occur before the first use of any function or object defined
    in the same translation unit as the object to be initialized.31) [Example:
           // ­ File 1 ­
           #include "a.h"
           #include "b.h"
           B b;
           A::A(){
                      b.Use();
           }

           // ­ File 2 ­
           #include "a.h"
           A a;




    __________________
    31) An object defined in namespace scope having initialization with side-effects must be initialized even if it is not used (3.7.1).




    44
    © ISO/IEC                                                                              ISO/IEC 14882:1998(E)

    3 Basic concepts                                                           3.6.2 Initialization of non-local objects



         // ­ File 3 ­
         #include "a.h"
         #include "b.h"
         extern A a;
         extern B b;

         int main() {
                 a.Use();
                 b.Use();
         }
    It is implementation-defined whether either a or b is initialized before main is entered or whether the
    initializations are delayed until a is first 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 used by the initialization of a, that is,
    before A::A is called. If, however, a is initialized at some point after the first statement of main, b will
    be initialized prior to its use in A::A. ]
4   If construction or destruction of a non-local static object ends in throwing an uncaught exception, the result
    is to call terminate (18.6.3.3).

    3.6.3 Termination                                                                              [basic.start.term]
1   Destructors (12.4) for initialized objects of static storage duration (declared at block scope or at namespace
    scope) are called as a result of returning from main and as a result of calling exit (18.3). These objects
    are destroyed in the reverse order of the completion of their constructor or of the completion of their
    dynamic initialization. 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 local object with static storage duration initialized during the construction of the sub-
    objects is destroyed.
2   If a function contains a local object of static storage duration that has been destroyed and the function is
    called during the destruction of an object with static storage duration, the program has undefined behavior
    if the flow of control passes through the definition of the previously destroyed local object.
3   If a function is registered with atexit (see <cstdlib>, 18.3) then following the call to exit, any
    objects with static storage duration initialized prior to the registration of that function shall not be destroyed
    until the registered function is called from the termination process and has completed. For an object with
    static storage duration constructed after a function is registered with atexit, then following the call to
    exit, the registered function is not called until the execution of the object's destructor has completed. If
    atexit is called during the construction of an object, the complete object to which it belongs shall be
    destroyed before the registered function is called.
4   Calling the function
         void abort();

    declared in <cstdlib> terminates the program without executing destructors for objects of automatic or
    static storage duration and without calling the functions passed to atexit().

    3.7 Storage duration                                                                                    [basic.stc]
1   Storage duration is the property of an object that defines the minimum potential lifetime of the storage con-
    taining the object. The storage duration is determined by the construct used to create the object and is one
    of the following:
    -- static storage duration
    -- automatic storage duration
    -- dynamic storage duration




                                                                                                                    45
    ISO/IEC 14882:1998(E)                                                                                  © ISO/IEC

    3.7 Storage duration                                                                              3 Basic concepts



2   Static 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).
3   The storage class specifiers static and auto are related to storage duration as described below.
4   The storage duration categories apply to references as well. The lifetime of a reference is its storage dura-
    tion.

    3.7.1 Static storage duration                                                                    [basic.stc.static]
1   All objects which neither have dynamic storage duration nor are local have static storage duration. The
    storage for these objects shall last for the duration of the program (3.6.2, 3.6.3).
2   If an object of static storage duration has initialization or a destructor with side effects, it shall not be elimi-
    nated even if it appears to be unused, except that a class object or its copy may be eliminated as specified in
    12.8.
3   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. ]
4   The keyword static applied to a class data member in a class definition gives the data member static
    storage duration.

    3.7.2 Automatic storage duration                                                                  [basic.stc.auto]
1   Local objects explicitly declared auto or register or not explicitly declared static or extern have
    automatic storage duration. The storage for these objects lasts until the block in which they are created
    exits.
2   [Note: these objects are initialized and destroyed as described in 6.7. ]
3   If a named automatic object has initialization or a destructor with side effects, 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 may be eliminated as specified in 12.8.

    3.7.3 Dynamic storage duration                                                                [basic.stc.dynamic]
1   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[].
2   The library provides default definitions for the global allocation and deallocation functions. Some global
    allocation and deallocation functions are replaceable (18.4.1). A C++ program shall provide at most one
    definition of a replaceable allocation or deallocation function. Any such function definition replaces the
    default version provided in the library (17.4.3.4). The following allocation and deallocation functions
    (18.4) are implicitly declared in global scope in each translation unit of a program
         void* operator new(std::size_t) throw(std::bad_alloc);
         void* operator new[](std::size_t) throw(std::bad_alloc);
         void operator delete(void*) throw();
         void operator delete[](void*) throw();
    These implicit declarations introduce only the function names operator new, operator new[],
    operator delete, operator delete[]. [Note: the implicit declarations do not introduce the
    names std, std::bad_alloc, and 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 <new> is well-formed. However, referring to std, std::bad_alloc, and
    std::size_t is ill-formed unless the name has been declared by including the appropriate header. ]



    46
    © ISO/IEC                                                                                    ISO/IEC 14882:1998(E)

    3 Basic concepts                                                                       3.7.3 Dynamic storage duration



    Allocation and/or deallocation functions can also be declared and defined for any class (12.5).
3   Any allocation and/or deallocation functions defined in a C++ program shall conform to the semantics spec-
    ified in 3.7.3.1 and 3.7.3.2.

    3.7.3.1 Allocation functions                                                          [basic.stc.dynamic.allocation]
1   An allocation function shall be a class member function or a global function; a program is ill-formed if an
    allocation function is declared in a namespace scope other than global scope or declared static in global
    scope. The return type shall be void*. The first parameter shall have type size_t (18.1). The first
    parameter shall not have an associated default argument (8.3.6). The value of the first 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 first parameter as specified above (that is, template parameter
    types shall not be used in the return type and first parameter type). Template allocation functions shall have
    two or more parameters.
2   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 alloca-
    tion function. The order, contiguity, and initial value of storage allocated by successive calls to an alloca-
    tion function is unspecified. The pointer returned shall be suitably aligned so that it can be converted to a
    pointer of any complete object type 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). If the size of the
    space requested is zero, the value returned shall not be a null pointer value (4.10). The results of derefer-
    encing a pointer returned as a request for zero size are undefined.32)
3   An allocation function that fails to allocate storage can invoke the currently installed new_handler
    (18.4.2.2), if any. [Note: A program-supplied allocation function can obtain the address of the currently
    installed new_handler using the set_new_handler function (18.4.2.3). ] If an allocation function
    declared with an empty exception-specification (15.4), throw(), fails to allocate storage, it shall return a
    null pointer. Any other allocation function that fails to allocate storage shall only indicate failure by throw-
    ing an exception of class std::bad_alloc (18.4.2.1) or a class derived from std::bad_alloc.
4   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 storage duration (3.7.1), for objects of type type_info (5.2.8), for the copy of an object thrown by
    a throw expression (15.1). ]

    3.7.3.2 Deallocation functions                                                     [basic.stc.dynamic.deallocation]
1   Deallocation functions shall be class member functions or global functions; a program is ill-formed if deal-
    location functions are declared in a namespace scope other than global scope or declared static in global
    scope.
2   Each deallocation function shall return void and its first parameter shall be void*. A deallocation func-
    tion 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.1), 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
    __________________
    32) The intent is to have operator new() implementable by calling malloc() or calloc(), so the rules are substantially the
    same. C++ differs from C in requiring a zero request to return a non-null pointer.




                                                                                                                          47
    ISO/IEC 14882:1998(E)                                                                                 © ISO/IEC

    3.7.3.2 Deallocation functions                                                                   3 Basic concepts



    second of which has type std::size_t, then this function is a usual deallocation function. A dealloca-
    tion function can be an instance of a function template. Neither the first parameter nor the return type shall
    depend on a template parameter. [Note: that is, a deallocation function template shall have a first parameter
    of type void* and a return type of void (as specified above). ] A deallocation function template shall
    have two or more function parameters. A template instance is never a usual deallocation function, regard-
    less of its signature.
3   The value of the first argument supplied to one of the deallocation functions provided in the standard
    library may be a null pointer value; if so, the call to the deallocation function has no effect. Otherwise, the
    value supplied to operator delete(void*) in the standard library shall be one of the values returned
    by a previous invocation of either operator new(size_t) or operator new(size_t, const
    std::nothrow_t&) in the standard library, and the value supplied to operator
    delete[](void*) in the standard library shall be one of the values returned by a previous invocation of
    either operator new[](size_t) or operator new[](size_t, const std::nothrow_t&)
    in the standard library.
4   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, render-
    ing invalid all pointers referring to any part of the deallocated storage. The effect of using an invalid
    pointer value (including passing it to a deallocation function) is undefined.33)

    3.7.4 Duration of sub-objects                                                                  [basic.stc.inherit]
1   The storage duration of member subobjects, base class subobjects and array elements is that of their com-
    plete object (1.8).

    3.8 Object Lifetime                                                                                   [basic.life]
1   The lifetime of an object is a runtime property of the object. The lifetime of an object of type T begins
    when:
    -- storage with the proper alignment and size for type T is obtained, and
    -- if T is a class type with a non-trivial constructor (12.1), the constructor call has completed.
    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.
2   [Note: the lifetime of an array object or of an object of type (3.9) starts as soon as storage with proper size
    and alignment is obtained, and its lifetime ends when the storage which the array or object occupies is
    reused or released. 12.6.2 describes the lifetime of base and member subobjects. ]
3   The properties ascribed to objects throughout this International Standard apply for a given object only dur-
    ing its lifetime. [Note: in particular, before the lifetime of an object starts and after its lifetime ends there
    are significant restrictions on the use of the object, as described below, in 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 con-
    struction and destruction phases. ]
4   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 effects produced by the destructor has undefined
    __________________
    33) On some implementations, it causes a system-generated runtime fault.




    48
    © ISO/IEC                                                                                        ISO/IEC 14882:1998(E)

    3 Basic concepts                                                                                        3.8 Object Lifetime



    behavior.
5   Before the lifetime of an object has started but after the storage which the object will occupy has been allo-
    cated34) 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. Such a pointer refers to allocated storage (3.7.3.2), and using the
    pointer as if the pointer were of type void*, is well-defined. Such a pointer may be dereferenced but the
    resulting lvalue may only be used in limited ways, as described below. 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
    program has undefined behavior. If the object will be or was of a non-POD class type, the program has
    undefined behavior if:
    -- 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*).
    -- the pointer is used as the operand of a dynamic_cast (5.2.7). [Example:
               struct B {
                       virtual void f();
                       void mutate();
                       virtual ~B();
               };

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

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

               void g() {
                       void* p = malloc(sizeof(D1) + sizeof(D2));
                       B* pb = new (p) D1;
                       pb->mutate();
                       &pb;                    // OK: pb points to valid memory
                       void* q = pb;           // OK: pb points to valid memory
                       pb->f();                // undefined behavior, lifetime of *pb has ended
               }
         --end example]
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 lvalue which refers to the original object may be used but only in limited ways.
    Such an lvalue refers to allocated storage (3.7.3.2), and using the properties of the lvalue which do not
    depend on its value is well-defined. If an lvalue-to-rvalue conversion (4.1) is applied to such an lvalue, the
    program has undefined behavior; if the original object will be or was of a non-POD class type, the program
    has undefined behavior if:
    -- the lvalue is used to access a non-static data member or call a non-static member function of the object,
       or
    __________________
    34) For example, before the construction of a global object of non-POD class type (12.7).




                                                                                                                            49
    ISO/IEC 14882:1998(E)                                                                                                    © ISO/IEC

    3.8 Object Lifetime                                                                                                3 Basic concepts



    -- the lvalue is implicitly converted (4.10) to a reference to a base class type, or
    -- the lvalue is used as the operand of a static_cast (5.2.9) (except when the conversion is ultimately
       to char& or unsigned char&), or
    -- the lvalue 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-qualifiers), 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 ) {
                               this->~C();                                         // lifetime of *this ends
                               new (this) C(other);                                // new object of type C created
                               f();                                                // well-defined
                       }
                       return *this;
               }

               C c1;
               C c2;
               c1 = c2;                                              // well-defined
               c1.f();                                               // well-defined; c1 refers to a new object of type C
         --end example]
8   If a program ends the lifetime of an object of type T with static (3.7.1) or automatic (3.7.2) storage duration
    and if T has a non-trivial destructor,35) 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 pro-
    gram is undefined. This is true even if the block is exited with an exception. [Example:
          class T { };
          struct B {
                  ~B();
          };

          void h() {
                  B b;
                  new (&b) T;
          }                                                      // undefined behavior at block exit
    --end example]
    __________________
    35) that is, an object for which a destructor will be called implicitly--either either upon exit from the block for an object with auto-
    matic storage duration or upon exit from the program for an object with static storage duration.




    50
    © ISO/IEC                                                                                        ISO/IEC 14882:1998(E)

    3 Basic concepts                                                                                         3.8 Object Lifetime



9   Creating a new object at the storage location that a const object with static or automatic storage duration
    occupies or, at the storage location that such a const object used to occupy before its lifetime ended
    results in undefined behavior. [Example:
          struct B {
                  B();
                  ~B();
          };

          const B b;

          void h() {
                  b.~B();
                  new (&b) const B;                          // undefined behavior
          }
    --end example]

    3.9 Types                                                                                                        [basic.types]
1   [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). ]
2   For any complete POD object 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.36) If the con-
    tent 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;                                             // obj initialized to its original value
          memcpy(buf, &obj, N);                              // between these two calls to memcpy,
                                                             // obj might be modified
          memcpy(&obj, buf, N);                              // at this point, each subobject of obj of scalar type
                                                             // holds its original value
    --end example]
3   For any POD type T, if two pointers to T point to distinct T objects obj1 and obj2, if the value of obj1
    is copied into obj2, using the memcpy library function, obj2 shall subsequently hold the same value as
    obj1. [Example:
          T* t1p;
          T* t2p;
                                                             // provided that t2p points to an initialized object ...
          memcpy(t1p, t2p, sizeof(T));                       // at this point, every subobject of POD type in *t1p contains
                                                             // the same value as the corresponding subobject in *t2p
    --end example]
4   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 POD types, the value representation is a set of bits in the object represen-
    tation that determines a value, which is one discrete element of an implementation-defined set of values.37)
5   Object types have alignment requirements (3.9.1, 3.9.2). The alignment of a complete object type is an
    implementation-defined integer value representing a number of bytes; an object is allocated at an address
    that meets the alignment requirements of its object type.
    __________________
    36) By using, for example, the library functions (17.4.1.2) memcpy or memmove.
    37) The intent is that the memory model of C++ is compatible with that of ISO/IEC 9899 Programming Language C.




                                                                                                                               51
     ISO/IEC 14882:1998(E)                                                                                        © ISO/IEC

     3.9 Types                                                                                                3 Basic concepts



6    A class that has been declared but not defined, or an array of unknown size or of incomplete element type,
     is an incompletely-defined object type.38) Incompletely-defined object types and the void types are incom-
     plete types (3.9.1). Objects shall not be defined to have an incomplete type.
7    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 trans-
     lation 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 different types. The type of a pointer to array of unknown size, or of a type
     defined by a typedef declaration to be an array of unknown size, cannot be completed. [Example:
           class X;                                              // X is an incomplete type
           extern X* xp;                                         // xp is a pointer to an incomplete type
           extern int arr[];                                     // the type of arr is incomplete
           typedef int UNKA[];                                   // UNKA is an incomplete type
           UNKA* arrp;                                           // arrp is a pointer to an incomplete type
           UNKA** arrpp;

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

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

           X x;
           void bar()
           {
                xp = &x;                                         // OK; type is ``pointer to X''
                arrp = &arr;                                     // ill-formed: different types
                xp++;                                            // OK: X is complete
                arrp++;                                          // ill-formed: UNKA can't be completed
           }
     --end example]
8    [Note: the rules for declarations and expressions describe in which contexts incomplete types are prohib-
     ited. ]
9    An object type is a (possibly cv-qualified) type that is not a function type, not a reference type, and not a
     void type.
10   Arithmetic types (3.9.1), enumeration types, pointer types, and pointer to member types (3.9.2), and cv-
     qualified versions of these types (3.9.3) are collectively called scalar types. Scalar types, POD-struct types,
     POD-union types (clause 9), arrays of such types and cv-qualified versions of these types (3.9.3) are collec-
     tively called POD types.
11   If two types T1 and T2 are the same type, then T1 and T2 are layout-compatible types. [Note: Layout-
     compatible enumerations are described in 7.2. Layout-compatible POD-structs and POD-unions are
     described in 9.2. ]



     __________________
     38) The size and layout of an instance of an incompletely-defined object type is unknown.




     52
    © ISO/IEC                                                                                              ISO/IEC 14882:1998(E)

    3 Basic concepts                                                                                          3.9.1 Fundamental types



    3.9.1 Fundamental types                                                                                      [basic.fundamental]
1   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 char-
    acter object is equal to the value of the single character literal form of that character. It is implementation-
    defined 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 align-
    ment requirements (3.9); 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-defined.
2   There are four signed integer types: "signed char", "short int", "int", and "long int." In this
    list, each type provides at least as much storage as those preceding it in the list. Plain ints have the natu-
    ral size suggested by the architecture of the execution environment39) ; the other signed integer types are
    provided to meet special needs.
3   For each of the signed integer types, there exists a corresponding (but different) unsigned integer type:
    "unsigned char", "unsigned short int", "unsigned int", and "unsigned long
    int," each of which occupies the same amount of storage and has the same alignment requirements (3.9)
    as the corresponding signed integer type40) ; that is, each signed integer type has the same object represen-
    tation as its corresponding unsigned integer type. The range of nonnegative values of a signed integer type
    is a subrange of the corresponding unsigned integer type, and the value representation of each correspond-
    ing signed/unsigned type shall be the same.
4   Unsigned integers, declared unsigned, shall obey the laws of arithmetic modulo 2 n where n is the num-
    ber of bits in the value representation of that particular size of integer.41)
5   Type wchar_t is a distinct type whose values can represent distinct codes for all members of the largest
    extended character set specified among the supported locales (22.1.1). Type wchar_t shall have the same
    size, signedness, and alignment requirements (3.9) as one of the other integral types, called its underlying
    type.
6   Values of type bool are either true or false.42) [Note: there are no signed, unsigned, short, or
    long bool types or values. ] As described below, bool values behave as integral types. Values of type
    bool participate in integral promotions (4.5).
7   Types bool, char, wchar_t, and the signed and unsigned integer types are collectively called integral
    types.43) A synonym for integral type is integer type. The representations of integral types shall define val-
    ues by use of a pure binary numeration system.44) [Example: this International Standard permits 2's com-
    plement, 1's complement and signed magnitude representations for integral types. ]
8   There are three floating point types: float, double, and long double. The type double provides
    at least as much precision as float, and the type long double provides at least as much precision as
    double. The set of values of the type float is a subset of the set of values of the type double; the set
    __________________
    39) that is, large enough to contain any value in the range of INT_MIN and INT_MAX, as defined in the header <climits>.
    40) See 7.1.5.2 regarding the correspondence between types and the sequences of type-specifiers that designate them.
    41) This implies that unsigned arithmetic does not overflow because a result that cannot be represented by the resulting unsigned inte-
    ger type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting unsigned inte-
    ger type.
    42) Using a bool value in ways described by this International Standard as ``undefined,'' such as by examining the value of an unini-
    tialized automatic variable, might cause it to behave as if is neither true nor false.
    43) Therefore, enumerations (7.2) are not integral; however, enumerations can be promoted to int, unsigned int, long, or
    unsigned long, as specified in 4.5.
    44) A positional representation for integers that uses the binary digits 0 and 1, in which the values represented by successive 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.)




                                                                                                                                        53
     ISO/IEC 14882:1998(E)                                                                                                    © ISO/IEC

     3.9.1 Fundamental types                                                                                              3 Basic concepts



     of values of the type double is a subset of the set of values of the type long double. The value repre-
     sentation of floating-point types is implementation-defined. Integral and floating types are collectively
     called arithmetic types. Specializations of the standard template numeric_limits (18.2) shall specify
     the maximum and minimum values of each arithmetic type for an implementation.
9    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 con-
     verted 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 as the expression in a return statement (6.6.3) for a function with the return type void.
10   [Note: even if the implementation defines two or more basic types to have the same value representation,
     they are nevertheless different types. ]

     3.9.2 Compound types                                                                                              [basic.compound]
1    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;
     -- 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 different types at different times, 9.5;
     -- enumerations, which comprise a set of named constant values. Each distinct enumeration constitutes a
        different enumerated type, 7.2;
     -- pointers to non-static45) class members, which identify members of a given type within objects of a
        given class, 8.3.3.
2    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.
3    A pointer to objects 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." ] 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.9). The
     value representation of pointer types is implementation-defined. Pointers to cv-qualified and cv-
     unqualified versions (3.9.3) of layout-compatible types shall have the same value representation and align-
     ment requirements (3.9).
4    Objects of cv-qualified (3.9.3) or cv-unqualified type void* (pointer to void), can be used to point to
     objects of unknown type. A void* shall be able to hold any object pointer. A cv-qualified or cv-
     unqualified (3.9.3) void* shall have the same representation and alignment requirements as a cv-qualified
     or cv-unqualified char*.




     __________________
     45) Static class members are objects or functions, and pointers to them are ordinary pointers to objects or functions.




     54
    © ISO/IEC                                                                                             ISO/IEC 14882:1998(E)

    3 Basic concepts                                                                                               3.9.3 CV-qualifiers



    3.9.3 CV-qualifiers                                                                                       [basic.type.qualifier]
1   A type mentioned in 3.9.1 and 3.9.2 is a cv-unqualified type. Each type which is a cv-unqualified complete
    or incomplete object type or is void (3.9) has three corresponding cv-qualified versions of its type: a
    const-qualified version, a volatile-qualified version, and a const-volatile-qualified version. The term object
    type (1.8) includes the cv-qualifiers specified when the object is created. The presence of a const speci-
    fier in a decl-specifier-seq declares an object of const-qualified object type; such object is called a const
    object. The presence of a volatile specifier in a decl-specifier-seq declares an object of volatile-
    qualified object type; such object is called a volatile object. The presence of both cv-qualifiers in a decl-
    specifier-seq declares an object of const-volatile-qualified object type; such object is called a const volatile
    object. The cv-qualified or cv-unqualified versions of a type are distinct types; however, they shall have
    the same representation and alignment requirements (3.9).46)
2   A compound type (3.9.2) is not cv-qualified by the cv-qualifiers (if any) of the types from which it is com-
    pounded. Any cv-qualifiers applied to an array type affect the array element type, not the array type (8.3.4).
3   Each non-static, non-mutable, non-reference data member of a const-qualified class object is const-
    qualified, each non-static, non-reference data member of a volatile-qualified class object is volatile-
    qualified and similarly for members of a const-volatile class. See 8.3.5 and 9.3.2 regarding cv-qualified
    function types.
4   There is a (partial) ordering on cv-qualifiers, so that a type can be said to be more cv-qualified than another.
    Table 6 shows the relations that constitute this ordering.


                                     Table 6--relations on const and volatile
                                         ______________________________________
                                          no cv-qualifier <        const       
                                          no cv-qualifier <      volatile      
                                                                               
                                          no cv-qualifier <  const volatile 
                                             const        <  const volatile 
                                          volatile        <  const volatile 
                                         ______________________________________

5   In this International Standard, the notation cv (or cv1, cv2, etc.), used in the description of types, represents
    an arbitrary set of cv-qualifiers, i.e., one of {const}, {volatile}, {const, volatile}, or the
    empty set. Cv-qualifiers applied to an array type attach to the underlying element type, so the notation
    "cv T," where T is an array type, refers to an array whose elements are so-qualified. Such array types can
    be said to be more (or less) cv-qualified than other types based on the cv-qualification of the underlying ele-
    ment types.

    3.10 Lvalues and rvalues                                                                                               [basic.lval]
1   Every expression is either an lvalue or an rvalue.
2   An lvalue refers to an object or function. Some rvalue expressions--those of class or cv-qualified class
    type--also refer to objects.47)
3   [Note: some built-in operators and function calls yield lvalues. [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 function
          int& f();

    yields an lvalue, so the call f() is an lvalue expression. ] ]
    __________________
    46) The same representation and alignment requirements are meant to imply interchangeability as arguments to functions, return values
    from functions, and members of unions.
    47) Expressions such as invocations of constructors and of functions that return a class type refer to objects, and the implementation
    can invoke a member function upon such objects, but the expressions are not lvalues.




                                                                                                                                      55
     ISO/IEC 14882:1998(E)                                                                                             © ISO/IEC

     3.10 Lvalues and rvalues                                                                                      3 Basic concepts



4    [Note: some built-in operators expect lvalue operands. [Example: built-in assignment operators all expect
     their left hand operands to be lvalues. ] Other built-in operators yield rvalues, and some expect them.
     [Example: the unary and binary + operators expect rvalue arguments and yield rvalue results. ] The discus-
     sion of each built-in operator in clause 5 indicates whether it expects lvalue operands and whether it yields
     an lvalue. ]
5    The result of calling a function that does not return a reference is an rvalue. User defined operators are
     functions, and whether such operators expect or yield lvalues is determined by their parameter and return
     types.
6    An expression which holds a temporary object resulting from a cast to a nonreference type is an rvalue (this
     includes the explicit creation of an object using functional notation (5.2.3)).
7    Whenever an lvalue appears in a context where an rvalue is expected, the lvalue is converted to an rvalue;
     see 4.1, 4.2, and 4.3.
8    The discussion of reference initialization in 8.5.3 and of temporaries in 12.2 indicates the behavior of lval-
     ues and rvalues in other significant contexts.
9    Class rvalues can have cv-qualified types; non-class rvalues always have cv-unqualified types. Rvalues
     shall always have complete types or the void type; in addition to these types, lvalues can also have incom-
     plete types.
10   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. ]
11   Functions cannot be modified, but pointers to functions can be modifiable.
12   A pointer to an incomplete type can be modifiable. At some point in the program when the pointed to type
     is complete, the object at which the pointer points can also be modified.
13   The referent of a const-qualified expression shall not be modified (through that expression), except that if
     it is of class type and has a mutable component, that component can be modified (7.1.5.1).
14   If an expression can be used to modify the object to which it refers, the expression is called modifiable. A
     program that attempts to modify an object through a nonmodifiable lvalue or rvalue expression is ill-
     formed.
15   If a program attempts to access the stored value of an object through an lvalue of other than one of the fol-
     lowing types the behavior is undefined48):
     -- the dynamic type of the object,
     -- a cv-qualified version of 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-qualified version of the dynamic type of
        the object,
     -- an aggregate or union type that includes one of the aforementioned types among its members (includ-
        ing, recursively, a member of a subaggregate or contained union),
     -- a type that is a (possibly cv-qualified) base class type of the dynamic type of the object,
     -- a char or unsigned char type.




     __________________
     48) The intent of this list is to specify those circumstances in which an object may or may not be aliased.




     56
    © ISO/IEC                                                                                           ISO/IEC 14882:1998(E)




    4 Standard conversions                                                                                                [conv]
1   Standard conversions are implicit conversions defined for built-in types. 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, floating point promotion, integral
       conversions, floating point conversions, floating-integral conversions, pointer conversions, pointer to
       member conversions, and boolean conversions.
    -- Zero or one qualification conversion.
    [Note: a standard conversion sequence can be empty, i.e., it can consist of no conversions. ] A standard
    conversion sequence will be applied to an expression if necessary to convert it to a required destination
    type.
2   [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 destina-
       tion 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 func-
       tion 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]
3   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). The effect of the implicit conversion is the same as
    performing the declaration and initialization and then using the temporary variable as the result of the con-
    version. The result is an lvalue if T is a reference type (8.3.2), and an rvalue otherwise. The expression e
    is used as an lvalue if and only if the initialization uses it as an lvalue.
4   [Note: For user-defined types, user-defined 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-
    defined conversion followed by another standard conversion sequence.
5   There are some contexts where certain conversions are suppressed. For example, the lvalue-to-rvalue con-
    version is not done on the operand of the unary & operator. Specific exceptions are given in the descrip-
    tions of those operators and contexts. ]

    4.1 Lvalue-to-rvalue conversion                                                                                       [conv.lval]
1   An lvalue (3.10) of a non-function, non-array type T can be converted to an rvalue. If T is an incomplete
    type, a program that necessitates this conversion is ill-formed. If the object to which the lvalue 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 undefined behavior. If T is a non-class type, the type of the rvalue is
    the cv-unqualified version of T. Otherwise, the type of the rvalue is T. 49)
    __________________
    49) In C++ class rvalues can have cv-qualified types (because they are objects). This differs from ISO C, in which non-lvalues never
    have cv-qualified types.


                                                                                                                                    57
    ISO/IEC 14882:1998(E)                                                                                                   © ISO/IEC

    4.1 Lvalue-to-rvalue conversion                                                                          4 Standard conversions



2   The value contained in the object indicated by the lvalue is the rvalue result. When an lvalue-to-rvalue con-
    version occurs within the operand of sizeof (5.3.3) the value contained in the referenced object is not
    accessed, since that operator does not evaluate its operand.
3   [Note: See also 3.10. ]

    4.2 Array-to-pointer conversion                                                                                      [conv.array]
1   An lvalue or rvalue of type "array of N T" or "array of unknown bound of T" can be converted to an rvalue
    of type "pointer to T." The result is a pointer to the first element of the array.
2   A string literal (2.13.4) that is not a wide string literal can be converted to an rvalue of type "pointer to
    char"; a wide string literal can be converted to an rvalue of type "pointer to wchar_t". In either case,
    the result is a pointer to the first element of the array. This conversion is considered only when there is an
    explicit appropriate pointer target type, and not when there is a general need to convert from an lvalue to an
    rvalue. [Note: this conversion is deprecated. See Annex D. ] For the purpose of ranking in overload reso-
    lution (13.3.3.1.1), this conversion is considered an array-to-pointer conversion followed by a qualification
    conversion (4.4). [Example: "abc" is converted to "pointer to const char" as an array-to-pointer con-
    version, and then to "pointer to char" as a qualification conversion. ]

    4.3 Function-to-pointer conversion                                                                                     [conv.func]
1   An lvalue of function type T can be converted to an rvalue of type "pointer to T." The result is a pointer to
    the function.50)
2   [Note: See 13.4 for additional rules for the case where the function is overloaded. ]

    4.4 Qualification conversions                                                                                          [conv.qual]
1   An rvalue of type "pointer to cv1 T" can be converted to an rvalue of type "pointer to cv2 T" if "cv2 T" is
    more cv-qualified than "cv1 T."
2   An rvalue of type "pointer to member of X of type cv1 T" can be converted to an rvalue of type "pointer to
    member of X of type cv2 T" if "cv2 T" is more cv-qualified than "cv1 T."
3   [Note: Function types (including those used in pointer to member function types) are never cv-qualified
    (8.3.5). ]
4   A conversion can add cv-qualifiers at levels other than the first in multi-level pointers, subject to the fol-
    lowing rules:51)
       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-qualifiers
         after the first in a pointer type, e.g., cv 1 , 1 , cv 1 , 2 , . . . , cv 1 ,n in the pointer type T1, is called the cv-
         qualification signature of the pointer type. An expression of type T1 can be converted to type T2 if and
         only if the following conditions are satisfied:
             -- 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.
             -- if the cv 1 , j and cv 2 , j are different, then const is in every cv 2 ,k for 0 < k < j.
    __________________
    50) This conversion never applies to nonstatic member functions because an lvalue that refers to a nonstatic member function cannot be
    obtained.
    51) These rules ensure that const-safety is preserved by the conversion.




    58
    © ISO/IEC                                                                                      ISO/IEC 14882:1998(E)

    4 Standard conversions                                                                       4.4 Qualification conversions



    [Note: if a program could assign a pointer of type T** to a pointer of type const T** (that is, if line //1
    below was 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;            //1: not allowed
                  *pcc = &c;
                  *pc = 'C';              //2: modifies a const object
          }
    --end note]
5   A multi-level pointer to member type, or a multi-level mixed pointer and pointer to member type has the
    form:
                  cv 0 P 0 to cv 1 P 1 to . . . cv n - 1 P n - 1 to cv n T
    where P i is either a pointer or pointer to member and where T is not a pointer type or pointer to member
    type.
6   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 P 0 to cv 1 , 1 P 1 to . . . cv 1 ,n - 1 P n - 1 to cv 1 ,n T
    and
                  T2 is cv 2 , 0 P 0 to cv 2 , 1 P 1 to . . . cv 2 ,n - 1 P n - 1 to cv 2 ,n T

7   For similar multi-level pointer to member types and similar multi-level mixed pointer and pointer to mem-
    ber types, the rules for adding cv-qualifiers are the same as those used for similar pointer types.

    4.5 Integral promotions                                                                                     [conv.prom]
1   An rvalue of type char, signed char, unsigned char, short int, or unsigned short
    int can be converted to an rvalue of type int if int can represent all the values of the source type; other-
    wise, the source rvalue can be converted to an rvalue of type unsigned int.
2   An rvalue of type wchar_t (3.9.1) or an enumeration type (7.2) can be converted to an rvalue of the first
    of the following types that can represent all the values of its underlying type: int, unsigned int,
    long, or unsigned long.
3   An rvalue for an integral bit-field (9.6) can be converted to an rvalue of type int if int can represent all
    the values of the bit-field; otherwise, it can be converted to unsigned int if unsigned int can rep-
    resent all the values of the bit-field. If the bit-field is larger yet, no integral promotion applies to it. If the
    bit-field has an enumerated type, it is treated as any other value of that type for promotion purposes.
4   An rvalue of type bool can be converted to an rvalue of type int, with false becoming zero and true
    becoming one.
5   These conversions are called integral promotions.

    4.6 Floating point promotion                                                                              [conv.fpprom]
1   An rvalue of type float can be converted to an rvalue of type double. The value is unchanged.
2   This conversion is called floating point promotion.




                                                                                                                           59
    ISO/IEC 14882:1998(E)                                                                                © ISO/IEC

    4.7 Integral conversions                                                                4 Standard conversions



    4.7 Integral conversions                                                                        [conv.integral]
1   An rvalue of an integer type can be converted to an rvalue of another integer type. An rvalue of an enumer-
    ation type can be converted to an rvalue of an integer type.
2   If the destination type is unsigned, the resulting value is the least unsigned integer congruent to the source
    integer (modulo 2 n 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). ]
3   If the destination type is signed, the value is unchanged if it can be represented in the destination type (and
    bit-field width); otherwise, the value is implementation-defined.
4   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.
5   The conversions allowed as integral promotions are excluded from the set of integral conversions.

    4.8 Floating point conversions                                                                   [conv.double]
1   An rvalue of floating point type can be converted to an rvalue of another floating point type. If the source
    value can be exactly represented in the destination type, the result of the conversion is that exact representa-
    tion. If the source value is between two adjacent destination values, the result of the conversion is an
    implementation-defined choice of either of those values. Otherwise, the behavior is undefined.
2   The conversions allowed as floating point promotions are excluded from the set of floating point conver-
    sions.

    4.9 Floating-integral conversions                                                                  [conv.fpint]
1   An rvalue of a floating point type can be converted to an rvalue of an integer type. The conversion trun-
    cates; that is, the fractional part is discarded. The behavior is undefined if the truncated value cannot be
    represented in the destination type. [Note: If the destination type is bool, see 4.12. ]
2   An rvalue of an integer type or of an enumeration type can be converted to an rvalue of a floating point
    type. The result is exact if possible. Otherwise, it is an implementation-defined choice of either the next
    lower or higher representable value. [Note: loss of precision occurs if the integral value cannot be repre-
    sented exactly as a value of the floating type. ] If the source type is bool, the value false is converted to
    zero and the value true is converted to one.

    4.10 Pointer conversions                                                                             [conv.ptr]
1   A null pointer constant is an integral constant expression (5.19) rvalue of integer type that evaluates to
    zero. 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 pointer to object or pointer to function type. Two null
    pointer values of the same type shall compare equal. The conversion of a null pointer constant to a pointer
    to cv-qualified type is a single conversion, and not the sequence of a pointer conversion followed by a qual-
    ification conversion (4.4).
2   An rvalue of type "pointer to cv T," where T is an object type, can be converted to an rvalue 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).
3   An rvalue of type "pointer to cv D," where D is a class type, can be converted to an rvalue 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 sub-object of the derived class object. The null pointer value is converted to the
    null pointer value of the destination type.




    60
    © ISO/IEC                                                                                                 ISO/IEC 14882:1998(E)

    4 Standard conversions                                                                        4.11 Pointer to member conversions



    4.11 Pointer to member conversions                                                                                        [conv.mem]
1   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. 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-qualified type is a single conversion, and not the sequence of
    a pointer to member conversion followed by a qualification conversion (4.4).
2   An rvalue of type "pointer to member of B of type cv T," where B is a class type, can be converted to an
    rvalue 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, 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 sub-object of D. The null member pointer value is converted to
    the null member pointer value of the destination type.52)

    4.12 Boolean conversions                                                                                                   [conv.bool]
1   An rvalue of arithmetic, enumeration, pointer, or pointer to member type can be converted to an rvalue 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.




    __________________
    52) 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 a pointer to object or a pointer to function 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*.




                                                                                                                                           61
ISO/IEC 14882:1998(E)                  ©   ISO/IEC




                        (Blank page)




62
    © ISO/IEC                                                                                           ISO/IEC 14882:1998(E)

    5 Expressions                                                                                                 5 Expressions




    5 Expressions                                                                                                   [expr]
1   [Note: Clause 5 defines the syntax, order of evaluation, and meaning of expressions. An expression is a
    sequence of operators and operands that specifies a computation. An expression can result in a value and
    can cause side effects.
2   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 specified in clause 5, but the requirements of operand
    type, lvalue, 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]
3   Clause 5 defines the effects 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 defined by this Standard. However, these built-in operators participate in overload
    resolution, and as part of that process user-defined conversions will be considered where necessary to con-
    vert the operands to types appropriate for the built-in operator. If a built-in operator is selected, such con-
    versions 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.
4   Except where noted, the order of evaluation of operands of individual operators and subexpressions of indi-
    vidual expressions, and the order in which side effects take place, is unspecified.53) Between the previous
    and next sequence point a scalar object shall have its stored value modified at most once by the evaluation
    of an expression. Furthermore, the prior value shall be accessed only to determine the value to be stored.
    The requirements of this paragraph shall be met for each allowable ordering of the subexpressions of a full
    expression; otherwise the behavior is undefined. [Example:
          i = v[i++];                                             // the behavior is unspecified
          i = 7, i++, i++;                                        // i becomes 9

          i = ++i + 1;                                            // the behavior is unspecified
          i = i + 1;                                              // the value of i is incremented
    --end example]
5   If during the evaluation of an expression, the result is not mathematically defined or not in the range of rep-
    resentable values for its type, the behavior is undefined, unless such an expression is a constant expression
    (5.19), in which case the program is ill-formed. [Note: most existing implementations of C++ ignore inte-
    ger overflows. Treatment of division by zero, forming a remainder using a zero divisor, and all floating
    point exceptions vary among machines, and is usually adjustable by a library function. ]
6   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 expres-
    sion is an lvalue.
7   An expression designating an object is called an object-expression.
8   Whenever an lvalue expression appears as an operand of an operator that expects an rvalue 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 an rvalue. [Note: because cv-qualifiers are removed from the type of
    an expression of non-class type when the expression is converted to an rvalue, an lvalue expression of type
    const int can, for example, be used where an rvalue expression of type int is required. ]
    __________________
    53) The precedence of operators is not directly specified, but it can be derived from the syntax.




                                                                                                                            63
     ISO/IEC 14882:1998(E)                                                                                                        © ISO/IEC

     5 Expressions                                                                                                              5 Expressions



9    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 defined as follows:
     -- 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.54)
     -- Then, if either operand is unsigned long the other shall be converted to unsigned long.
     -- Otherwise, if one operand is a long int and the other unsigned int, then if a long int can rep-
        resent all the values of an unsigned int, the unsigned int shall be converted to a long int;
        otherwise both operands shall be converted to unsigned long int.
     -- Otherwise, if either operand is long, the other shall be converted to long.
     -- Otherwise, if either operand is unsigned, the other shall be converted to unsigned.
     [Note: otherwise, the only remaining case is that both operands are int ]
10   The values of the floating operands and the results of floating expressions may be represented in greater
     precision and range than that required by the type; the types are not changed thereby.55)

     5.1 Primary expressions                                                                                                     [expr.prim]
1    Primary expressions are literals, names, and names qualified by the scope resolution operator ::.
           primary-expression:
                      literal
                      this
                      ( expression )
                      id-expression

           id-expression:
                       unqualified-id
                       qualified-id

           unqualified-id:
                       identifier
                       operator-function-id
                       conversion-function-id
                       ~ class-name
                       template-id

2    A literal is a primary expression. Its type depends on its form (2.13). A string literal is an lvalue; all other
     literals are rvalues.
3    The keyword this names a pointer to the object for which a nonstatic member function (9.3.2) is invoked.
     The keyword this shall be used only inside a nonstatic class member function body (9.3) or in a construc-
     tor mem-initializer (12.6.2). The type of the expression is a pointer to the function's class (9.3.2), possibly
     with cv-qualifiers on the class type. The expression is an rvalue.
4    The operator :: followed by an identifier, a qualified-id, or an operator-function-id is a primary-
     expression. Its type is specified by the declaration of the identifier, qualified-id, or operator-function-id.
     The result is the entity denoted by the identifier, qualified-id, or operator-function-id. The result is an
     lvalue if the entity is a function or variable. The identifier, qualified-id, or operator-function-id shall have
     __________________
     54) As a consequence, operands of type bool, wchar_t, or an enumerated type are converted to some integral type.
     55) The cast and assignment operators must still perform their specific conversions as described in 5.4, 5.2.9 and 5.17.




     64
     © ISO/IEC                                                                           ISO/IEC 14882:1998(E)

     5 Expressions                                                                         5.1 Primary expressions



     global namespace scope or be visible in global scope because of a using-directive (7.3.4). [Note: the use of
     :: allows a type, an object, a function, an enumerator, or a namespace declared in the global namespace to
     be referred to even if its identifier has been hidden (3.4.3). ]
5    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 affect 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.
6    An id-expression is a restricted form of a primary-expression. [Note: an id-expression can appear after .
     and -> operators (5.2.5). ]
7    An identifier is an id-expression provided it has been suitably declared (clause 7). [Note: for operator-
     function-ids, see 13.5; for conversion-function-ids, see 12.3.2; for template-ids, see 14.2. A class-name
     prefixed by ~ denotes a destructor; see 12.4. Within the definition of a nonstatic member function, an
     identifier that names a nonstatic member is transformed to a class member access expression (9.3.1). ] The
     type of the expression is the type of the identifier. The result is the entity denoted by the identifier. The
     result is an lvalue if the entity is a function, variable, or data member.
          qualified-id:
                      ::opt nested-name-specifier templateopt unqualified-id
                      :: identifier
                      :: operator-function-id
                      :: template-id

          nested-name-specifier:
                    class-or-namespace-name :: nested-name-specifieropt
                    class-or-namespace-name :: template nested-name-specifier

          class-or-namespace-name:
                     class-name
                     namespace-name
     A nested-name-specifier that names a class, optionally followed by the keyword template (14.8.1), 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
     qualified-id; 3.4.3.1 describes name lookup for class members that appear in qualified-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. [Note: a class member can be referred to using a qualified-id at any
     point in its potential scope (3.3.6). ] 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). [Note: a
     typedef-name that names a class is a class-name (7.1.3). Except as the identifier in the declarator for a con-
     structor or destructor definition outside of a class member-specification (12.1, 12.4), a typedef-name that
     names a class may be used in a qualified-id to refer to a constructor or destructor. ]
8    A nested-name-specifier that names a namespace (7.3), followed by the name of a member of that name-
     space (or the name of a member of a namespace made visible by a using-directive ) is a qualified-id; 3.4.3.2
     describes name lookup for namespace members that appear in qualified-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 vari-
     able.
9    In a qualified-id, if the id-expression is a conversion-function-id, its conversion-type-id shall denote the
     same type in both the context in which the entire qualified-id occurs and in the context of the class denoted
     by the nested-name-specifier.
10   An id-expression that denotes a nonstatic data member or nonstatic 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 class or a
        class derived from that class, or



                                                                                                                65
     ISO/IEC 14882:1998(E)                                                                                © ISO/IEC

     5.1 Primary expressions                                                                            5 Expressions



     -- to form a pointer to member (5.3.1), or
     -- in the body of a nonstatic member function of that class or of a class derived from that class (9.3.1), or
     -- in a mem-initializer for a constructor for that class or for a class derived from that class (12.6.2).
11   A template-id shall be used as an unqualified-id only as specified in 14.7.2, 14.7, and 14.5.4.

     5.2 Postfix expressions                                                                              [expr.post]
1    Postfix expressions group left-to-right.
           postfix-expression:
                       primary-expression
                       postfix-expression [ expression ]
                       postfix-expression ( expression-listopt )
                       simple-type-specifier ( expression-listopt )
                       typename ::opt nested-name-specifier identifier ( expression-listopt )
                       typename ::opt nested-name-specifier templateopt template-id ( expression-listopt )
                       postfix-expression . templateopt id-expression
                       postfix-expression -> templateopt id-expression
                       postfix-expression . pseudo-destructor-name
                       postfix-expression -> pseudo-destructor-name
                       postfix-expression ++
                       postfix-expression --
                       dynamic_cast < type-id > ( expression )
                       static_cast < type-id > ( expression )
                       reinterpret_cast < type-id > ( expression )
                       const_cast < type-id > ( expression )
                       typeid ( expression )
                       typeid ( type-id )

           expression-list:
                       assignment-expression
                       expression-list , assignment-expression

           pseudo-destructor-name:
                      ::opt nested-name-specifieropt type-name :: ~ type-name
                      ::opt nested-name-specifier template template-id :: ~ type-name
                      ::opt nested-name-specifieropt ~ type-name


     5.2.1 Subscripting                                                                                    [expr.sub]
1    A postfix expression followed by an expression in square brackets is a postfix expression. One of the
     expressions shall have the type "pointer to T" and the other shall have enumeration or integral type. The
     result is an lvalue of type "T." The type "T" shall be a completely-defined object type.56) The expression
     E1[E2] is identical (by definition) to *((E1)+(E2)). [Note: see 5.3 and 5.7 for details of * and + and
     8.3.4 for details of arrays. ]

     5.2.2 Function call                                                                                   [expr.call]
1    There are two kinds of function call: ordinary function call and member function57) (9.3) call. A function
     call is a postfix 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 postfix
     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 postfix expression), or it shall have pointer to function type. Calling a
     function through an expression whose function type has a language linkage that is different from the
     __________________
     56) This is true even if the subscript operator is used in the following common idiom: &x[0].
     57) A static member function (9.4) is an ordinary function.




     66
    © ISO/IEC                                                                             ISO/IEC 14882:1998(E)

    5 Expressions                                                                                 5.2.2 Function call



    language linkage of the function type of the called function's definition is undefined (7.5). For a member
    function call, the postfix expression shall be an implicit (9.3.1, 9.4) or explicit class member access (5.2.5)
    whose id-expression is a function member name, or a pointer-to-member expression (5.5) selecting a func-
    tion member. The first expression in the postfix expression is then called the object expression, and the call
    is as a member of the object pointed to or referred to. 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). ] If a function or member function name is used, the name can be over-
    loaded (clause 13), in which case the appropriate function shall be selected according to the rules in 13.3.
    The function called in a member function call is normally selected according to the static type of the object
    expression (clause 10), but if that function is virtual and is not specified using a qualified-id then the
    function actually called will be the final overrider (10.3) of the selected function in the dynamic type of the
    object expression [Note: the dynamic type is the type of the object pointed or 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. ]
2   If no declaration of the called function is visible from the scope of the call the program is ill-formed.
3   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 different. This type shall be a com-
    plete object type, a reference type or the type void.
4   When a function is called, each parameter (8.3.5) shall be initialized (8.5, 12.8, 12.1) with its corresponding
    argument. When a function is called, the parameters that have object type shall have completely-defined
    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. ] During the initial-
    ization 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 defined 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. ] 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 final overrider is different from the return type of the statically chosen function, the value
    returned from the final overrider is converted to the return type of the statically chosen function.
5   [Note: a function can change the values of its non-const parameters, but these changes cannot affect the val-
    ues of the arguments except where a parameter is of a reference type (8.3.2); if the reference is to a const-
    qualified 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.5, 2.13, 2.13.4, 8.3.4, 12.2). In addition, it is possible to modify the values of nonconstant
    objects through pointer parameters. ]
6   A function can be declared to accept fewer arguments (by declaring default arguments (8.3.6)) or more
    arguments (by using the ellipsis, ... 8.3.5) than the number of parameters in the function definition (8.4).
    [Note: this implies that, except where the ellipsis (...) is used, a parameter is available for each argument.
    ]
7   When there is no parameter for a given argument, the argument is passed in such a way that the receiving
    function can obtain the value of the argument by invoking va_arg (18.7). 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. After these conversions, if the argument does not have arithmetic, enumeration, pointer,
    pointer to member, or class type, the program is ill-formed. If the argument has a non-POD class type
    (clause 9), the behavior is undefined. If the argument has integral or enumeration type that is subject to the
    integral promotions (4.5), or a floating point type that is subject to the floating point promotion (4.6), the
    value of the argument is converted to the promoted type before the call. These promotions are referred to



                                                                                                                  67
     ISO/IEC 14882:1998(E)                                                                                                     © ISO/IEC

     5.2.2 Function call                                                                                                    5 Expressions



     as the default argument promotions.
8    The order of evaluation of arguments is unspecified. All side effects of argument expression evaluations
     take effect before the function is entered. The order of evaluation of the postfix expression and the argu-
     ment expression list is unspecified.
9    Recursive calls are permitted, except to the function named main (3.6.1).
10   A function call is an lvalue if and only if the result type is a reference.

     5.2.3 Explicit type conversion (functional notation)                                                               [expr.type.conv]
1    A simple-type-specifier (7.1.5) followed by a parenthesized expression-list constructs a value of the speci-
     fied type given the expression list. If the expression list is a single expression, the type conversion expres-
     sion is equivalent (in definedness, and if defined in meaning) to the corresponding cast expression (5.4). If
     the simple-type-specifier specifies a class type, the class type shall be complete. If the expression list speci-
     fies 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 effect to the declaration T t(x1, x2, ...); for
     some invented temporary variable t, with the result being the value of t as an rvalue.
2    The expression T(), where T is a simple-type-specifier (7.1.5.2) for a non-array complete object type or
     the (possibly cv-qualified) void type, creates an rvalue of the specified type, whose value is determined by
     default-initialization (8.5; no initialization is done for the void() case). [Note: if T is a non-class type
     that is cv-qualified, the cv-qualifiers are ignored when determining the type of the resulting rvalue
     (3.10). ]

     5.2.4 Pseudo destructor call                                                                                          [expr.pseudo]
1    The use of a pseudo-destructor-name after a dot . or arrow -> operator represents the destructor for the
     non-class type named by type-name. The result shall only be used as the operand for the function call oper-
     ator (), and the result of such a call has type void. The only effect is the evaluation of the postfix-
     expression before the dot or arrow.
2    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 type designated by the pseudo-
     destructor-name shall be the same as the object type. Furthermore, the two type-names in a pseudo-
     destructor-name of the form
           ::opt nested-name-specifieropt type-name :: ~ type-name
     shall designate the same scalar type. The cv-unqualified versions of the object type and of the type desig-
     nated by the pseudo-destructor-name shall be the same type.

     5.2.5 Class member access                                                                                                   [expr.ref]
1    A postfix expression followed by a dot . or an arrow ->, optionally followed by the keyword template
     (14.8.1), and then followed by an id-expression, is a postfix expression. The postfix expression before the
     dot or arrow is evaluated;58) the result of that evaluation, together with the id-expression, determine the
     result of the entire postfix expression.
2    For the first option (dot) the type of the first expression (the object expression) shall be "class object" (of a
     complete type). For the second option (arrow) the type of the first expression (the pointer expression) shall
     be "pointer to class object" (of a complete type). In these cases, 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. ] [Note: 3.4.5 describes
     how names are looked up after the . and -> operators. ]
     __________________
     58) This evaluation happens even if the result is unnecessary to determine the value of the entire postfix expression, for example if the
     id-expression denotes a static member.




     68
    © ISO/IEC                                                                           ISO/IEC 14882:1998(E)

    5 Expressions                                                                       5.2.5 Class member access



3   If E1 has the type "pointer to class X," then the expression E1->E2 is converted to the equivalent form
    (*(E1)).E2; the remainder of 5.2.5 will address only the first option (dot)59). Abbreviating object-
    expression.id-expression as E1.E2, then the type and lvalue properties of this expression are determined as
    follows. In the remainder of 5.2.5, cq represents either const or the absence of const; vq represents
    either volatile or the absence of volatile. cv represents an arbitrary set of cv-qualifiers, as defined
    in 3.9.3.
4   If E2 is declared to have type "reference to T", then E1.E2 is an lvalue; the type of E1.E2 is T. Other-
    wise, 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 desig-
       nates 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 first expression. If E1 is
       an lvalue, then E1.E2 is an lvalue. 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 mem-
       ber, 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 deter-
       mine 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
           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 returning T", then E1.E2 is not an lvalue. 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). ] 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 not an lvalue. The
       type of E1.E2 is T.
5   [Note: "class objects" can be structures (9.2) and unions (9.5). Classes are discussed in clause 9. ]

    5.2.6 Increment and decrement                                                                [expr.post.incr]
1   The value obtained by applying a postfix ++ is the value that the operand had before applying the operator.
    [Note: the value obtained is a copy of the original value ] The operand shall be a modifiable lvalue. The
    type of the operand shall be an arithmetic type or a pointer to a complete object type. After the result is
    noted, the value of the object is modified 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. ] The result is an rvalue. The type of the
    result is the cv-unqualified version of the type of the operand. See also 5.7 and 5.17.
2   The operand of postfix -- is decremented analogously to the postfix ++ operator, except that the operand
    shall not be of type bool. [Note: For prefix increment and decrement, see 5.3.2. ]




    __________________
    59) Note that if E1 has the type "pointer to class X", then (*(E1)) is an lvalue.




                                                                                                               69
    ISO/IEC 14882:1998(E)                                                                                                       © ISO/IEC

    5.2.7 Dynamic cast                                                                                                      5 Expressions



    5.2.7 Dynamic cast                                                                                             [expr.dynamic.cast]
1   The result of the expression dynamic_cast<T>(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". Types shall not be
    defined in a dynamic_cast. The dynamic_cast operator shall not cast away constness (5.2.11).
2   If T is a pointer type, v shall be an rvalue of a pointer to complete class type, and the result is an rvalue of
    type T. If T is a 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.
3   If the type of v is the same as the required result type (which, for convenience, will be called R in this
    description), or it is the same as R except that the class object type in R is more cv-qualified than the class
    object type in v, the result is v (converted if necessary).
4   If the value of v is a null pointer value in the pointer case, the result is the null pointer value of type R.
5   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 sub-object 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 an lvalue for the unique60) B sub-object
    of the D object referred to by v. In both the pointer and reference cases, cv1 shall be the same cv-
    qualification as, or greater cv-qualification than, cv2, and B shall be an accessible unambiguous base class
    of D. [Example:
          struct B {};
          struct D : B {};
          void foo(D* dp)
          {
              B* bp = dynamic_cast<B*>(dp);                                     // equivalent to B* bp = dp;
          }
    --end example]
6   Otherwise, v shall be a pointer to or an lvalue of a polymorphic type (10.3).
7   If T is "pointer to cv void," then the result is a pointer to the most derived object pointed to by v. Other-
    wise, 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.
8   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 sub-
       object of a T object, and if only one object of type T is derived from the sub-object pointed (referred) to
       by v, the result is a pointer (an lvalue referring) to that T object.
    -- Otherwise, if v points (refers) to a public base class sub-object of the most derived object, and the
       type of the most derived object has an unambiguous public base class of type T, the result is a pointer
       (an lvalue referring) to the T sub-object 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 bad_cast (18.5.2).




    __________________
    60) The most derived object (1.8) pointed or referred to by v can contain other B objects as base classes, but these are ignored.




    70
    © ISO/IEC                                                                                          ISO/IEC 14882:1998(E)

    5 Expressions                                                                                               5.2.7 Dynamic cast



    [Example:
          class A { virtual void f(); };
          class B { virtual void g(); };
          class D : public virtual A, private B {};
          void g()
          {
              D   d;
              B* bp = (B*)&d;             // cast needed to break protection
              A* ap = &d;                 // public derivation, no cast needed
              D& dr = dynamic_cast<D&>(*bp);         // fails
              ap = dynamic_cast<A*>(bp);             // fails
              bp = dynamic_cast<B*>(ap);             // fails
              ap = dynamic_cast<A*>(&d);             // succeeds
              bp = dynamic_cast<B*>(&d);             // fails
          }

          class E : public D, public B {};
          class F : public E, public D {};
          void h()
          {
              F   f;
              A* ap = &f;                                                  // succeeds: finds unique A
              D* dp = dynamic_cast<D*>(ap);                                // fails: yields 0
                                                                           // f has two D sub-objects
                 E*    ep     = (E*)ap;                                    // ill-formed:
                                                                           // cast from virtual base
                 E*    ep1 = dynamic_cast<E*>(ap);                         // succeeds
          }
     --end example] [Note: 12.7 describes the behavior of a dynamic_cast applied to an object under con-
    struction or destruction. ]

    5.2.8 Type identification                                                                                        [expr.typeid]
1   The result of a typeid expression is an lvalue of static type const std::type_info (18.5.1) and
    dynamic type const std::type_info or const name where name is an implementation-defined
    class derived from std::type_info which preserves the behavior described in 18.5.1.61) 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 type_info object at the end of the program is unspecified.
2   When typeid is applied to an lvalue expression whose type is a polymorphic class type (10.3), the result
    refers to a type_info object representing the type of the most derived object (1.8) (that is, the dynamic
    type) to which the lvalue refers. If the lvalue expression is obtained by applying the unary * operator to a
    pointer62) and the pointer is a null pointer value (4.10), the typeid expression throws the bad_typeid
    exception (18.5.3).
3   When typeid is applied to an expression other than an lvalue of a polymorphic class type, the result
    refers to a type_info object representing the static type of the expression. Lvalue-to-rvalue (4.1), array-
    to-pointer (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-defined. The expression is not evaluated.
4   When typeid is applied to a type-id, the result refers to a type_info object representing the type of the
    type-id. If the type of the type-id is a reference type, the result of the typeid expression refers to a
    type_info object representing the 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-defined. Types shall not be defined in the type-id.
    __________________
    61) The recommended name for such a class is extended_type_info.
    62) If p is an expression of pointer type, then *p, (*p), *(p), ((*p)), *((p)), and so on all meet this requirement.




                                                                                                                               71
    ISO/IEC 14882:1998(E)                                                                                 © ISO/IEC

    5.2.8 Type identification                                                                          5 Expressions



5   The top-level cv-qualifiers of the lvalue 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(d2);                       // yields true
         typeid(D)       ==     typeid(const D);                  // yields true
         typeid(D)       ==     typeid(d2);                       // yields true
         typeid(D)       ==     typeid(const D&);                 // yields true
    --end example]
6   If the header <typeinfo> (18.5.1) is not included prior to a use of typeid, the program is ill-formed.
7   [Note: 12.7 describes the behavior of typeid applied to an object under construction or destruction. ]

    5.2.9 Static cast                                                                               [expr.static.cast]
1   The result of the expression static_cast<T>(v) is the result of converting the expression v to type T.
    If T is a reference type, the result is an lvalue; otherwise, the result is an rvalue. Types shall not be defined
    in a static_cast. The static_cast operator shall not cast away constness (5.2.11).
2   An expression e can be explicitly converted to a type T using a static_cast of the form
    static_cast<T>(e) if the declaration "T t(e);" is well-formed, for some invented temporary vari-
    able t (8.5). The effect of such an explicit conversion is the same as performing the declaration and initial-
    ization and then using the temporary variable as the result of the conversion. The result is an lvalue if T is a
    reference type (8.3.2), and an rvalue otherwise. The expression e is used as an lvalue if and only if the
    initialization uses it as an lvalue.
3   Otherwise, the static_cast shall perform one of the conversions listed below. No other conversion
    shall be performed explicitly using a static_cast.
4   Any expression can be explicitly converted to type "cv void." The expression value is discarded. [Note:
    however, if the value is in a temporary variable (12.2), the destructor for that variable is not executed until
    the usual time, and the value of the variable is preserved for the purpose of executing the destructor. ] The
    lvalue-to-rvalue (4.1), array-to-pointer (4.2), and function-to-pointer (4.3) standard conversions are not
    applied to the expression.
5   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-qualification as, or greater cv-qualification than, cv1, and B is not a virtual base
    class of D. The result is an lvalue of type "cv2 D." If the lvalue of type "cv1 B" is actually a sub-object of
    an object of type D, the lvalue refers to the enclosing object of type D. Otherwise, the result of the cast is
    undefined. [Example:
         struct B {};
         struct D : public B {};
         D d;
         B &br = d;

         static_cast<D&>(br);                         // produces lvalue to the original d object
    --end example]
6   The inverse of any standard conversion sequence (clause 4), other than the lvalue-to-rvalue (4.1), array-to-
    pointer (4.2), function-to-pointer (4.3), and boolean (4.12) conversions, can be performed explicitly using
    static_cast subject to the restriction that the explicit conversion does not cast away constness (5.2.11),
    and the following additional rules for specific cases:




    72
     © ISO/IEC                                                                                              ISO/IEC 14882:1998(E)

     5 Expressions                                                                                                       5.2.9 Static cast



7    A value of integral type can be explicitly converted to an enumeration type. The value is unchanged if the
     integral value is within the range of the enumeration values (7.2). Otherwise, the resulting enumeration
     value is unspecified.
8    An rvalue of type "pointer to cv1 B", where B is a class type, can be converted to an rvalue 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-qualification as, or greater cv-qualification than, cv1, and
     B is not 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 rvalue of type "pointer to cv1 B" points to a B that is actually a sub-object of an
     object of type D, the resulting pointer points to the enclosing object of type D. Otherwise, the result of the
     cast is undefined.
9    An rvalue of type "pointer to member of D of type cv1 T" can be converted to an rvalue 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-qualification as, or greater cv-qualification than, cv1.63) The null member pointer value (4.11) is con-
     verted 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 undefined. [Note: although class B need
     not contain the original member, the dynamic type of the object on which the pointer to member is derefer-
     enced must contain the original member; see 5.5. ]
10   An rvalue of type "pointer to cv void" can be explicitly converted to a pointer to object type. A value of
     type pointer to object converted to "pointer to cv void" and back to the original pointer type will have its
     original value.

     5.2.10 Reinterpret cast                                                                                  [expr.reinterpret.cast]
1    The result of the expression reinterpret_cast<T>(v) is the result of converting the expression v to
     type T. If T is a reference type, the result is an lvalue; otherwise, the result is an rvalue and the lvalue-to-
     rvalue (4.1), array-to-pointer (4.2), and function-to-pointer (4.3) standard conversions are performed on the
     the expression v. Types shall not be defined in a reinterpret_cast. Conversions that can be per-
     formed explicitly using reinterpret_cast are listed below. No other conversion can be performed
     explicitly using reinterpret_cast.
2    The reinterpret_cast operator shall not cast away constness. [Note: see 5.2.11 for the definition of
     ``casting away constness''. Subject to the restrictions in this section, an expression may be cast to its own
     type using a reinterpret_cast operator. ]
3    The mapping performed by reinterpret_cast is implementation-defined. [Note: it might, or might
     not, produce a representation different from the original value. ]
4    A pointer can be explicitly converted to any integral type large enough to hold it. The mapping function is
     implementation-defined [Note: it is intended to be unsurprising to those who know the addressing structure
     of the underlying machine. ]
5    A value of integral type or enumeration type can be explicitly converted to a pointer.64) A pointer converted
     to an integer of sufficient 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-defined.
6    A pointer to a function can be explicitly converted to a pointer to a function of a different type. The effect
     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
     definition of the function is undefined. Except that converting an rvalue 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 result of such a pointer conversion is unspecified. [Note: see also 4.10 for more details of
     __________________
     63) Function types (including those used in pointer to member function types) are never cv-qualified; see 8.3.5 .
     64) Converting an integral constant expression (5.19) with value zero always yields a null pointer (4.10), but converting other expres-
     sions that happen to have value zero need not yield a null pointer.




                                                                                                                                        73
     ISO/IEC 14882:1998(E)                                                                                               © ISO/IEC

     5.2.10 Reinterpret cast                                                                                          5 Expressions



     pointer conversions. ]
7    A pointer to an object can be explicitly converted to a pointer to an object of different type.65) Except that
     converting an rvalue 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 such a pointer conversion is unspecified.
8    The null pointer value (4.10) is converted to the null pointer value of the destination type.
9    An rvalue of type "pointer to member of X of type T1" can be explicitly converted to an rvalue of type
     "pointer to member of Y of type T2" if T1 and T2 are both function types or both object types.66) 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 unspecified, except in the following cases:
     -- converting an rvalue of type "pointer to member function" to a different pointer to member function
        type and back to its original type yields the original pointer to member value.
     -- converting an rvalue of type "pointer to data member of X of type T1" to the type "pointer to data mem-
        ber 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.
10   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<T&>(x) has the same effect as the conversion
     *reinterpret_cast<T*>(&x) with the built-in & and * operators. The result is an lvalue that refers
     to the same object as the source lvalue, but with a different type. No temporary is created, no copy is made,
     and constructors (12.1) or conversion functions (12.3) are not called.67)

     5.2.11 Const cast                                                                                           [expr.const.cast]
1    The result of the expression const_cast<T>(v) is of type T. If T is a reference type, the result is an
     lvalue; otherwise, the result is an rvalue 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. Types shall not be
     defined in a const_cast. Conversions that can be performed explicitly using const_cast are listed
     below. No other conversion shall be performed explicitly using const_cast.
2    [Note: Subject to the restrictions in this section, an expression may be cast to its own type using a
     const_cast operator. ]
3    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
                    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 different cv-qualifications,
     an rvalue 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.
4    An lvalue of type T1 can be explicitly converted to an lvalue of type T2 using the cast
     const_cast<T2&> (where T1 and T2 are object types) if a pointer to T1 can be explicitly converted to
     the type pointer to T2 using a const_cast. The result of a reference const_cast refers to the origi-
     nal object.
     __________________
     65) The types may have different cv-qualifiers, subject to the overall restriction that a reinterpret_cast cannot cast away const-
     ness.
     66) T1 and T2 may have different cv-qualifiers, subject to the overall restriction that a reinterpret_cast cannot cast away const-
     ness.
     67) This is sometimes referred to as a type pun.




     74
     © ISO/IEC                                                                                     ISO/IEC 14882:1998(E)

     5 Expressions                                                                                        5.2.11 Const cast



5    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-
     qualifiers 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.
6    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.
7    [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-qualifier68) may produce undefined behav-
     ior (7.1.5.1). ]
8    The following rules define the process known as casting away constness. In these rules Tn and Xn repre-
     sent types. For two pointer types:
                    X 1 is T 1cv 1 , 1 * . . . cv 1 ,N *         where T 1 is not a pointer type
                    X 2 is T 2cv 2 , 1   * . . . cv 2 ,M *       where T 2 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 con-
     version (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    Casting from an lvalue of type T1 to an lvalue of type T2 using a reference cast casts away constness if a
     cast from an rvalue of type "pointer to T1" to the type "pointer to T2" casts away constness.
10   Casting from an rvalue of type "pointer to data member of X of type T1" to the type "pointer to data mem-
     ber of Y of type T2" casts away constness if a cast from an rvalue of type "pointer to T1" to the type
     "pointer to T2" casts away constness.
11   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-qualifier has
     been cast away.
12   [Note: some conversions which involve only changes in cv-qualification 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 undefined 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. ]




     __________________
     68) const_cast is not limited to conversions that cast away a const-qualifier.




                                                                                                                        75
    ISO/IEC 14882:1998(E)                                                                                   © ISO/IEC

    5.2.11 Const cast                                                                                     5 Expressions



    5.3 Unary expressions                                                                                 [expr.unary]
1   Expressions with unary operators group right-to-left.
         unary-expression:
                    postfix-expression
                    ++ cast-expression
                    -- cast-expression
                    unary-operator cast-expression
                    sizeof unary-expression
                    sizeof ( type-id )
                    new-expression
                    delete-expression

         unary-operator: one of
                    * & + -            !   ~


    5.3.1 Unary operators                                                                             [expr.unary.op]
1   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 an
    rvalue, see 4.1. ]
2   The result of the unary & operator is a pointer to its operand. The operand shall be an lvalue or a qualified-
    id. In the first case, if the type of the expression is "T," the type of the result is "pointer to T." In particular,
    the address of an object of type "cv T" is "pointer to cv T," with the same cv-qualifiers. For a qualified-id,
    if the member is a static member of type "T", the type of the result is plain "pointer to T." If the member is
    a nonstatic member of class C of type T, the type of the result is "pointer to member of class C of type
    T." [Example:
         struct A { int i; };
         struct B : A { };
         ... &B::i ...                               // has type int A::*
     --end example] [Note: a pointer to member formed from a mutable nonstatic data member (7.1.1) does
    not reflect the mutable specifier associated with the nonstatic data member. ]
3   A pointer to member is only formed when an explicit & is used and its operand is a qualified-id not
    enclosed in parentheses. [Note: that is, the expression &(qualified-id), where the qualified-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 qualified-id for a nonstatic member func-
    tion 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
    unqualified-id's class. ]
4   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 undefined (and no diagnostic
    is required). The operand of & shall not be a bit-field.
5   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 nonstatic member function, the context can also affect whether the expres-
    sion has type "pointer to function" or "pointer to member function." ]
6   The operand of the unary + operator shall have arithmetic, 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.



    76
    © ISO/IEC                                                                                          ISO/IEC 14882:1998(E)

    5 Expressions                                                                                           5.3.1 Unary operators



7   The operand of the unary - operator shall have arithmetic or 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 2 n , where n is the number of bits in the pro-
    moted operand. The type of the result is the type of the promoted operand.
8   The operand of the logical negation operator ! is implicitly 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.
9   The operand of ~ shall have integral or 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. The ambiguity is resolved in favor of
    treating ~ as a unary complement rather than treating ~X as referring to a destructor.

    5.3.2 Increment and decrement                                                                                  [expr.pre.incr]
1   The operand of prefix ++ is modified by adding 1, or set to true if it is bool (this use is deprecated).
    The operand shall be a modifiable lvalue. The type of the operand shall be an arithmetic type or a pointer
    to a completely-defined object type. The value is the new value of the operand; it is an lvalue. 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. ]
2   The operand of prefix -- is modified by subtracting 1. The operand shall not be of type bool. The
    requirements on the operand of prefix -- and the properties of its result are otherwise the same as those of
    prefix ++. [Note: For postfix increment and decrement, see 5.2.6. ]

    5.3.3 Sizeof                                                                                                      [expr.sizeof]
1   The sizeof operator yields the number of bytes in the object representation of its operand. The operand
    is either an expression, which is not evaluated, or a parenthesized type-id. The sizeof operator shall not
    be applied to an expression that has function or incomplete type, or to an enumeration type before all its
    enumerators have been declared, or to the parenthesized name of such types, or to an lvalue that designates
    a bit-field. 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-defined. [Note: in par-
    ticular, sizeof(bool) and sizeof(wchar_t) are implementation-defined.69) ] [Note: See 1.7 for
    the definition of byte and 3.9 for the definition of object representation. ]
2   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.70) 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.
3   The sizeof operator can be applied to a pointer to a function, but shall not be applied directly to a func-
    tion.
4   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.
5   Types shall not be defined in a sizeof expression.
6   The result is a constant of type size_t. [Note: size_t is defined in the standard header
    <cstddef>(18.1). ]


    __________________
    69) sizeof(bool) is not required to be 1.
    70) 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.




                                                                                                                                  77
    ISO/IEC 14882:1998(E)                                                                                  © ISO/IEC

    5.3.4 New                                                                                            5 Expressions



    5.3.4 New                                                                                              [expr.new]
1   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). [Note: because references are not objects, references cannot be
    created by new-expressions. ] [Note: the type-id may be a cv-qualified type, in which case the object cre-
    ated by the new-expression has a cv-qualified type. ]
         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-specifier-seq new-declaratoropt

         new-declarator:
                    ptr-operator new-declaratoropt
                    direct-new-declarator

         direct-new-declarator:
                    [ expression ]
                    direct-new-declarator [ constant-expression ]

         new-initializer:
                     ( expression-listopt )
    Entities created by a new-expression have dynamic storage duration (3.7.3). [Note: the lifetime of such an
    entity is not necessarily restricted to the scope in which it is created. ] If the entity is a non-array 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.
2   The new-type-id in a new-expression is the longest possible sequence of new-declarators. [Note: this pre-
    vents ambiguities between declarator operators &, *, [], and their expression counterparts. ] [Example:
         new int * i;                                      // syntax error: parsed as (new int*) i
                                                           //          not as (new int)*i
    The * is the pointer declarator and not the multiplication operator. ]
3   [Note: parentheses in a new-type-id of a new-expression can have surprising effects. [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])());

    allocates an array of 10 pointers to functions (taking no argument and returning int). ] ]
4   The type-specifier-seq shall not contain class declarations, or enumeration declarations.
5   When the allocated object is an array (that is, the direct-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]. ]




    78
     © ISO/IEC                                                                           ISO/IEC 14882:1998(E)

     5 Expressions                                                                                        5.3.4 New



6    Every constant-expression in a direct-new-declarator shall be an integral constant expression (5.19) and
     evaluate to a strictly positive value. The expression in a direct-new-declarator shall have integral type
     (3.9.1) with a non-negative value. [Example: if n is a variable of type int, then new float[n][5] is
     well-formed (because n is the expression of a direct-new-declarator), but new float[5][n] is ill-
     formed (because n is not a constant-expression). If n is negative, the effect of new float[n][5] is
     undefined. ]
7    When the value of the expression in a direct-new-declarator is zero, the allocation function is called to allo-
     cate an array with no elements. The pointer returned by the new-expression is non-null. [Note: If the
     library allocation function is called, the pointer returned is distinct from the pointer to any other object. ]
8    A new-expression obtains storage for the object by calling an allocation function (3.7.3.1). If the new-
     expression terminates by throwing an exception, it may release storage by calling a deallocation function
     (3.7.3.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 alloca-
     tion function's name is operator new[] and the deallocation function's name is
     operator delete[]. [Note: an implementation shall provide default definitions for the global alloca-
     tion functions (3.7.3, 18.4.1.1, 18.4.1.2). A C++ program can provide alternative definitions of these func-
     tions (17.4.3.4) and/or class-specific versions (12.5). ]
9    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 find the name, or if the allocated type is not a
     class type, the allocation function's name is looked up in the global scope.
10   A new-expression passes the amount of space requested to the allocation function as the first argument of
     type std::size_t. That argument shall be no less than the size of the object being created; it may be
     greater than the size of the object being created only if the object is an array. For arrays of char and
     unsigned char, the difference between the result of the new-expression and the address returned by the
     allocation function shall be an integral multiple of the most stringent alignment requirement (3.9) 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, this
     constraint on array allocation overhead permits the common idiom of allocating character arrays into which
     objects of other types will later be placed. ]
11   The new-placement syntax is used to supply additional arguments to an allocation function. If used, over-
     load resolution is performed on a function call created by assembling an argument list consisting of the
     amount of space requested (the first argument) and the expressions in the new-placement part of the new-
     expression (the second and succeeding arguments). The first of these arguments has type size_t and the
     remaining arguments have the corresponding types of the expressions in the new-placement.
12   [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 unspecified values representing array allocation overhead; the result of the
     new-expression will be offset by this amount from the value returned by operator new[]. This over-
     head 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. ]
13   [Note: unless an allocation function is declared with an empty exception-specification (15.4), throw(), it
     indicates failure to allocate storage by throwing a bad_alloc exception (clause 15, 18.4.2.1); it returns a
     non-null pointer otherwise. If the allocation function is declared with an empty exception-specification,



                                                                                                                 79
     ISO/IEC 14882:1998(E)                                                                                 © ISO/IEC

     5.3.4 New                                                                                          5 Expressions



     throw(), it returns null to indicate failure to allocate storage and a non-null pointer otherwise. ] 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.
14   [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. ]
15   A new-expression that creates an object of type T initializes that object as follows:
     -- If the new-initializer is omitted:
          -- If T is a (possibly cv-qualified) non-POD class type (or array thereof), the object is default-
             initialized (8.5) If T is a const-qualified type, the underlying class type shall have a user-declared
             default constructor.
          -- Otherwise, the object created has indeterminate value. If T is a const-qualified type, or a (possibly
             cv-qualified) POD class type (or array thereof) containing (directly or indirectly) a member of
             const-qualified type, the program is ill-formed;
     -- If the new-initializer is of the form (), default-initialization shall be performed (8.5);
     -- If the new-initializer is of the form (expression-list) and T is a class type, the appropriate constructor is
        called, using expression-list as the arguments (8.5);
     -- If the new-initializer is of the form (expression-list) and T is an arithmetic, enumeration, pointer, or
        pointer-to-member type and expression-list comprises exactly one expression, then the object is initial-
        ized to the (possibly converted) value of the expression (8.5);
     -- Otherwise the new-expression is ill-formed.
16   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).
17   If any part of the object initialization described above71) 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 func-
     tion does not allocate memory; otherwise, it is likely to result in a memory leak. ]
18   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 find 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.
19   A declaration of a placement deallocation function matches the declaration of a placement allocation func-
     tion if it has the same number of parameters and, after parameter transformations (8.3.5), all parameter
     types except the first are identical. Any non-placement deallocation function matches a non-placement
     allocation function. If the lookup finds a single matching deallocation function, that function will be called;
     otherwise, no deallocation function will be called.
20   If a new-expression calls a deallocation function, it passes the value returned from the allocation function
     call as the first 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 specified with the new-placement syntax. If the implementation is allowed to make a copy of any
     __________________
     71) This may include evaluating a new-initializer and/or calling a constructor.




     80
     © ISO/IEC                                                                                            ISO/IEC 14882:1998(E)

     5 Expressions                                                                                                            5.3.4 New



     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 allo-
     cation function. If the copy is elided in one place, it need not be elided in the other.
21   Whether the allocation function is called before evaluating the constructor arguments or after evaluating the
     constructor arguments but before entering the constructor is unspecified. It is also unspecified whether the
     arguments to a constructor are evaluated if the allocation function returns the null pointer or exits using an
     exception.

     5.3.5 Delete                                                                                                        [expr.delete]
1    The delete-expression operator destroys a most derived object (1.8) or array created by a new-expression.
           delete-expression:
                       ::opt delete cast-expression
                       ::opt delete [ ] cast-expression
     The first alternative is for non-array objects, and the second is for arrays. The operand shall have a pointer
     type, or a class type having a single conversion function (12.3.2) to a pointer type. The result has type
     void.
2    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
     this section. In either alternative, if the value of the operand of delete is the null pointer the operation
     has no effect. In the first alternative (delete object), the value of the operand of delete shall be a pointer
     to a non-array object or a pointer to a sub-object (1.8) representing a base class of such an object (clause
     10). If not, the behavior is undefined. In the second alternative (delete array), the value of the operand of
     delete shall be the pointer value which resulted from a previous array new-expression.72) If not, the
     behavior is undefined. [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. ] [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. ]
3    In the first alternative (delete object), if the static type of the operand is different from its dynamic type, the
     static type shall be a base class of the operand's dynamic type and the static type shall have a virtual
     destructor or the behavior is undefined. In the second alternative (delete array) if the dynamic type of the
     object to be deleted differs from its static type, the behavior is undefined.73)
4    The cast-expression in a delete-expression shall be evaluated exactly once. If the delete-expression calls
     the implementation deallocation function (3.7.3.2), and if the operand of the delete expression is not the
     null pointer constant, the deallocation function will deallocate the storage referenced by the pointer thus
     rendering the pointer invalid. [Note: the value of a pointer that refers to deallocated storage is indetermi-
     nate. ]
5    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 undefined.
6    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).
7    The delete-expression will call a deallocation function (3.7.3.2).
8    [Note: An implementation provides default definitions of the global deallocation functions
     operator delete() for non-arrays (18.4.1.1) and operator delete[]() for arrays (18.4.1.2).
     A C++ program can provide alternative definitions of these functions (17.4.3.4), and/or class-specific
     __________________
     72) For non-zero-length arrays, this is the same as a pointer to the first element of the array created by that new-expression. Zero-
     length arrays do not have a first element.
     73) This implies that an object cannot be deleted using a pointer of type void* because there are no objects of type void.




                                                                                                                                      81
    ISO/IEC 14882:1998(E)                                                                                  © ISO/IEC

    5.3.5 Delete                                                                                         5 Expressions



    versions (12.5). ] When the keyword delete in a delete-expression is preceded by the unary :: operator,
    the global deallocation function is used to deallocate the storage.
9   Access and ambiguity control are done for both the deallocation function and the destructor (12.4, 12.5).

    5.4 Explicit type conversion (cast notation)                                                           [expr.cast]
1   The result of the expression (T) cast-expression is of type T. The result is an lvalue if T is a reference
    type, otherwise the result is an rvalue. [Note: if T is a non-class type that is cv-qualified, the cv-qualifiers
    are ignored when determining the type of the resulting rvalue; see 3.10. ]
2   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   Types shall not be defined in casts.
4   Any type conversion not mentioned below and not explicitly defined by the user (12.3) is ill-formed.
5   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. If a conversion can be interpreted in more than one of the ways listed above, the interpre-
    tation that appears first 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:
         struct A {};
         struct I1 : A {};
         struct I2 : A {};
         struct D : I1, I2 {};
         A *foo( D *p ) {
                 return (A*)( p );                      // ill-formed static_cast interpretation
         }
    --end example]
6   The operand of a cast using the cast notation can be an rvalue of type "pointer to incomplete class type".
    The destination type of a cast using the cast notation can be "pointer to incomplete class type". In such
    cases, even if there is a inheritance relationship between the source and destination classes, whether the
    static_cast or reinterpret_cast interpretation is used is unspecified.
7   In addition to those conversions, the following static_cast and reinterpret_cast operations
    (optionally followed by a const_cast operation) may be performed using the cast notation of explicit
    type conversion, even if the base class type is not accessible:
    -- a pointer to an object of derived class type or an lvalue 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;



    82
    © ISO/IEC                                                                            ISO/IEC 14882:1998(E)

    5 Expressions                                                        5.4 Explicit type conversion (cast notation)



    -- a pointer to an object of non-virtual base class type, an lvalue of non-virtual base class type, or a pointer
       to member of 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.

    5.5 Pointer-to-member operators                                                              [expr.mptr.oper]
1   The pointer-to-member operators ->* and .* group left-to-right.
         pm-expression:
                    cast-expression
                    pm-expression .* cast-expression
                    pm-expression ->* cast-expression

2   The binary operator .* binds its second operand, which shall be of type "pointer to member of T" (where
    T is a completely-defined class type) to its first 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 specified by
    the second operand.
3   The binary operator ->* binds its second operand, which shall be of type "pointer to member of T" (where
    T is a completely-defined class type) to its first 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 result is an object or a function of the
    type specified by the second operand.
4   If the dynamic type of the object does not contain the member to which the pointer refers, the behavior is
    undefined.
5   The restrictions on cv-qualification, and the manner in which the cv-qualifiers of the operands are combined
    to produce the cv-qualifiers 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 {
                 mutable int i;
         };
         const S cs;
         int S::* pm = &S::i;                         // pm refers to mutable member S::i
         cs.*pm = 88;                                 // ill-formed: cs is a const object
    ]
6   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);

    calls the member function denoted by ptr_to_mfct for the object pointed to by ptr_to_obj. ] The
    result of a .* expression is an lvalue only if its first operand is an lvalue and its second operand is a
    pointer to data member. The result of an ->* expression is an lvalue only if its second operand is a pointer
    to data member. If the second operand is the null pointer to member value (4.11), the behavior is unde-
    fined.

    5.6 Multiplicative operators                                                                        [expr.mul]
1   The multiplicative operators *, /, and % group left-to-right.
         multiplicative-expression:
                     pm-expression
                     multiplicative-expression * pm-expression
                     multiplicative-expression / pm-expression
                     multiplicative-expression % pm-expression




                                                                                                                  83
    ISO/IEC 14882:1998(E)                                                                                                   © ISO/IEC

    5.6 Multiplicative operators                                                                                        5 Expressions



2   The operands of * and / shall have arithmetic or enumeration type; the operands of % shall have integral or
    enumeration type. The usual arithmetic conversions are performed on the operands and determine the type
    of the result.
3   The binary * operator indicates multiplication.
4   The binary / operator yields the quotient, and the binary % operator yields the remainder from the division
    of the first expression by the second. If the second operand of / or % is zero the behavior is undefined; oth-
    erwise (a/b)*b + a%b is equal to a. If both operands are nonnegative then the remainder is nonnega-
    tive; if not, the sign of the remainder is implementation-defined74).

    5.7 Additive operators                                                                                                  [expr.add]
1   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
    For addition, either both operands shall have arithmetic or enumeration type, or one operand shall be a
    pointer to a completely defined object type and the other shall have integral or enumeration type.
2   For subtraction, one of the following shall hold:
    -- both operands have arithmetic or enumeration type; or
    -- both operands are pointers to cv-qualified or cv-unqualified versions of the same completely defined
       object type; or
    -- the left operand is a pointer to a completely defined object type and the right operand has integral or
       enumeration type.
3   The result of the binary + operator is the sum of the operands. The result of the binary - operator is the dif-
    ference resulting from the subtraction of the second operand from the first.
4   For the purposes of these operators, a pointer to a nonarray object behaves the same as a pointer to the first
    element of an array of length one with the type of the object as its element type.
5   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 offset from the original element such that the difference of the sub-
    scripts of the resulting and original array elements equals the integral expression. In other words, if 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 ele-
    ment of the array object, the evaluation shall not produce an overflow; otherwise, the behavior is undefined.
6   When two pointers to elements of the same array object are subtracted, the result is the difference of the
    subscripts of the two array elements. The type of the result is an implementation-defined signed integral
    type; this type shall be the same type that is defined as ptrdiff_t in the <cstddef> header (18.1). As
    with any other arithmetic overflow, if the result does not fit in the space provided, the behavior is unde-
    fined. 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 fits in an object of type
    __________________
    74) According to work underway toward the revision of ISO C, the preferred algorithm for integer division follows the rules defined in
    the ISO Fortran standard, ISO/IEC 1539:1991, in which the quotient is always rounded toward zero.




    84
    © ISO/IEC                                                                                                 ISO/IEC 14882:1998(E)

    5 Expressions                                                                                                   5.7 Additive operators



    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 undefined.75)
8   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 function 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 ptrdiff_t.

    5.8 Shift operators                                                                                                         [expr.shift]
1   The shift operators << and >> group left-to-right.
          shift-expression:
                      additive-expression
                      shift-expression << additive-expression
                      shift-expression >> additive-expression
    The operands shall be of integral or enumeration type and integral promotions are performed. The type of
    the result is that of the promoted left operand. The behavior is undefined if the right operand is negative, or
    greater than or equal to the length in bits of the promoted left operand.
2   The value of E1 << E2 is E1 (interpreted as a bit pattern) left-shifted E2 bit positions; vacated bits are
    zero-filled. If E1 has an unsigned type, the value of the result is E1 multiplied by the quantity 2 raised to
    the power E2, reduced modulo ULONG_MAX+1 if E1 has type unsigned long, UINT_MAX+1 otherwise.
    [Note: the constants ULONG_MAX and UINT_MAX are defined in the header <climits>). ]
3   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 nonnegative value, the value of the result is the integral part of the quotient of E1 divided
    by the quantity 2 raised to the power E2. If E1 has a signed type and a negative value, the resulting value
    is implementation-defined.

    5.9 Relational operators                                                                                                       [expr.rel]
1   The relational operators group left-to-right.                        [Example: a<b<c               means       (a<b)<c         and     not
    (a<b)&&(b<c). ]
          relational-expression:
                      shift-expression
                      relational-expression        < shift-expression
                      relational-expression        > shift-expression
                      relational-expression        <= shift-expression
                      relational-expression        >= shift-expression
    The operands shall have arithmetic, enumeration or pointer type. The operators < (less than), > (greater
    than), <= (less than or equal to), and >= (greater than or equal to) all yield false or true. The type of
    the result is bool.


    __________________
    75) Another way to approach pointer arithmetic is first to convert the pointer(s) to character pointer(s): In this scheme the integral value
    of the expression added to or subtracted from the converted pointer is first multiplied by the size of the object originally pointed to, and
    the resulting pointer is converted back to the original type. For pointer subtraction, the result of the difference between the character
    pointers is similarly divided by the size of the object originally pointed to.

7   When viewed in this way, an implementation need only provide one extra byte (which might overlap another object in the program)
    just after the end of the object in order to satisfy the "one past the last element" requirements.




                                                                                                                                            85
    ISO/IEC 14882:1998(E)                                                                              © ISO/IEC

    5.9 Relational operators                                                                        5 Expressions



2   The usual arithmetic conversions are performed on operands of arithmetic or enumeration type. Pointer
    conversions (4.10) and qualification conversions (4.4) are performed on pointer operands (or on a pointer
    operand and a null pointer constant) to bring them to their composite pointer type. If one operand is a null
    pointer constant, the composite pointer type is the type of the other operand. Otherwise, if one of the
    operands has type "pointer to cv1 void", then the other has type "pointer to cv2 T" and the composite
    pointer type is "pointer to cv12 void", where cv12 is the union of cv1 and cv2. Otherwise, the composite
    pointer type is a pointer type similar (4.4) to the type of one of the operands, with a cv-qualification signa-
    ture (4.4) that is the union of the cv-qualification signatures of the operand types. [Note: this implies that
    any pointer can be compared to a null pointer constant and that any object pointer can be compared to a
    pointer to (possibly cv-qualified) void. ] [Example:
         void *p;
         const int *q;
         int **pi;
         const int *const *pci;
         void ct()
         {
             p <= q;                                  // Both converted to const void * before comparison
             pi <= pci;                               // Both converted to const int *const * before comparison
         }
     --end example] Pointers to objects or functions of the same type (after pointer conversions) can be com-
    pared, with a result defined as follows:
    -- If two pointers p and q of the same type point to the same object or function, or both point one past the
       end of the same array, or are both null, then p<=q and p>=q both yield true and p<q and p>q both
       yield false.
    -- If two pointers p and q of the same type point to different objects that are not members of the same
       object or elements of the same array or to different functions, or if only one of them is null, the results
       of p<q, p>q, p<=q, and p>=q are unspecified.
    -- If two pointers point to nonstatic data members of the same object, or to subobjects or array elements of
       such members, recursively, the pointer to the later declared member compares greater provided the two
       members are not separated by an access-specifier label (11.1) and provided their class is not a union.
    -- If two pointers point to nonstatic data members of the same object separated by an access-specifier label
       (11.1) the result is unspecified.
    -- If two pointers point to data members of the same union object, they compare equal (after conversion to
       void*, if necessary). If two pointers point to elements of the same array or one beyond the end of the
       array, the pointer to the object with the higher subscript compares higher.
    -- Other pointer comparisons are unspecified.

    5.10 Equality operators                                                                              [expr.eq]
         equality-expression:
                     relational-expression
                     equality-expression == relational-expression
                     equality-expression != relational-expression

1   The == (equal to) and the != (not equal to) operators have the same semantic restrictions, conversions, and
    result type as the relational operators except for their lower precedence and truth-value result. [Note: a<b
    == c<d is true whenever a<b and c<d have the same truth-value. ] Pointers to objects or functions of
    the same type (after pointer conversions) can be compared for equality. Two pointers of the same type
    compare equal if and only if they are both null, both point to the same object or function, or both point one
    past the end of the same array.




    86
    © ISO/IEC                                                                         ISO/IEC 14882:1998(E)

    5 Expressions                                                                        5.10 Equality operators



2   In addition, pointers to members can be compared, or a pointer to member and a null pointer constant.
    Pointer to member conversions (4.11) and qualification conversions (4.4) are performed to bring them to a
    common type. If one operand is a null pointer constant, the common type is the type of the other operand.
    Otherwise, the common type is a pointer to member type similar (4.4) to the type of one of the operands,
    with a cv-qualification signature (4.4) that is the union of the cv-qualification signatures of the operand
    types. [Note: this implies that any pointer to member can be compared to a null pointer constant. ] If both
    operands are null, they compare equal. Otherwise if only one is null, they compare unequal. Otherwise if
    either is a pointer to a virtual member function, the result is unspecified. Otherwise they compare equal if
    and only if they would refer to the same member of the same most derived object (1.8) or the same subob-
    ject if they were dereferenced with a hypothetical object of the associated class type. [Example:
         struct B {
                 int f();
         };
         struct L : B { };
         struct R : B { };
         struct D : L, R { };

         int (B::*pb)() = &B::f;
         int (L::*pl)() = pb;
         int (R::*pr)() = pb;
         int (D::*pdl)() = pl;
         int (D::*pdr)() = pr;
         bool x = (pdl == pdr);                       // false
    --end example]

    5.11 Bitwise AND operator                                                                    [expr.bit.and]
         and-expression:
                    equality-expression
                    and-expression & equality-expression

1   The usual arithmetic conversions are performed; the result is the bitwise AND function of the operands. The
    operator applies only to integral or enumeration operands.

    5.12 Bitwise exclusive OR operator                                                               [expr.xor]
         exclusive-or-expression:
                     and-expression
                     exclusive-or-expression ^ and-expression

1   The usual arithmetic conversions are performed; the result is the bitwise exclusive     OR   function of the
    operands. The operator applies only to integral or enumeration operands.

    5.13 Bitwise inclusive OR operator                                                                [expr.or]
         inclusive-or-expression:
                     exclusive-or-expression
                     inclusive-or-expression | exclusive-or-expression

1   The usual arithmetic conversions are performed; the result is the bitwise inclusive     OR   function of its
    operands. The operator applies only to integral or enumeration operands.

    5.14 Logical AND operator                                                                    [expr.log.and]
         logical-and-expression:
                     inclusive-or-expression
                     logical-and-expression && inclusive-or-expression




                                                                                                             87
    ISO/IEC 14882:1998(E)                                                                               © ISO/IEC

    5.14 Logical AND operator                                                                        5 Expressions



1   The && operator groups left-to-right. The operands are both implicitly converted to type bool (clause 4).
    The result is true if both operands are true and false otherwise. Unlike &, && guarantees left-to-right
    evaluation: the second operand is not evaluated if the first operand is false.
2   The result is a bool. All side effects of the first expression except for destruction of temporaries (12.2)
    happen before the second expression is evaluated.

    5.15 Logical OR operator                                                                          [expr.log.or]
          logical-or-expression:
                      logical-and-expression
                      logical-or-expression || logical-and-expression

1   The || operator groups left-to-right. The operands are both implicitly converted to bool (clause 4). It
    returns true if either of its operands is true, and false otherwise. Unlike |, || guarantees left-to-
    right evaluation; moreover, the second operand is not evaluated if the first operand evaluates to true.
2   The result is a bool. All side effects of the first expression except for destruction of temporaries (12.2)
    happen before the second expression is evaluated.

    5.16 Conditional operator                                                                          [expr.cond]
          conditional-expression:
                      logical-or-expression
                      logical-or-expression ? expression : assignment-expression

1   Conditional expressions group right-to-left. The first expression is implicitly converted to bool (clause 4).
    It is evaluated and if it is true, the result of the conditional expression is the value of the second expres-
    sion, otherwise that of the third expression. All side effects of the first expression except for destruction of
    temporaries (12.2) happen before the second or third expression is evaluated. Only one of the second and
    third expressions is evaluated.
2   If either the second or the third operand has type (possibly cv-qualified) void, then the lvalue-to-rvalue
    (4.1), array-to-pointer (4.2), and function-to-pointer (4.3) standard conversions are performed on the second
    and third operands, and one of the following shall hold:
    -- The second or the third operand (but not both) is a throw-expression (15.1); the result is of the type of
       the other and is an rvalue.
    -- Both the second and the third operands have type void; the result is of type void and is an rvalue.
       [Note: this includes the case where both operands are throw-expressions. ]
3   Otherwise, if the second and third operand have different types, and either has (possibly cv-qualified) class
    type, an attempt is made to convert each of those operands to the type of the other. The process for deter-
    mining whether an operand expression E1 of type T1 can be converted to match an operand expression E2
    of type T2 is defined as follows:
    -- If E2 is an lvalue: E1 can be converted to match E2 if E1 can be implicitly converted (clause 4) to the
       type "reference to T2", subject to the constraint that in the conversion the reference must bind directly
       (8.5.3) to E1.
    -- If E2 is an rvalue, or if the conversion above cannot be done:
         -- if E1 and E2 have class type, and the underlying class types are the same or one is a base class of
            the other: E1 can be converted to match E2 if the class of T2 is the same type as, or a base class of,
            the class of T1, and the cv-qualification of T2 is the same cv-qualification as, or a greater cv-
            qualification than, the cv-qualification of T1. If the conversion is applied, E1 is changed to an
            rvalue of type T2 that still refers to the original source class object (or the appropriate subobject
            thereof). [Note: that is, no copy is made. ]
         -- Otherwise (i.e., if E1 or E2 has a nonclass type, or if they both have class types but the underlying


    88
    © ISO/IEC                                                                                  ISO/IEC 14882:1998(E)


    5 Expressions                                                                         5.16 Conditional operator



           classes are not either the same or one a base class of the other): E1 can be converted to match E2 if
           E1 can be implicitly converted to the type that expression E2 would have if E2 were converted to an
           rvalue (or the type it has, if E2 is an rvalue).

    Using this process, it is determined whether the second operand can be converted to match the third
    operand, and whether the third operand can be converted to match the second operand. If both can be con-
    verted, or one can be converted but the conversion is ambiguous, the program is ill-formed. If neither can
    be converted, the operands are left unchanged and further checking is performed as described below. If
    exactly one conversion is possible, that conversion is applied to the chosen operand and the converted
    operand is used in place of the original operand for the remainder of this section.
4   If the second and third operands are lvalues and have the same type, the result is of that type and is an
    lvalue.
5   Otherwise, the result is an rvalue. If the second and third operand do not have the same type, and either has
    (possibly cv-qualified) class type, overload resolution is used to determine the conversions (if any) to be
    applied to the operands (13.3.1.2, 13.6). If the overload resolution fails, the program is ill-formed. Other-
    wise, the conversions thus determined are applied, and the converted operands are used in place of the orig-
    inal operands for the remainder of this section.
6   Lvalue-to-rvalue (4.1), array-to-pointer (4.2), and function-to-pointer (4.3) standard conversions are per-
    formed on the second and third operands. After those conversions, one of the following shall hold:
    -- The second and third operands have the same type; the result is of that type.
    -- The second and third operands have arithmetic or enumeration type; the usual arithmetic conversions
       are performed to bring them to a common type, and the result is of that type.
    -- The second and third operands have pointer type, or one has pointer type and the other is a null pointer
       constant; pointer conversions (4.10) and qualification conversions (4.4) are performed to bring them to
       their composite pointer type (5.9). The result is of the composite pointer type.
    -- The second and third operands have pointer to member type, or one has pointer to member type and the
       other is a null pointer constant; pointer to member conversions (4.11) and qualification conversions
       (4.4) are performed to bring them to a common type, whose cv-qualification shall match the cv-
       qualification of either the second or the third operand. The result is of the common type.

    5.17 Assignment operators                                                                             [expr.ass]
1   There are several assignment operators, all of which group right-to-left. All require a modifiable lvalue as
    their left operand, and the type of an assignment expression is that of its left operand. The result of the
    assignment operation is the value stored in the left operand after the assignment has taken place; the result
    is an lvalue.
         assignment-expression:
                    conditional-expression
                    logical-or-expression assignment-operator assignment-expression
                    throw-expression

         assignment-operator: one of
                    = *= /= %=             +=    -=   >>=    <<=    &=    ^=    |=

2   In simple assignment (=), the value of the expression replaces that of the object referred to by the left
    operand.
3   If the left operand is not of class type, the expression is implicitly converted (clause 4) to the cv-unqualified
    type of the left operand.
4   If the left operand is of class type, the class shall be complete. Assignment to objects of a class is defined
    by the copy assignment operator (12.8, 13.5.3).



                                                                                                                  89
    ISO/IEC 14882:1998(E)                                                                                  © ISO/IEC


    5.17 Assignment operators                                                                         5 Expressions



5   [Note: For class objects, assignment is not in general the same as initialization (8.5, 12.1, 12.6, 12.8). ]
6   When the left operand of an assignment operator denotes a reference to T, the operation assigns to the
    object of type T denoted by the reference.
7   The behavior of an expression of the form E1 op= E2 is equivalent to E1 = E1 op E2 except that E1 is
    evaluated only once. In += and -=, E1 shall either have arithmetic type or be a pointer to a possibly cv-
    qualified completely defined object type. In all other cases, E1 shall have arithmetic type.
8   If the value being stored in an object is accessed from another object that overlaps in any way the storage of
    the first object, then the overlap shall be exact and the two objects shall have the same type, otherwise the
    behavior is undefined.

    5.18 Comma operator                                                                              [expr.comma]
1   The comma operator groups left-to-right.
         expression:
                       assignment-expression
                       expression , assignment-expression
    A pair of expressions separated by a comma is evaluated left-to-right and the value of the left expression is
    discarded. The lvalue-to-rvalue (4.1), array-to-pointer (4.2), and function-to-pointer (4.3) standard conver-
    sions are not applied to the left expression. All side effects (1.9) of the left expression, except for the
    destruction of temporaries (12.2), are performed before the evaluation of the right expression. The type and
    value of the result are the type and value of the right operand; the result is an lvalue if its right operand is.
2   In contexts where comma is given a special meaning, [Example: in lists of arguments to functions (5.2.2)
    and lists of initializers (8.5) ] the comma operator as described in clause 5 can appear only in parentheses.
    [Example:
         f(a, (t=3, t+2), c);

    has three arguments, the second of which has the value 5. ]

    5.19 Constant expressions                                                                          [expr.const]
1   In several places, C++ requires expressions that evaluate to an integral or enumeration constant: as array
    bounds (8.3.4, 5.3.4), as case expressions (6.4.2), as bit-field lengths (9.6), as enumerator initializers (7.2),
    as static member initializers (9.4.2), and as integral or enumeration non-type template arguments (14.3).
         constant-expression:
                    conditional-expression
    An integral constant-expression can involve only literals (2.13), enumerators, const variables or static
    data members of integral or enumeration types initialized with constant expressions (8.5), non-type tem-
    plate parameters of integral or enumeration types, and sizeof expressions. Floating literals (2.13.3) can
    appear only if they are cast to integral or enumeration types. Only type conversions to integral or enumera-
    tion types can be used. In particular, except in sizeof expressions, functions, class objects, pointers, or
    references shall not be used, and assignment, increment, decrement, function-call, or comma operators shall
    not be used.
2   Other expressions are considered constant-expressions only for the purpose of non-local static object
    initialization (3.6.2). Such constant expressions shall evaluate to one of the following:
    -- a null pointer value (4.10),
    -- a null member pointer value (4.11),
    -- an arithmetic constant expression,
    -- an address constant expression,
    -- a reference constant expression,


    90
    © ISO/IEC                                                                                 ISO/IEC 14882:1998(E)


    5 Expressions                                                                        5.19 Constant expressions



    -- an address constant expression for a complete object type, plus or minus an integral constant expression,
       or
    -- a pointer to member constant expression.
3   An arithmetic constant expression shall have arithmetic or enumeration type and shall only have operands
    that are integer literals (2.13.1), floating literals (2.13.3), enumerators, character literals (2.13.2) and
    sizeof expressions (5.3.3). Cast operators in an arithmetic constant expression shall only convert arith-
    metic or enumeration types to arithmetic or enumeration types, except as part of an operand to the sizeof
    operator.
4   An address constant expression is a pointer to an lvalue designating an object of static storage duration, a
    string literal (2.13.4), or a function. The pointer shall be created explicitly, using the unary & operator, or
    implicitly using a non-type template parameter of pointer type, or using an expression of array (4.2) or
    function (4.3) type. The subscripting operator [] and the class member access . and -> operators, the &
    and * unary operators, and pointer casts (except dynamic_casts, 5.2.7) can be used in the creation of an
    address constant expression, but the value of an object shall not be accessed by the use of these operators.
    If the subscripting operator is used, one of its operands shall be an integral constant expression. An expres-
    sion that designates the address of a member or base class of a non-POD class object (clause 9) is not an
    address constant expression (12.7). Function calls shall not be used in an address constant expression, even
    if the function is inline and has a reference return type.
5   A reference constant expression is an lvalue designating an object of static storage duration, a non-type
    template parameter of reference type, or a function. The subscripting operator [], the class member access
    . and -> operators, the & and * unary operators, and reference casts (except those invoking user-defined
    conversion functions (12.3.2) and except dynamic_casts (5.2.7)) can be used in the creation of a refer-
    ence constant expression, but the value of an object shall not be accessed by the use of these operators. If
    the subscripting operator is used, one of its operands shall be an integral constant expression. An lvalue
    expression that designates a member or base class of a non-POD class object (clause 9) is not a reference
    constant expression (12.7). Function calls shall not be used in a reference constant expression, even if the
    function is inline and has a reference return type.
6   A pointer to member constant expression shall be created using the unary & operator applied to a qualified-
    id operand (5.3.1), optionally preceded by a pointer to member cast (5.2.9).




                                                                                                                91
ISO/IEC 14882:1998(E)                  ©   ISO/IEC




                        (Blank page)




92
    © ISO/IEC                                                                                 ISO/IEC 14882:1998(E)


    6 Statements                                                                                       6 Statements




    6 Statements                                                                                [stmt.stmt]
1   Except as indicated, statements are executed in sequence.
         statement:
                      labeled-statement
                      expression-statement
                      compound-statement
                      selection-statement
                      iteration-statement
                      jump-statement
                      declaration-statement
                      try-block


    6.1 Labeled statement                                                                              [stmt.label]
1   A statement can be labeled.
         labeled-statement:
                     identifier : statement
                     case constant-expression : statement
                     default : statement
    An identifier label declares the identifier. The only use of an identifier label is as the target of a goto. The
    scope of a label is the function in which it appears. Labels shall not be redeclared within a function. A
    label can be used in a goto statement before its definition. Labels have their own name space and do not
    interfere with other identifiers.
2   Case labels and default labels shall occur only in switch statements.

    6.2 Expression statement                                                                           [stmt.expr]
1   Expression statements have the form
         expression-statement:
                    expressionopt ;
    The expression is evaluated and its value is discarded. The lvalue-to-rvalue (4.1), array-to-pointer (4.2),
    and function-to-pointer (4.3) standard conversions are not applied to the expression. All side effects from
    an expression statement are completed before the next statement is executed. An expression statement with
    the expression missing is called a null statement. [Note: Most statements are expression statements--
    usually assignments or function calls. A null statement is useful to carry a label just before the } of a com-
    pound statement and to supply a null body to an iteration statement such as a while statement (6.5.1). ]

    6.3 Compound statement or block                                                                   [stmt.block]
1   So that several statements can be used where one is expected, the compound statement (also, and equiva-
    lently, called "block") is provided.
         compound-statement:
                    { statement-seqopt }

         statement-seq:
                     statement
                     statement-seq statement
    A compound statement defines a local scope (3.3). [Note: a declaration is a statement (6.7). ]




                                                                                                                 93
    ISO/IEC 14882:1998(E)                                                                               © ISO/IEC


    6.4 Selection statements                                                                        6 Statements



    6.4 Selection statements                                                                        [stmt.select]
1   Selection statements choose one of several flows of control.
         selection-statement:
                     if ( condition ) statement
                     if ( condition ) statement else statement
                     switch ( condition ) statement

         condition:
                      expression
                      type-specifier-seq declarator = assignment-expression
    In clause 6, the term substatement refers to the contained statement or statements that appear in the syntax
    notation. The substatement in a selection-statement (both substatements, in the else form of the if state-
    ment) implicitly defines a local scope (3.3). If the substatement in a selection-statement is a single state-
    ment and not a compound-statement, it is as if it was rewritten to be a compound-statement containing the
    original substatement. [Example:
         if (x)
             int i;
    can be equivalently rewritten as
         if (x) {
             int i;
         }
    Thus after the if statement, i is no longer in scope. ]
2   The rules for conditions apply both to selection-statements and to the for and while statements (6.5).
    The declarator shall not specify a function or an array. The type-specifier-seq shall not contain typedef
    and shall not declare a new class or enumeration.
3   A name introduced by a declaration in a condition (either introduced by the type-specifier-seq or the
    declarator of the condition) is in scope from its point of declaration until the end of the substatements con-
    trolled by the condition. If the name is re-declared in the outermost block of a substatement controlled by
    the condition, the declaration that re-declares the name is ill-formed. [Example:
         if (int x = f()) {
                 int x;                                // ill-formed, redeclaration of x
         }
         else {
                 int x;                                // ill-formed, redeclaration of x
         }
    --end example]
4   The value of a condition that is an initialized declaration in a statement other than a switch statement is
    the value of the declared variable implicitly converted to type bool. If that conversion is ill-formed, the
    program is ill-formed. The value of a condition that is an initialized declaration in a switch statement is
    the value of the declared variable if it has integral or enumeration type, or of that variable implicitly con-
    verted to integral or enumeration type otherwise. The value of a condition that is an expression is the value
    of the expression, implicitly converted to bool for statements other than switch; if that conversion is
    ill-formed, the program is ill-formed. The value of the condition will be referred to as simply "the condi-
    tion" where the usage is unambiguous.
5   If a condition can be syntactically resolved as either an expression or the declaration of a local name, it is
    interpreted as a declaration.




    94
    © ISO/IEC                                                                                 ISO/IEC 14882:1998(E)


    6 Statements                                                                             6.4.1 The if statement



    6.4.1 The if statement                                                                                 [stmt.if]
1   If the condition (6.4) yields true the first substatement is executed. If the else part of the selection
    statement is present and the condition yields false, the second substatement is executed. In the second
    form of if statement (the one including else), if the first substatement is also an if statement then that
    inner if statement shall contain an else part.76)

    6.4.2 The switch statement                                                                       [stmt.switch]
1   The switch statement causes control to be transferred to one of several statements depending on the value
    of a condition.
2   The condition shall be of integral type, enumeration type, or of a class type for which a single conversion
    function to integral or enumeration type exists (12.3). If the condition is of class type, the condition is con-
    verted by calling that conversion function, and the result of the conversion is used in place of the original
    condition for the remainder of this section. Integral promotions are performed. Any statement within the
    switch statement can be labeled with one or more case labels as follows:
                        case constant-expression :

    where the constant-expression shall be an integral constant-expression. The integral constant-expression
    (5.19) is implicitly converted to the promoted type of the switch condition. No two of the case constants in
    the same switch shall have the same value after conversion to the promoted type of the switch condition.
3   There shall be at most one label of the form
          default :

    within a switch statement.
4   Switch statements can be nested; a case or default label is associated with the smallest switch enclos-
    ing it.
5   When the switch statement is executed, its condition is evaluated and compared with each case constant.
    If one of the case constants is equal to the value of the condition, control is passed to the statement follow-
    ing the matched case label. If no case constant matches the condition, and if there is a default label,
    control passes to the statement labeled by the default label. If no case matches and if there is no default
    then none of the statements in the switch is executed.
6   case and default labels in themselves do not alter the flow of control, which continues unimpeded
    across such labels. To exit from a switch, see break, 6.6.1. [Note: usually, the substatement that is the
    subject of a switch is compound and case and default labels appear on the top-level statements con-
    tained within the (compound) substatement, but this is not required. Declarations can appear in the sub-
    statement of a switch-statement. ]

    6.5 Iteration statements                                                                            [stmt.iter]
1   Iteration statements specify looping.
          iteration-statement:
                       while ( condition ) statement
                       do statement while ( expression ) ;
                       for ( for-init-statement conditionopt ; expressionopt ) statement

          for-init-statement:
                       expression-statement
                       simple-declaration
    [Note: a for-init-statement ends with a semicolon. ]
    __________________
    76) In other words, the else is associated with the nearest un-elsed if.




                                                                                                                 95
    ISO/IEC 14882:1998(E)                                                                                 © ISO/IEC


    6.5 Iteration statements                                                                          6 Statements



2   The substatement in an iteration-statement implicitly defines a local scope (3.3) which is entered and exited
    each time through the loop.
3   If the substatement in an iteration-statement is a single statement and not a compound-statement, it is as if it
    was rewritten to be a compound-statement containing the original statement. [Example:
         while (--x >= 0)
             int i;
    can be equivalently rewritten as
         while (--x >= 0) {
             int i;
         }
    Thus after the while statement, i is no longer in scope. ]
4   [Note: The requirements on conditions in iteration statements are described in 6.4. --end note]

    6.5.1 The while statement                                                                         [stmt.while]
1   In the while statement th