______________________________________________________________________ 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 require- ment appear at various places within the Standard. 2 C++ is a general purpose programming language based on the C program- ming language as described in ISO/IEC 9899:1990 Programming Languages C (_intro.refs_). In addition to the facilities provided by C, C++ provides additional data types, classes, templates, exceptions, names- paces, inline functions, operator overloading, function name overload- ing, references, free store management operators, and additional library facilities. The differences between C++ and ISO C are summa- rized in _diff.iso_. 3 Clauses _lib.library_ through _lib.input.output_ (the library clauses) describe the Standard C++ library, which provides definitions for the following kinds of entities: macros (_cpp.replace_), values (clause _basic_), types (_dcl.name_, _dcl.meaning_), templates (clause _temp_), classes (clause _class_), functions (_dcl.fct_), and objects (clause _dcl.dcl_). 4 For classes and class templates, the library clauses specify partial definitions. Private members (clause _class.access_) are not speci- fied, but each implementation shall supply them to complete the defi- nitions according to the description in the library clauses. 5 For functions, function templates, objects, and values, the library clauses specify declarations. Implementations shall supply defini- tions consistent with the descriptions in the library clauses. 6 The names defined in the library have namespace scope (_basic.names- pace_). A C++ translation unit (_lex.phases_) obtains access to these names by including the appropriate standard library header (_cpp.include_). 7 The templates, classes, functions, and objects in the library have external linkage (_basic.link_). The implementation provides defini- tions for standard library entities, as necessary, while combining translation units to form a complete C++ program (_lex.phases_). 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 stan- dards are subject to revision, and parties to agreements based on this International Standard are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. Members of IEC and ISO maintain registers of currently valid Interna- tional Standards. --ISO/IEC 2382 Dictionary for Information Processing Systems. --ISO/IEC 9899:1990 Programming Languages - C --ISO/IEC:1990 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 the C Standard and clause 7 of Amendment 1 to the C Standard is hereinafter called the Standard C Library.1) 1.3 Implementation compliance [intro.compliance] 1 The set of "diagnosable rules" consists of all syntactic and semantic rules in this International Standard except for those rules containing an explicit notation that "no diagnostic is required" or which are described as resulting in "undefined behavior." 2 Although this International Standard states only requirements on C++ implementations, those requirements are often easier to understand if they are phrased as requirements on programs, parts of programs, or execution of programs. Such requirements have the following meaning: --If a program contains no violations of the rules in this Interna- tional Standard, a conforming implementation shall, within its resource limits, accept and correctly execute2) that program. --If a program contains a violation of any diagnosable rule, a con- forming 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 Standard places no requirement on _________________________ 1) With the qualifications noted in clauses _lib.library_ through _lib.input.output_, and in _diff.library_, the Standard C library is a subset of the Standard C++ library. 2) "Correct execution" can include undefined behavior, depending on the data being processed; see _intro.defs_ and _intro.execution_. implementations with respect to that program. 3 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 (_lib.compliance_). 4 In this International Standard, a term is italicized when it is first defined. In this International Standard, the examples, the notes, the footnotes, and the non-normative annexes are not part of the normative 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. 5 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 pro- grams that use such extensions that are ill-formed according to this Standard. Having done so, however, they can compile and execute such programs. 1.4 Definitions [intro.defs] 1 For the purposes of this International Standard, the definitions given in ISO/IEC 2382 and the following definitions apply. 1.4.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 brack- ets in a template instantiation. Also known as an "actual argument" or "actual parameter." 1.4.2 diagnostic message [defns.diagnostic] a message belonging to an implementation-defined subset of the imple- mentation's output messages. 1.4.3 dynamic type [defns.dynamic.type] the dynamic type of an lvalue expression is the type of the most derived object (_intro.object_) to which the lvalue refers. [Example: if a pointer (_dcl.ptr_) p whose static type is "pointer to class B" is pointing to an object of class D, derived from B (clause _class.derived_), the dynamic type of the expression *p is D." Refer- ences (_dcl.ref_) are treated similarly. ] The dynamic type of an rvalue expression is its static type. 1.4.4 ill-formed program [defns.ill.formed] input to a C++ implementation that is not a well-formed program (q. v.). 1.4.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 docu- ment. 1.4.6 implementation limits [defns.impl.limits] restrictions imposed upon programs by the implementation. 1.4.7 locale-specific behavior [defns.locale.specific] behavior that depends on local conventions of nationality, culture, and language that each implementation shall document. 1.4.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 (_lex.charset_). 1.4.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.4.10 signature [defns.signature] the information about a function that participates in overload resolu- tion (_over.match_): 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 the member function is declared.3) The signa- ture of a template function specialization includes the types of its template arguments (_temp.over.link_). 1.4.11 static type [defns.static.type] of an expression, the type (_basic.types_) resulting from analysis of the program without consideration of execution semantics. It depends only on the form of the program and does not change while the program is executing. 1.4.12 undefined behavior [defns.undefined] behavior, such as might arise upon use of an erroneous program con- struct or of erroneous data, for which the Standard imposes no requirements. Undefined behavior may also be expected when the stan- dard omits the description of any explicit definition of behavior. _________________________ 3) Function signatures do not include return type, because that does not participate in overload resolution. [Note: permissible undefined behavior ranges from ignoring the situa- tion completely with unpredictable results, to behaving during trans- lation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic mes- sage), to terminating a translation or execution (with the issuance of a diagnostic message). Note that many erroneous program constructs do not engender undefined behavior; they are required to be diagnosed. ] 1.4.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 the Standard. ] 1.4.14 well-formed program [defns.well.formed] a C++ program constructed according to the syntax rules, diagnosable semantic rules, and the One Definition Rule (_basic.def.odr_). 1 _lib.definitions_ defines additional terms that are used only in the library clauses (_lib.library_-_lib.input.output_). 1.5 Syntax notation [syntax] 1 In the syntax notation used in this International Standard, syntactic categories are indicated by italic type, and literal words and charac- ters in constant width type. Alternatives are listed on separate lines except in a few cases where a long set of alternatives is pre- sented on one line, marked by the phrase "one of." An optional termi- nal 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. qual- ified-id). --X-seq is one or more X's without intervening delimiters (e.g. dec- laration-seq is a sequence of declarations). --X-list is one or more X's separated by intervening commas (e.g. expression-list is a sequence of expressions separated by commas). 1.6 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 contain any member of the basic exe- cution 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 _basic.types_. ] 1.7 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 func- tion is not an object, regardless of whether or not it occupies stor- age in the way that objects do. ] An object is created by a defini- tion (_basic.def_), by a new-expression (_expr.new_) or by the imple- mentation (_class.temporary_) when needed. The properties of an object are determined when the object is created. An object can have a name (clause _basic_). An object has a storage duration (_basic.stc_) which influences its lifetime (_basic.life_). An object has a type (_basic.types_). The term object type refers to the type with which the object is created. Some objects are polymorphic (_class.virtual_); the implementation generates information associated with each such object that makes it possible to determine that object's type during program execution. For other objects, the inter- pretation of the values found therein is determined by the type of the expressions (clause _expr_) used to access them. 2 Objects can contain other objects, called sub-objects. A sub-object can be a member sub-object (_class.mem_), a base class sub-object (clause _class.derived_), 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 (_class.mem_), 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 (_class.bit_), 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 (_basic.types_) 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 (_basic.types_). ] _________________________ 4) The acronym POD stands for "plain old data." 1.8 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 imple- mentations. In particular, they need not copy or emulate the struc- ture of the abstract machine. Rather, conforming implementations are required to emulate (only) the observable behavior of the abstract machine as explained below.5) 2 Certain aspects and operations of the abstract machine are described in this 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 documenta- tion shall define the instance of the abstract machine that corre- sponds 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, the Standard defines a set of allowable behaviors. These define the non- deterministic 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 pro- duce the same observable behavior 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 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) _________________________ 5) This provision is sometimes called the "as-if" rule, because an im- plementation is free to disregard any requirement of the 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 ex- pression if it can deduce that its value is not used and that no side effects affecting the observable behavior of the program are produced. 6) An implementation can offer additional library I/O functions as an extension. Implementations that do so should treat calls to those 7 Accessing an object designated by a volatile lvalue (_basic.lval_), 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 subse- quent evaluations shall have taken place.7) 8 Once the execution of a function begins, no expressions from the call- ing function are evaluated until execution 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 unde- fined. 10An instance of each object with automatic storage duration (_basic.stc.auto_) is associated with each entry into its block. Such an object exists and retains its last-stored value during the execu- tion of the block and while the block is suspended (by a call of a function or receipt of a signal). 11The 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 identi- cal 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 interac- tive device is implementation-defined. [Note: more stringent correspondences between abstract and actual semantics may be defined by each implementation. ] _________________________ 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 gener- ated. Also note that when a call to a library I/O function returns, the side effect is considered complete, even though some external ac- tions 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. 12A 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 con- sidered to be an expression for the purposes of this definition. 13[Note: certain contexts in C++ cause the evaluation of a full-expres- sion that results from a syntactic construct other than expression (_expr.comma_). For example, in _dcl.init_ 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 _dcl.init_, another syntax for initializer is = initializer-clause but again the resulting construct might be a function call upon a con- structor function with one assignment-expression as an argument; again, the function call is a full-expression. ] 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 expressions (_dcl.fct.default_) 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 implementa- tion 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 _________________________ 9) Overloaded operators are never assumed to be associative or commu- tative. above expression statement can be rewritten by the implementation in any of the above ways because the same result will occur. ] 16There is a sequence point at the completion of evaluation of each full-expression10). 17When 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 state- ments in the function body. There is also a sequence point after the copying of a returned value and before the execution of any expres- sions outside the function11). Several contexts in C++ cause evalua- tion of a function call, even though no corresponding function call syntax appears in the translation unit. [Example: evaluation of a new expression invokes one or more allocation and constructor functions; see _expr.new_. For another example, invocation of a conversion func- tion (_class.conv.fct_) 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. 18In 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 (_expr.log.and_, _expr.log.or_, _expr.cond_, _expr.comma_) there is a sequence point after the evaluation of the first expression12). 1.9 Acknowledgments [intro.ack] 1 The C++ programming language as described in this International Stan- dard is based on the language as described in Chapter R (Reference Manual) of Stroustrup: The C++ Programming Language (second edition, Addison-Wesley Publishing Company, ISBN 0-201-53992-6, copyright (C) _________________________ 10) As specified in _class.temporary_, after the "end-of-full-expres- sion" sequence point, a sequence of zero or more invocations of de- structor functions for temporary objects takes place, usually in re- verse order of the construction of each temporary object. 11) The sequence point at the function return is not explicitly speci- fied 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 terminate its exe- cution, such as the throw of an exception. 12) The operators indicated in this paragraph are the built-in opera- tors, as described in clause _expr_. When one of these operators is overloaded (clause _over_) in a valid context, thus designating a us- er-defined operator function, the expression designates a function in- vocation, and the operands form an argument list, without an implied sequence point between them. 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 (C) 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 Stan- dard C++ Library (Prentice-Hall, ISBN 0-13-117003-1, copyright (C) 1995 P.J. Plauger). 3 All rights in these originals are reserved. ______________________________________________________________________ 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 (_lib.headers_) and source files included (_cpp.include_) via the pre- processing directive #include, less any source lines skipped by any of the conditional inclusion (_cpp.cond_) preprocessing directives, 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 transla- tion units of a program communicate (_basic.link_) by (for example) calls to functions whose identifiers have external linkage, manipula- tion of objects whose identifiers have external linkage, or manipula- tion of data files. Translation units can be separately translated and then later linked to produce an executable program. (_basic.link_). ] 2.1 Phases of translation [lex.phases] 1 The precedence among the syntax rules of translation is specified by the following phases.13) 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 (_lex.trigraph_) are replaced by corresponding single-character internal representations. Any source file char- acter not in the basic source character set (_lex.charset_) is replaced by the universal-character-name that designates that character. (An implementation may use any internal encoding, so long as an actual extended character encountered in the source 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, _________________________ 13) Implementations must behave as if these separate phases occur, al- though in practice different phases might be folded together. 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 char- acter immediately preceded by a backslash character, the behavior is undefined. 3 The source file is decomposed into preprocessing tokens (_lex.pptoken_) and sequences of white-space characters (including comments). A source file shall not end in a partial preprocessing token or partial comment14). 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 preprocessing tokens is context-dependent. [Example: see the han- dling of < within a #include preprocessing 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 (_cpp.concat_), the behavior is undefined. A #include preprocess- ing directive causes the named header or source file to be pro- cessed 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 con- verted to a member of the execution character set (_lex.ccon_, _lex.string_). 6 Adjacent ordinary string literal tokens are concatenated. Adja- cent wide string literal tokens are concatenated. 7 White-space characters separating tokens are no longer signifi- cant. Each preprocessing token is converted into a token. (_lex.token_). The resulting tokens are syntactically and seman- tically 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 particu- lar 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 pro- duce a list of required instantiations. [Note: this may include instantiations which have been explicitly requested (_temp.explicit_). ] The definitions of the required templates _________________________ 14) A partial preprocessing token would arise from a source file end- ing in the first portion of a multi-character token that requires a terminating sequence of characters, such as a header-name that is missing the closing " or >. A partial comment would arise from a source file ending with an unclosed /* comment. 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 instantia- tions are performed to produce instantiation units. [Note: these are similar to translated translation units, but contain no refer- ences 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 external 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 representing horizontal tab, verti- cal 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 universal character name designates a character in the basic source character set, then the program is ill-formed. _________________________ 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 imple- mentation is required to document how the basic source characters are represented in source files. 3 The basic execution character set and the basic execution wide-charac- ter set shall each contain all the members of the basic source charac- ter set, plus control characters representing alert, backspace, and carriage return, plus a null character (respectively, null wide char- acter), whose representation has all zero bits. For each basic execu- tion 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, respec- tively. The values of the members of the execution character sets are implementation-defined, and any additional members are locale-spe- cific. 2.3 Trigraph sequences [lex.trigraph] 1 Before any other processing takes place, each occurrence of one of the following sequences of three characters ("trigraph sequences") is replaced by the single character indicated in Table 1. Table 1--trigraph sequences +-----------------------+------------------------+------------------------+ |trigraph replacement | trigraph replacement | trigraph replacement | +-----------------------+------------------------+------------------------+ | ??= # | ??( [ | ??< { | +-----------------------+------------------------+------------------------+ | ??/ \ | ??) ] | ??> } | +-----------------------+------------------------+------------------------+ | ??' ^ | ??! | | ??- ~ | +-----------------------+------------------------+------------------------+ 2 [Example: ??=define arraycheck(a,b) a??(b??) ??!??! b??(a??) becomes #define arraycheck(a,b) a[b] || b[a] --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 (_lex.token_) 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 lexically match the other prepro- cessing token categories. If a ' or a " character matches the last category, the behavior is undefined. Preprocessing tokens can be sep- arated by white space; this consists of comments (_lex.comment_), or white-space characters (space, horizontal tab, new-line, vertical tab, and form-feed), or both. As described in clause _cpp_, in certain circumstances during translation phase 4, white space (or the absence thereof) serves as more than preprocessing token separation. White space can appear within a preprocessing token only as part of a header name or between the quotation characters in a character literal or string literal. 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 fragment 1E1 is parsed as a preprocessing number (one that is a valid floating literal token), whether or not E is a macro name. ] 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] 1 Alternative token representations are provided for some operators and punctuators16). 2 In all respects of the language, each alternative token behaves the same, respectively, as its primary token, except for its spelling17). _________________________ 16) These include "digraphs" and additional reserved words. The term "digraph" (token consisting of two characters) is not perfectly de- scriptive, since one of the alternative preprocessing-tokens is %:%: and of course several primary tokens contain two characters. Nonethe- less, those alternative tokens that aren't lexical keywords are collo- quially known as "digraphs". 17) Thus the "stringized" values (_cpp.stringize_) of [ and <: will be different, maintaining the source spelling, but the tokens can other- 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 |= | +----------------------+-----------------------+-----------------------+ | <: [ | or || | xor_eq ^= | +----------------------+-----------------------+-----------------------+ | :> ] | 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 charac- ters */. These comments do not nest. The characters // start a com- ment, 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 termi- nates the comment; no diagnostic is required. [Note: The comment characters //, /*, and */ have no special meaning within a // comment and are treated just like other characters. Similarly, the comment characters // and /* have no special meaning within a /* comment. ] _________________________ wise be freely interchanged. 18) Literals include strings and character and numeric literals. 2.8 Header names [lex.header] header-name: "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 (_cpp.include_). The sequences in both forms of header-names are mapped in an implementation-defined manner to headers or to external source file names as specified in _cpp.include_. 2 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 undefined.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 (_lex.icon_) and all floating literal tokens (_lex.fcon_). 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, _lex.phases_) to an integral literal token or a floating literal token. _________________________ 19) Thus, sequences of characters that resemble escape sequences cause undefined behavior. 2.10 Identifiers [lex.name] identifier: nondigit identifier nondigit identifier digit 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 identifier shall designate a char- acter whose encoding in ISO 10646 falls into one of the ranges speci- fied in Annex _extendid_. Upper- and lower-case letters are differ- ent. All characters are significant.20) 2 In addition, some identifiers are reserved for use by C++ implementa- tions and standard libraries (_lib.global.names_) 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): _________________________ 20) On systems in which linkers cannot accept extended characters, an encoding of the universal-character-name may be used in forming valid external identifiers. For example, some otherwise unused character or sequence of characters may be used to encode the \u in a universal- character-name. Extended characters may produce a long external iden- tifier, 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 exter- nal identifiers. 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 cer- tain operators and punctuators (_lex.digraph_) 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 | +------------------------------------------------+ 2.12 Operators and punctuators [lex.operators] 1 The lexical representation of C++ programs includes a number of pre- processing 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 trans- lation phase 7 (_lex.phases_). 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 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 expo- nent 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 consists of a sequence of decimal digits. An octal integer literal (base eight) begins with the digit 0 and consists of a sequence of octal digits.22) A hexadecimal integer literal (base sixteen) begins with 0x or 0X and _________________________ 21) The term "literal" generally designates, in this International Standard, those tokens that are called "constants" in ISO C. 22) The digits 8 and 9 are not octal digits. consists of a sequence of hexadecimal digits, which include the deci- mal digits and the letters a through f and A through F with decimal values ten through fifteen. [Example: the number twelve can be writ- ten 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 represented 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 represented: 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 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 con- tains more than one c-char is a multicharacter literal. A multichar- acter 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 lit- eral containing multiple c-chars is implementation-defined. 3 Certain nongraphic characters, the single quote ', the double quote ", the question mark ?, and the backslash \, 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 back- slash is not one of those specified, the behavior is undefined. An escape sequence specifies a single character. 4 The escape \ooo consists of the backslash followed by one, two, or three octal digits that are taken to specify the value of the desired character. The escape \xhhh consists of the backslash followed by x followed by one or more hexadecimal digits that are taken to specify the value of the desired character. There is no limit to the number of digits in a hexadecimal sequence. A sequence of octal or hexadeci- mal digits is terminated by the first character that is not an octal _________________________ 23) They are intended for character sets where a character does not fit into a single byte. digit or a hexadecimal digit, respectively. The value of a character literal is implementation-defined if it falls outside of the implemen- tation-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 exe- cution character set, of the character named. If there is no such encoding, the universal-character-name is translated to an implementa- tion-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 omit- ted. 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 signifi- cant part is to be scaled. If the scaled value is in the range of representable values for its type, the result is the scaled value if representable, else the larger or smaller representable value nearest the scaled value, chosen in an implementation-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 rep- resentable values for its type, the program is ill-formed. 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 _lex.ccon_) 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 ordinary 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 (_basic.stc_), 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 charac- ters. 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 (_lex.phases_), 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 (_lex.phases_), '\0' is appended to every string literal so that pro- grams 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 literals (_lex.ccon_), 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 lvalues. ______________________________________________________________________ 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 termi- nating 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 discussed 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 (_lex.name_) that denotes an entity or label (_stmt.goto_, _stmt.label_). 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 introduced either by a goto state- ment (_stmt.goto_) or a labeled-statement (_stmt.label_). 6 Some names denote types, classes, enumerations, or templates. In gen- eral, 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 (_basic.lookup_). 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 translation units depending on the linkage (_basic.link_) of the identifier specified in each translation unit. 3.1 Declarations and definitions [basic.def] 1 A declaration (clause _dcl.dcl_) introduces names into a translation unit or redeclares names introduced by previous declarations. A dec- laration 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 (_dcl.fct.def_), it contains the extern specifier (_dcl.stc_) or a linkage-specification24) (_dcl.link_) and neither an initializer nor a function-body, it declares a static data member in a class declaration (_class.static_), it is a class name declaration (_class.name_), or it is a typedef declaration (_dcl.type- def_), a using-declaration (_namespace.udecl_), or a using-directive (_namespace.udir_). 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 (_class.ctor_), copy constructor (_class.copy_), assignment operator (_class.copy_), or destructor (_class.dtor_) member functions. [Example: given _________________________ 24) Appearing inside the braced-enclosed declaration-seq in a linkage- specification does not affect whether a declaration is a definition. struct C { string s; // string is the standard library class (clause _lib.strings_) }; int main() { C a; C b = a; b = a; } the implementation will implicitly define functions to make the defi- nition 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 (_basic.scope.pdecl_). ] 6 A program is ill-formed if the definition of any object gives the object an incomplete type (_basic.types_). 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. 2 An expression is potentially evaluated unless either it is the operand of the sizeof operator (_expr.sizeof_), or it is the operand of the typeid operator and does not designate an lvalue of polymorphic class type (_expr.typeid_). 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 functions (_expr.call_), operator overloading (clause _over_), user- defined conversions (_class.conv.fct_), allocation function for place- ment new (_expr.new_), as well as non-default initialization (_dcl.init_). A copy constructor is used even if the call is actually elided by the implementation. ] An allocation or deallocation func- tion for a class is used by a new expression appearing in a poten- tially-evaluated expression as specified in _expr.new_ and _class.free_. A deallocation function for a class is used by a delete expression appearing in a potentially-evaluated expression as speci- fied in _expr.delete_ and _class.free_. A copy-assignment function for a class is used by an implicitly-defined copy-assignment function for another class as specified in _class.copy_. A default constructor for a class is used by default initialization as specified in _dcl.init_. A constructor for a class is used as specified in _dcl.init_. A destructor for a class is used as specified in _class.dtor_. 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 appropri- ate) it is implicitly defined (see _class.ctor_, _class.dtor_ and _class.copy_). An inline function shall be defined in every transla- tion 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 com- plete. [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 (_basic.def_, _expr.new_), or --an lvalue-to-rvalue conversion is applied to an lvalue referring to an object of type T (_conv.lval_), or --an expression is converted (either implicitly or explicitly) to type T (clause _conv_, _expr.type.conv_, _expr.dynamic.cast_, _expr.static.cast_, _expr.cast_), 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 refer- ence to T using an implicit conversion (clause _conv_), a dynamic_cast (_expr.dynamic.cast_) or a static_cast (_expr.static.cast_), or --a class member access operator is applied to an expression of type T (_expr.ref_), or --the typeid operator (_expr.typeid_) or the sizeof operator (_expr.sizeof_) is applied to an operand of type T, or --a function with a return type or argument type of type T is defined (_basic.def_) or called (_expr.call_), or --an lvalue of type T is assigned to (_expr.ass_). ] 5 There can be more than one definition of a class type (clause _class_), enumeration type (_dcl.enum_), inline function with external linkage (_dcl.fct.spec_), class template (clause _temp_), non-static function template (_temp.fct_), static data member of a class template (_temp.static_), member function template (_temp.mem.func_), or tem- plate specialization for which some template parameters are not specified (_temp.spec_, _temp.class.spec_) 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 _basic.lookup_, shall refer to an entity defined within the defini- tion of D, or shall refer to the same entity, after overload resolu- tion (_over.match_) and after matching of partial template special- ization (_temp.over_), except that a name can refer to a const object with internal or no linkage if the object has the same inte- gral or enumeration type in all definitions of D, and the object is initialized with a constant expression (_expr.const_), 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 (_class.ctor_), it is as if the constructor was implicitly defined in every translation unit where it is used, and the implicit defini- tion in every translation unit shall call the same constructor for a base class or a class member of D. [Example: _________________________ 25) _dcl.fct.default_ describes how default argument names are looked up. // 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 (_temp.nondep_), and also to dependent names at the point of instantiation (_temp.dep_). If the defini- tions of D satisfy all these requirements, then the program shall behave as if there were a single definition of D. If the defini- tions 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 par- ticular name is valid only within some possibly discontiguous portion of program text called its scope. To determine the scope of a decla- ration, it is sometimes convenient to refer to the potential scope of a declaration. The scope of a declaration is the same as its poten- tial 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. 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 decla- ration 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 (_class.friend_), certain uses of the elaborated-type-speci- fier (_basic.scope.pdecl_), and using-directives (_namespace.udir_) 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 function templates; in this case the class name or enumeration name is hidden (_basic.scope.hiding_). [Note: a namespace name or a class template name must be unique in its declarative region (_namespace.alias_, clause _temp_). ] [Note: these restrictions apply to the declarative region into which a name is introduced, which is not necessarily the same as the region in which the declaration occurs. In particular, elaborated-type-speci- fiers (_basic.scope.pdecl_) and friend declarations (_class.friend_) may introduce a (possibly not visible) name into an enclosing names- pace; these restrictions apply to that region. Local extern declara- tions (_basic.link_) may introduce a name into the declarative region where the declaration appears and also introduce a (possibly not visi- ble) name into an enclosing namespace; these restrictions apply to both regions. ] 5 [Note: the name lookup rules are summarized in _basic.lookup_. ] 3.3.1 Point of declaration [basic.scope.pdecl] 1 The point of declaration for a name is immediately after its complete declarator (clause _dcl.decl_) 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. ] 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 decla- ration, the identifier is declared in the smallest non-class, non- function-prototype scope that contains the declaration. [Note: if the elaborated-type-specifier designates an enumeration, the identi- fier 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 _basic.lookup.elab_. ] 6 [Note: friend declarations refer to functions or classes that are mem- bers of the nearest enclosing namespace, but they do not introduce new names into that namespace (_namespace.memdef_). 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 _temp.inst_. ] 3.3.2 Local scope [basic.scope.local] 1 A name declared in a block (_stmt.block_) is local to that block. Its potential scope begins at its point of declaration (_basic.scope.pdecl_) and ends at the end of its declarative region. 2 The potential scope of a function parameter name in a function defini- tion (_dcl.fct.def_) begins at its point of declaration. If the func- tion 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 defini- tion nor in the outermost block of any handler associated with a func- tion try-block . 3 The name in a catch exception-declaration is local to the handler and shall not be redeclared in the outermost 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 statement, any of the outermost blocks) of the controlled statement; see _stmt.select_. 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 (_dcl.fct.def_), names of parame- ters (if supplied) have function prototype scope, which terminates at the end of the nearest enclosing function declarator. 3.3.4 Function scope [basic.funscope] 1 Labels (_stmt.label_) 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 names- pace scope. Its potential scope includes its namespace from the name's point of declaration (_basic.scope.pdecl_) onwards; and for each using-directive (_namespace.udir_) 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 resolu- tion operator (_expr.prim_) applied to the name of its namespace or the name of a namespace which nominates the member's namespace in a using-directive; see _namespace.qual_. 3 A name declared outside all named or unnamed namespaces (_basic.names- pace_), blocks (_stmt.block_), function declarations (_dcl.fct_), function definitions (_dcl.fct.def_) and classes (clause _class_) has global namespace scope (also called global scope). The potential scope of such a name begins at its point of declaration (_basic.scope.pdecl_) 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-ini- tializers in that class (including such things in nested classes). 2)A name N used in a class S shall refer to the same declaration in its context and when re-evaluated in the completed scope of S. No diagnostic is required for a violation of this rule. 3)If reordering member declarations in a class yields an alternate valid program under (1) and (2), the program is ill-formed, no diag- nostic 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 func- tion'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 out- side the class (this includes static data member definitions, nested class definitions, member function definitions (including the member function body and, for constructor functions (_class.ctor_), the ctor-initializer (_class.base.init_)) and any portion of the declarator part of such definitions which follows the identifier, including a parameter-declaration-clause and any default arguments (_dcl.fct.default_). [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 _class.derived_) from its class, --after the . operator applied to an expression of the type of its class (_expr.ref_) or a class derived from its class, --after the -> operator applied to a pointer to an object of its class (_expr.ref_) or a class derived from its class, --after the :: scope resolution operator (_expr.prim_) 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 (_class.member.lookup_). 2 A class name (_class.name_) or enumeration name (_dcl.enum_) can be hidden by the name of an object, function, or enumerator declared in the same scope. If a class or enumeration name and an object, func- tion, or enumerator are 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 _basic.scope.class_. The declaration of a member in a derived class (clause _class.derived_) hides the declaration of a member of a base class of the same name; see _class.member.lookup_. 4 During the lookup of a name qualified by a namespace name, declara- tions 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 (_namespace.qual_). 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 (_dcl.typedef_), namespace-names (_basic.namespace_) and class- names (_class.name_)) wherever the grammar allows such names in the context discussed by a particular rule. Name lookup associates the use of a name with a declaration (_basic.def_) of that name. Name lookup shall find an unambiguous declaration for the name (see _class.member.lookup_). Name lookup may associate more than one dec- laration with a name if it finds the name to be a function name; the declarations are said to form a set of overloaded functions (_over.load_). Overload resolution (_over.match_) takes place after name lookup has succeeded. The access rules (clause _class.access_) are considered only once name lookup and function overload resolution (if applicable) have succeeded. Only after name lookup, function overload resolution (if applicable) and access checking have succeeded are the attributes introduced by the name's declaration used further in expression processing (clause _expr_). 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 _class_), the name of a class is also considered a member of that class for the purposes of name hiding and lookup. 4 [Note: _basic.link_ discusses linkage issues. The notions of scope, point of declaration and name hiding are discussed in _basic.scope_. ] 3.4.1 Unqualified name lookup [basic.lookup.unqual] 1 In all the cases listed in _basic.lookup.unqual_, the scopes are searched for a declaration in the order listed in each of the respec- tive 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 _namespace.udir_. For the purpose of the unqualified name lookup rules described in _basic.lookup.unqual_, 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 _basic.lookup.koenig_. [Note: for pur- poses of determining (during parsing) whether an expression is a post- fix-expression for a function call, the usual name lookup rules apply. The rules in _basic.lookup.koenig_ have no effect on the syntactic interpretation 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 call, the argument-dependent name lookup (_basic.lookup.koenig_) 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 names- pace 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 purpose of exposition, N could repre- sent the global scope) shall be declared before its use in the block in which it is used or in one of its enclosing blocks (_stmt.block_) 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: _________________________ 26) This refers to unqualified names following the function declara- tor; 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. 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 func- tion 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 (_class.member.lookup_), or --if X is a nested class of class Y (_class.nest_), before the defini- tion 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 (_class.local_) 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 defi- nition of class X in namespace N or in one of N's enclosing names- paces. [Example: _________________________ 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 defi- nition. 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 (_class.nest_). namespace M { class B { }; } 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 _names- pace.memdef_. ] [Note: _basic.scope.class_ further describes the restrictions on the use of names in a class definition. _class.nest_ further describes the restrictions on the use of names in nested class definitions. _class.local_ 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 (_class.mfct_)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 (_stmt.block_), or --shall be a member of class X or be a member of a base class of X (_class.member.lookup_), or --if X is a nested class of class Y (_class.nest_), 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 (_class.local_) 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 _________________________ 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 expression 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. --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; } // 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: _class.mfct_ and _class.static_ further describe the restrictions on the use of names in member function defi- nitions. _class.nest_ further describes the restrictions on the use of names in the scope of nested classes. _class.local_ further describes the restrictions on the use of names in local class defini- tions. ] 9 Name lookup for a name used in the definition of a friend function (_class.friend_) 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. 10In 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] 11During the lookup for a name used as a default argument (_dcl.fct.default_) in a function parameter-declaration-clause or used in the expression of a mem-initializer for a constructor (_class.base.init_), the function parameter names are visible and hide the names of entities declared in the block, class or namespace scopes containing the function declaration. [Note: _dcl.fct.default_ further describes the restrictions on the use of names in default arguments. _class.base.init_ further describes the restrictions on the use of names in a ctor-initializer. ] 12A name used in the definition of a static data member of class X (_class.static.data_) (after the qualified-id of the static member) is looked up as if the name was used in a member function of X. [Note: _class.static.data_ further describes the restrictions on the use of names in the definition of a static data member. ] 13A name used in the handler for a function-try-block (clause _except_) 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 redeclared in the exception-declaration nor in the outer- most 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 _temp.res_. ] 3.4.2 Argument-dependent name lookup [basic.lookup.koenig] 1 When an unqualified name is used as the postfix-expression in a func- tion call (_expr.call_), other namespaces not considered during the usual unqualified lookup (_basic.lookup.unqual_) may be searched, and namespace-scope friend function declarations (_class.friend_) not oth- erwise 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). 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 follow- ing 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 associ- ated with the return type. --If T is a pointer to a member function of a class X, its associated namespaces and classes are those associated with the function param- eter types and return type, together with those associated with X. --If T is a pointer to a data member of class X, its associated names- paces 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 associated 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. [Exam- ple: 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 associated namespace is used as a quali- fier (_namespace.qual_) 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 (_class.friend_). 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 (_expr.prim_) applied to a nested-name- specifier that nominates its class or namespace. During the lookup for a name preceding the :: scope resolution operator, object, func- tion, and enumerator names are ignored. If the name found is not a class-name (clause _class_) or namespace-name (_namespace.def_), the program is ill-formed. [Example: 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 (_class.nest_) 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 :: (_expr.prim_) is looked up in global scope, in the translation unit where it is used. The name shall be declared in global namespace scope or shall be a name whose declaration is visible in global scope because of a using-direc- tive (_namespace.qual_). The use of :: allows a global name to be referred to even if its identifier has been hidden (_basic.scope.hid- ing_). 5 If a pseudo-destructor-name (_expr.pseudo_) contains a nested-name- specifier, the type-names are looked up as types in the scope desig- nated 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 struct A { ~A(); }; typedef A AB; int main() { AB *p; p->AB::~AB(); // explicitly calls the destructor for A } --end example] [Note: _basic.lookup.classref_ 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 (_class.member.lookup_), except for the cases listed below. The name shall represent one or more members of that class or of one of its base classes (clause _class.derived_). [Note: a class member can be referred to using a qualified-id at any point in its potential scope (_basic.scope.class_). ] The exceptions to the name lookup rule above are the following: --a destructor name is looked up as specified in _basic.lookup.qual_; --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 post- fix-expression occurs and shall refer to the same type in both con- texts; --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 tem- plate-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 con- taining 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 con- text of the reference is a using-declaration (_namespace.udecl_), 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 pro- gram is ill-formed. [Example: int x; namespace Y { void f(float); void h(int); } namespace Z { void h(double); } namespace A { using namespace Y; void f(int); void g(int); int i; } namespace B { using namespace Z; void f(char); int i; } namespace AB { using namespace A; using namespace B; 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; } 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 fol- lowing 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 declarations are from different namespaces), the program is ill- formed. [Example: namespace A { struct x { }; int x; int y; } namespace B { struct y {}; } namespace C { using namespace A; using namespace B; int i = C::x; // OK, A::x (of type int) 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. [Example: namespace A { namespace B { void f1(int); } using namespace B; } void A::f1(int) { } // ill-formed, f1 is not a member of A --end example] However, in such namespace member declarations, the nested-name-specifier may rely on using-directives to implicitly pro- vide 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 (_basic.scope.hiding_). 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 _basic.lookup.unqual_ 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 elabo- rated-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 _basic.scope.pdecl_. 3 If the name is a qualified-id, the name is looked up according its qualifications, as described in _basic.lookup.qual_, 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 (_dcl.type.elab_) friend struct Glob; // OK: Refers to (as yet) undeclared Glob // at global scope. /* ... */ }; struct Base { struct Data; // OK: Declares nested Data struct ::Data* thatData; // OK: Refers to ::Data struct Base::Data* thisData; // OK: Refers to nested Data friend class ::Data; // OK: global Data is a friend friend class Data; // OK: nested Data is a friend struct Data { /* ... */ }; // Defines nested Data struct Data; // OK: Redeclares nested Data }; struct Data; // OK: Redeclares Data at global scope struct ::Data; // error: cannot introduce a qualified type (_dcl.type.elab_) struct Base::Data; // error: cannot introduce a qualified type (_dcl.type.elab_) struct Base::Datum; // error: Datum undefined struct Base::Data* pBase; // OK: refers to nested Data --end example] 3.4.5 Class member access [basic.lookup.classref] 1 In a class member access expression (_expr.ref_), if the . or -> token is immediately followed by an identifier followed by a <, the identi- fier must be looked up to determine whether the < is the beginning of a template argument list (_temp.names_) 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 tem- plate. If the lookup in the class of the object expression finds a template, 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, oth- erwise the program is ill-formed. 2 If the id-expression in a class member access (_expr.ref_) is an unqualified-id, and the type of the object expression 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 mem- bers of the class type of the object expression and are not ambiguous according to _class.member.lookup_. 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 (_temp.names_), 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 expression (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. 3.5 Program and linkage [basic.link] 1 A program consists of one or more translation units (clause _lex_) linked together. A translation unit consists of a sequence of decla- rations. 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 (_basic.scope.namespace_) 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 _class_), or an unnamed class defined in a typedef declaration in which the class has the typedef name for linkage purposes (_dcl.typedef_); or --a named enumeration (_dcl.enum_), or an unnamed enumeration defined in a typedef declaration in which the enumeration has the typedef name for linkage purposes (_dcl.typedef_); or --an enumerator belonging to an enumeration with external linkage; or --a template, unless it is a function template that has internal link- age (clause _temp_); or --a namespace (_basic.namespace_), unless it is declared within an unnamed namespace. 5 In addition, a member function, static data member, class or enumera- tion of class scope has external linkage 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. [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 declaration in global scope (line //1), the object with automatic storage duration and no linkage intro- duced by the declaration on line //2, and the object with static stor- age 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 (_basic.scope.local_) has no linkage. A name with no linkage (notably, the name of a class or enu- meration declared in a local scope (_basic.scope.local_)) shall not be used to declare an entity with linkage. If a declaration uses a type- def 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 (_temp.arg_). 9 Two names that are the same (clause _basic_) 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 --when both names denote functions, the function types are identical for purposes of overloading; and --when both names denote function templates, the signatures (_temp.over.link_) are the same. 10After all adjustments of types (during which typedefs (_dcl.typedef_) are replaced by their definitions), the types specified by all decla- rations referring to a given object or function shall be identical, except that declarations for an array object can specify array types that differ by the presence or absence of a major array bound (_dcl.array_). 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 link- age-specification (_dcl.link_). ] 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 termina- tion is implementation-defined; start-up contains the execution of constructors for objects of namespace scope with static storage dura- tion; termination contains the execution of destructors for objects with static storage duration. ] 2 An implementation shall not predefine the main function. This func- tion shall not be overloaded. It shall have a return type of type int, but otherwise its type is implementation-defined. All implemen- tations 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) (_lib.multibyte.strings_) 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 recom- mended that any further (optional) parameters be added after argv. ] 3 The function main shall not be used (_basic.def.odr_) within a pro- gram. The linkage (_basic.link_) 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 (_lib.support.start.term_) terminates the pro- gram without leaving the current block and hence without destroying any objects with automatic storage duration (_class.dtor_). If exit is called to end a program during 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 automatic 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; 3.6.2 Initialization of non-local objects [basic.start.init] 1 The storage for objects with static storage duration (_basic.stc.static_) shall be zero-initialized (_dcl.init_) before any other initialization takes place. Zero-initialization and initializa- tion with a constant expression are collectively called static ini- tialization; all other initialization is dynamic initialization. Objects of POD types (_basic.types_) with static storage duration ini- tialized with constant expressions (_expr.const_) 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: _dcl.init.aggr_ describes the order in which aggregate members are initialized. The initialization of local static objects is described in _stmt.dcl_. ] 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, provided 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 produced by the dynamic initial- ization 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 dura- tion 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-ini- tialized. 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 (_dcl.init_, _class.static_, _class.ctor_, _class.expl.init_) 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; // - 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 initial- ized 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 (_lib.terminate_). _________________________ 31) An object defined in namespace scope having initialization with side-effects must be initialized even if it is not used (_ba- sic.stc.static_). 3.6.3 Termination [basic.start.term] 1 Destructors (_class.dtor_) 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 (_lib.support.start.term_). These objects are destroyed in the reverse order of the completion of their constructor or of the comple- tion 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 subobjects 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 , _lib.sup- port.start.term_) 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 regis- tered 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 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 containing the object. The storage duration is determined by the construct used to create the object and is one of the following: --static storage duration --automatic storage duration --dynamic storage duration 2 Static and automatic storage durations are associated with objects introduced by declarations (_basic.def_) and implicitly created by the implementation (_class.temporary_). The dynamic storage duration is associated with objects created with operator new (_expr.new_). 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 duration. 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 (_basic.start.init_, _basic.start.term_). 2 If an object of static storage duration has initialization or a destructor with side effects, it shall not be eliminated even if it appears to be unused, except that a class object or its copy may be eliminated as specified in _class.copy_. 3 The keyword static can be used to declare a local variable with static storage duration. [Note: _stmt.dcl_ describes the initialization of local static variables; _basic.start.term_ describes the destruction of local static variables. ] 4 The keyword static applied to a class data member in a class defini- tion 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 stor- age for these objects lasts until the block in which they are created exits. 2 [Note: these objects are initialized and destroyed as described in _stmt.dcl_. ] 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 _class.copy_. 3.7.3 Dynamic storage duration [basic.stc.dynamic] 1 Objects can be created dynamically during program execution (_intro.execution_), using new-expressions (_expr.new_), and destroyed using delete-expressions (_expr.delete_). A C++ implementation pro- vides 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 func- tions are replaceable (_lib.new.delete_). 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 (_lib.replacement.functions_). The following allocation and deallocation functions (_lib.support.dynamic_) are implicitly declared in global scope in each translation unit of a pro- gram 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 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. ] Allocation and/or deallocation functions can also be declared and defined for any class (_class.free_). 3 Any allocation and/or deallocation functions defined in a C++ program shall conform to the semantics specified in _basic.stc.dynamic.alloca- tion_ and _basic.stc.dynamic.deallocation_. 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 (_lib.support.types_). The first parameter shall not have an associated default argument (_dcl.fct.default_). The value of the first parameter shall be inter- preted as the requested size of the allocation. An allocation func- tion 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 parame- ter 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 allocation function. The order, contiguity, and initial value of storage allocated by succes- sive calls to an allocation 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 (_conv.ptr_). The results of dereferencing 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 (_lib.new.handler_), if any. [Note: A program-supplied allocation function can obtain the address of the currently installed new_handler using the set_new_handler function (_lib.set.new.handler_). ] If an allocation function declared with an empty exception-specification (_except.spec_), throw(), fails to allo- cate storage, it shall return a null pointer. Any other allocation function that fails to allocate storage shall only indicate failure by throwing an exception of class std::bad_alloc (_lib.bad.alloc_) or a class derived from std::bad_alloc. 4 A global allocation function is only called as the result of a new expression (_expr.new_), or called directly using the function call syntax (_expr.call_), or called indirectly through calls to the func- tions in the C++ standard library. [Note: in particular, a global allocation function is not called to allocate storage for objects with static storage duration (_basic.stc.static_), for objects of type type_info (_expr.typeid_), for the copy of an object thrown by a throw expression (_except.throw_). ] 3.7.3.2 Deallocation functions [basic.stc.dynamic.deallocation] 1 Deallocation functions shall be class member functions or global func- tions; a program is ill-formed if deallocation 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 function can have more than one param- eter. 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 (_lib.support.types_), then this function is a usual deallocation function. Similarly, if a class T has a member dealloca- tion function named operator delete[] with exactly one parameter, then that function is a usual (non-placement) deallocation function. If class T does not declare such an operator delete[] but does declare a member deallocation function named operator delete[] with exactly two parameters, the second of which has type std::size_t, then this func- tion is a usual deallocation function. A deallocation function can be an instance of a function template. Neither the first parameter nor _________________________ 32) The intent is to have operator new() implementable by calling mal- loc() or calloc(), so the rules are substantially the same. C++ dif- fers from C in requiring a zero request to return a non-null pointer. 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 dealloca- tion function template shall have two or more function parameters. A template instance is never a usual deallocation function, regardless 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 stan- dard library shall be one of the values returned by a previous invoca- tion 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 (_conv.ptr_), the deallocation function shall deallocate the storage referenced by the pointer, rendering 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 complete object (_intro.object_). 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 (_class.ctor_), 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 (_class.dtor_), the destructor call starts, or --the storage which the object occupies is reused or released. _________________________ 33) On some implementations, it causes a system-generated runtime fault. 2 [Note: the lifetime of an array object or of an object of type (_basic.types_) starts as soon as storage with proper size and align- ment is obtained, and its lifetime ends when the storage which the array or object occupies is reused or released. _class.base.init_ describes the lifetime of base and member subobjects. ] 3 The properties ascribed to objects throughout this International Stan- dard apply for a given object only during its lifetime. [Note: in particular, before the lifetime of an object starts and after its lifetime ends there are significant restrictions on the use of the object, as described below, in _class.base.init_ and in _class.cdtor_. Also, the behavior of an object under construction and destruction might not be the same as the behavior of an object whose lifetime has started and not ended. _class.base.init_ and _class.cdtor_ describe the behavior of objects during the construction 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 (_expr.delete_) 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 behavior. 5 Before the lifetime of an object has started but after the storage which the object will occupy has been allocated34) or, after the life- time 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 (_basic.stc.dynamic.deallocation_), 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 (_conv.ptr_) to a pointer to a base class type, or --the pointer is used as the operand of a static_cast _________________________ 34) For example, before the construction of a global object of non-POD class type (_class.cdtor_). (_expr.static.cast_) (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 (_expr.dynamic.cast_). [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 (_basic.stc.dynamic.deallocation_), and using the properties of the lvalue which do not depend on its value is well-defined. If an lvalue-to-rvalue conversion (_conv.lval_) 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 --the lvalue is implicitly converted (_conv.ptr_) to a reference to a base class type, or --the lvalue is used as the operand of a static_cast (_expr.static.cast_) (except when the conversion is ultimately to char& or unsigned char&), or --the lvalue is used as the operand of a dynamic_cast (_expr.dynamic.cast_) 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 cre- ated 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 auto- matically 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 (_intro.object_) 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 (_basic.stc.static_) or automatic (_basic.stc.auto_) 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 program is undefined. This is true even if the block is exited with an exception. [Example: _________________________ 35) that is, an object for which a destructor will be called implicit- ly -- either upon exit from the block for an object with automatic storage duration or upon exit from the program for an object with static storage duration. class T { }; struct B { ~B(); }; void h() { B b; new (&b) T; } // undefined behavior at block exit --end example] 9 Creating a new object at the storage location that a const object with static or automatic storage duration occupies or, at the storage loca- tion 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: _basic.types_ 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 (_intro.object_), references (_dcl.ref_), or functions (_dcl.fct_). ] 2 For any complete POD object type T, whether or not the object holds a valid value of type T, the underlying bytes (_intro.memory_) making up the object can be copied into an array of char or unsigned char.36) If the content of the array of char or unsigned char is copied back into the object, the object shall subsequently hold its original value. [Example: #define N sizeof(T) char buf[N]; T obj; // 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 _________________________ 36) By using, for example, the library functions (_lib.headers_) mem- cpy or memmove. 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 representa- tion is a set of bits in the object representation that determines a value, which is one discrete element of an implementation-defined set of values.37) 5 Object types have alignment requirements (_basic.fundamental_, _basic.compound_). 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 require- ments of its object type. 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 incomplete types (_basic.fundamental_). 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 translation unit, the array type becomes complete; the array type at those two points is the same type. The declared type of an array object might be an array of unknown size and therefore be incomplete at one point in a translation unit and complete later on; the array types at those two points ("array of unknown bound of T" and "array of N T") are different types. The type of a pointer to array of unknown size, or of a type defined by a type- def declaration to be an array of unknown size, cannot be completed. [Example: _________________________ 37) The intent is that the memory model of C++ is compatible with that of ISO/IEC 9899 Programming Language C. 38) The size and layout of an instance of an incompletely-defined ob- ject type is unknown. 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 prohibited. ] 9 An object type is a (possibly cv-qualified) type that is not a func- tion type, not a reference type, and not a void type. 10Arithmetic types (_basic.fundamental_), enumeration types, pointer types, and pointer to member types (_basic.compound_), and cv-quali- fied versions of these types (_basic.type.qualifier_) are collectively called scalar types. Scalar types, POD-struct types, POD-union types (clause _class_), arrays of such types and cv-qualified versions of these types (_basic.type.qualifier_) are collectively called POD types. 11If two types T1 and T2 are the same type, then T1 and T2 are layout- compatible types. [Note: Layout-compatible enumerations are described in _dcl.enum_. Layout-compatible POD-structs and POD-unions are described in _class.mem_. ] 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 charac- ter from this set is stored in a character object, the integral value of that character object is equal to the value of the single character literal form of that character. It is implementation-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 alignment requirements (_basic.types_); 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 natural 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 (_basic.types_) as the corresponding signed integer type40) ; that is, each signed integer type has the same object repre- sentation as its corresponding unsigned integer type. The range of nonnegative values of a signed integer type is a subrange of the cor- responding unsigned integer type, and the value representation of each corresponding signed/unsigned type shall be the same. 4 Unsigned integers, declared unsigned, shall obey the laws of arith- metic modulo 2n where n is the number of bits in the value representa- tion 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 (_lib.locale_). Type wchar_t shall have the same size, signedness, and alignment requirements (_basic.types_) 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 _________________________ 39) that is, large enough to contain any value in the range of INT_MIN and INT_MAX, as defined in the header . 40) See _dcl.type.simple_ 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 integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting unsigned integer type. 42) Using a bool value in ways described by this International Stan- dard as ``undefined,'' such as by examining the value of an uninitial- ized automatic variable, might cause it to behave as if is neither true nor false. participate in integral promotions (_conv.prom_). 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 values by use of a pure binary numeration system.44) [Example: this International Standard permits 2's complement, 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 of values of the type double is a subset of the set of values of the type long double. The value representation of floating-point types is implementation-defined. Integral and floating types are collectively called arithmetic types. Specializa- tions of the standard template numeric_limits (_lib.support.limits_) 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 incom- plete type that cannot be completed. It is used as the return type for functions that do not return a value. Any expression can be explicitly converted to type cv void (_expr.cast_). An expression of type void shall be used only as an expression statement (_stmt.expr_), as an operand of a comma expression (_expr.comma_), as a second or third operand of ?: (_expr.cond_), as the operand of typeid, or as the expression in a return statement (_stmt.return_) 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, _dcl.array_; --functions, which have parameters of given types and return void or references or objects of a given type, _dcl.fct_; _________________________ 43) Therefore, enumerations (_dcl.enum_) are not integral; however, enumerations can be promoted to int, unsigned int, long, or unsigned long, as specified in _conv.prom_. 44) A positional representation for integers that uses the binary dig- its 0 and 1, in which the values represented by successive bits are additive, begin with 1, and are multiplied by successive integral pow- er of 2, except perhaps for the bit with the highest position. (Adapted from the American National Dictionary for Information Pro- cessing Systems.) --pointers to void or objects or functions (including static members of classes) of a given type, _dcl.ptr_; --references to objects or functions of a given type, _dcl.ref_; --classes containing a sequence of objects of various types (clause _class_), a set of types, enumerations and functions for manipulat- ing these objects (_class.mfct_), and a set of restrictions on the access to these entities (clause _class.access_); --unions, which are classes capable of containing objects of different types at different times, _class.union_; --enumerations, which comprise a set of named constant values. Each distinct enumeration constitutes a different enumerated type, _dcl.enum_; --pointers to non-static45) class members, which identify members of a given type within objects of a given class, _dcl.mptr_. 2 These methods of constructing types can be applied recursively; restrictions are mentioned in _dcl.ptr_, _dcl.array_, _dcl.fct_, and _dcl.ref_. 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 refer- ring 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 (_basic.types_). The value representation of pointer types is implementation-defined. Pointers to cv-qualified and cv-unqualified versions (_basic.type.qualifier_) of layout-compatible types shall have the same value representation and alignment require- ments (_basic.types_). 4 Objects of cv-qualified (_basic.type.qualifier_) 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 (_basic.type.qualifier_) void* shall have the same representation and alignment requirements as a cv-quali- fied or cv-unqualified char*. 3.9.3 CV-qualifiers [basic.type.qualifier] 1 A type mentioned in _basic.fundamental_ and _basic.compound_ is a cv- unqualified type. Each type which is a cv-unqualified complete or incomplete object type or is void (_basic.types_) has three corre- sponding cv-qualified versions of its type: a const-qualified version, a volatile-qualified version, and a const-volatile-qualified version. _________________________ 45) Static class members are objects or functions, and pointers to them are ordinary pointers to objects or functions. The term object type (_intro.object_) includes the cv-qualifiers spec- ified when the object is created. The presence of a const specifier 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 (_basic.types_).46) 2 A compound type (_basic.compound_) is not cv-qualified by the cv-qual- ifiers (if any) of the types from which it is compounded. Any cv- qualifiers applied to an array type affect the array element type, not the array type (_dcl.array_). 3 Each non-static, non-mutable, non-reference data member of a const- qualified class object is const-qualified, each non-static, non-refer- ence data member of a volatile-qualified class object is volatile- qualified and similarly for members of a const-volatile class. See _dcl.fct_ and _class.this_ 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 rela- tions that constitute this ordering. _________________________ 46) The same representation and alignment requirements are meant to imply interchangeability as arguments to functions, return values from functions, and members of unions. Table 6--relations on const and volatile +----------+ x] .if 00h0]>85M .as 10 0]u-85M)' x] .if 00d0]>35M .as 10 0]u-35M' no cv-qualifier85M .as 10 0]u-85M)' x] .if 00d0]>35M .as 10 0]u-35M' no cv-qualifier85M .as 10 0]u-85M)' x] .if 00d0]>35M .as 10 0]u-35M' no cv-qualifier85M .as 10 0]u-85M)' x] .if 00d0]>35M .as 10 0]u-35M' const85M .as 10 0]u-85M)' x] .if 00d0]>35M .as 10 0]u-35M' volatile0 such that: 0sfont]I]ize]u'TR]1R]is2]cvR]1R]pointer to2]cvR]1R]pointer to2]R].R].R].cvR]1R]R]pointer]to2]cvR]1T0rfont] and 0sfont]I]ize]u'TR]2R]is2]cvR]2R]pointer to2]cvR]2R]pointer to2]R].R].R].cvR]2R]R]pointer]to2]cvR]2T0rfont] where each cvi,j is const, volatile, const volatile, or nothing. The n-tuple of cv-qualifiers after the first in a pointer type, e.g., cv1,1, cv1,2, ..., cv1,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 cv1,j then const is in cv2,j, and _________________________ 50) This conversion never applies to nonstatic member functions be- cause an lvalue that refers to a nonstatic member function cannot be obtained. 51) These rules ensure that const-safety is preserved by the conver- sion. similarly for volatile. --if the cv1,j and cv2,j are different, then const is in every cv2,k for 00 such that: 0sfont]I]ize]u'TR]1R]is2]cvR]1PRR]to2]cvR]1PRR]to2]R].R].R].cvR]1R]PnR]R]to2]cvR]1T0rfont] and 0sfont]I]ize]u'TR]2R]is2]cvR]2PRR]to2]cvR]2PRR]to2]R].R].R].cvR]2R]PnR]R]to2]cvR]2T0rfont] 7 For similar multi-level pointer to member types and similar multi- level mixed pointer and pointer to member types, the rules for adding cv-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; otherwise, the source rvalue can be converted to an rvalue of type unsigned int. 2 An rvalue of type wchar_t (_basic.fundamental_) or an enumeration type (_dcl.enum_) can be converted to an rvalue of the first of the follow- ing 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 (_class.bit_) 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 represent 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. 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 enumeration 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 2n where n is the number of bits used to represent the unsigned type). [Note: In a two's complement representation, this conversion is conceptual and there is no change in the bit pattern (if there is no truncation). ] 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 _conv.bool_. 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 rep- resented in the destination type, the result of the conversion is that exact representation. If the source value is between two adjacent destination values, the result of the conversion is an implementation- 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 conversions. 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 truncates; 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 _conv.bool_. ] 2 An rvalue of an integer type or of an enumeration type can be con- verted 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 preci- sion occurs if the integral value cannot be represented 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 (_expr.const_) 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 conver- sion of a null pointer constant to a pointer to cv-qualified type is a single conversion, and not the sequence of a pointer conversion fol- lowed by a qualification conversion (_conv.qual_). 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 (_intro.object_) 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 _class.derived_) of D. If B is an inaccessible (clause _class.access_) or ambiguous (_class.member.lookup_) 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. 4.11 Pointer to member conversions [conv.mem] 1 A null pointer constant (_conv.ptr_) 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 (_conv.qual_). 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 _class.derived_) of B. If B is an inaccessible (clause _class.access_), ambiguous (_class.member.lookup_) or virtual (_class.mi_) base class of D, a program that necessitates this conver- sion 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 com- pared to the rule for pointers to objects (from pointer to derived to pointer to base) (_conv.ptr_, clause _class.derived_). 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*. ______________________________________________________________________ 5 Expressions [expr] ______________________________________________________________________ 1 [Note: Clause _expr_ 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 _class_) or enumeration type (_dcl.enum_). Uses of overloaded operators are transformed into func- tion calls as described in _over.oper_. Overloaded operators obey the rules for syntax specified in clause _expr_, 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 (_over.oper_), and are not guaranteed for operands of type bool. --end note] 3 Clause _expr_ 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 opera- tors 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 consid- ered where necessary to convert 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 con- sidered further according to the rules in clause _expr_; see _over.match.oper_, _over.built_. 4 Except where noted, the order of evaluation of operands of individual operators and subexpressions of individual expressions, and the order in which side effects take place, is unspecified.53) Between the pre- vious and next sequence point a scalar object shall have its stored value modified at most once by the evaluation of an expression. Fur- thermore, 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 expres- sion; otherwise the behavior is undefined. [Example: _________________________ 53) The precedence of operators is not directly specified, but it can be derived from the syntax. 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 mathemat- ically defined or not in the range of representable values for its type, the behavior is undefined, unless such an expression is a con- stant expression (_expr.const_), in which case the program is ill- formed. [Note: most existing implementations of C++ ignore integer 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" (_dcl.ref_, _dcl.init.ref_), the type is adjusted to T" prior to any further anal- ysis, the expression designates the object or function denoted by the reference, and the expression 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 (_conv.lval_), array-to-pointer (_conv.array_), or function-to-pointer (_conv.func_) standard conversions are applied to convert the expres- sion to an rvalue. [Note: because cv-qualifiers are removed from the type of an expression of non-class type when the expression is con- verted to an rvalue, an lvalue expression of type const int can, for example, be used where an rvalue expression of type int is required. ] 9 Many binary operators that expect operands of arithmetic or enumera- tion 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 con- verted 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 (_conv.prom_) shall be performed on both operands.54) _________________________ 54) As a consequence, operands of type bool, wchar_t, or an enumerated type are converted to some integral type. --Then, if either operand is unsigned long the other shall be con- verted to unsigned long. --Otherwise, if one operand is a long int and the other unsigned int, then if a long int can represent 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 con- verted to unsigned. [Note: otherwise, the only remaining case is that both operands are int ] 10The 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 (_lex.literal_). 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 (_class.this_) is invoked. The keyword this shall be used only inside a nonstatic class member function body (_class.mfct_) _________________________ 55) The cast and assignment operators must still perform their specif- ic conversions as described in _expr.cast_, _expr.static.cast_ and _expr.ass_. or in a constructor mem-initializer (_class.base.init_). The type of the expression is a pointer to the function's class (_class.this_), 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 oper- ator-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-func- tion-id shall have global namespace scope or be visible in global scope because of a using-directive (_namespace.udir_). [Note: the use of :: allows a type, an object, a function, an enumerator, or a names- pace declared in the global namespace to be referred to even if its identifier has been hidden (_basic.lookup.qual_). ] 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 (_expr.ref_). ] 7 An identifier is an id-expression provided it has been suitably declared (clause _dcl.dcl_). [Note: for operator-function-ids, see _over.oper_; for conversion-function-ids, see _class.conv.fct_; for template-ids, see _temp.names_. A class-name prefixed by ~ denotes a destructor; see _class.dtor_. Within the definition of a nonstatic member function, an identifier that names a nonstatic member is trans- formed to a class member access expression (_class.mfct.nonstatic_). ] 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. 8 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 (_temp.arg.explicit_), and then followed by the name of a member of either that class (_class.mem_) or one of its base classes (clause _class.derived_), is a qualified-id; _class.qual_ 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 (_basic.scope.class_). ] Where class-name :: class-name is used, and the two class-names refer to the same class, this notation names the constructor (_class.ctor_). Where class-name :: ~ class-name is used, the two class-names shall refer to the same class; this notation names the destructor (_class.dtor_). [Note: a typedef-name that names a class is a class-name (_dcl.typedef_). Except as the identifier in the declarator for a constructor or destructor definition outside of a class member-specification (_class.ctor_, _class.dtor_), a typedef- name that names a class may be used in a qualified-id to refer to a constructor or destructor. ] 9 A nested-name-specifier that names a namespace (_basic.namespace_), followed by the name of a member of that namespace (or the name of a member of a namespace made visible by a using-directive ) is a quali- fied-id; _namespace.qual_ 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 variable. 10In 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. 11An 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 (_expr.ref_) in which the object- expression refers to the member's class or a class derived from that class, or --to form a pointer to member (_expr.unary.op_), or --in the body of a nonstatic member function of that class or of a class derived from that class (_class.mfct.nonstatic_), or --in a mem-initializer for a constructor for that class or for a class derived from that class (_class.base.init_). 12A template-id shall be used as an unqualified-id only as specified in _temp.explicit_, _temp.spec_, and _temp.class.spec_. 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 com- pletely-defined object type.56) The expression E1[E2] is identical (by definition) to *((E1)+(E2)). [Note: see _expr.unary_ and _expr.add_ for details of * and + and _dcl.array_ for details of arrays. ] 5.2.2 Function call [expr.call] 1 There are two kinds of function call: ordinary function call and mem- ber function57) (_class.mfct_) 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 func- tion-to-pointer standard conversion (_conv.func_) is suppressed on the postfix expression), or it shall have pointer to function type. Call- ing a function through an expression whose function type has a lan- guage linkage that is different from the language linkage of the _________________________ 56) This is true even if the subscript operator is used in the follow- ing common idiom: &x[0]. 57) A static member function (_class.static_) is an ordinary function. function type of the called function's definition is undefined (_dcl.link_). For a member function call, the postfix expression shall be an implicit (_class.mfct.nonstatic_, _class.static_) or explicit class member access (_expr.ref_) whose id-expression is a function member name, or a pointer-to-member expression (_expr.mptr.oper_) selecting a function 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 _class.mfct.nonstatic_). ] If a function or member function name is used, the name can be overloaded (clause _over_), in which case the appropriate function shall be selected according to the rules in _over.match_. The function called in a member function call is normally selected according to the static type of the object expression (clause _class.derived_), but if that function is virtual and is not specified using a qualified-id then the function actually called will be the final overrider (_class.virtual_) 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. _class.cdtor_ 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 complete object type, a reference type or the type void. 4 When a function is called, each parameter (_dcl.fct_) shall be ini- tialized (_dcl.init_, _class.copy_, _class.ctor_) with its correspond- ing 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 initialization of a parameter, an implementation may avoid the construction of extra temporaries by combining the conversions on the associated argument and/or the con- struction of temporaries with the initialization of the parameter (see _class.temporary_). The lifetime of a parameter ends when the func- tion in which it is defined returns. The initialization and destruc- tion of each parameter occurs within the context of the calling func- tion. [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 _except_) with a handler that could handle the excep- tion, this handler is not considered. ] The value of a function call is the value returned by the called function except in a virtual func- tion 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 stati- cally chosen function. 5 [Note: a function can change the values of its non-const parameters, but these changes cannot affect the values of the arguments except where a parameter is of a reference type (_dcl.ref_); 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 (_dcl.type_, _lex.literal_, _lex.string_, _dcl.array_, _class.temporary_). In addition, it is possible to mod- ify the values of nonconstant objects through pointer parameters. ] 6 A function can be declared to accept fewer arguments (by declaring default arguments (_dcl.fct.default_)) or more arguments (by using the ellipsis, ... _dcl.fct_) than the number of parameters in the func- tion definition (_dcl.fct.def_). [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 (_lib.support.runtime_). The lvalue-to-rvalue (_conv.lval_), array-to-pointer (_conv.array_), and function-to-pointer (_conv.func_) 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 _class_), the behavior is undefined. If the argu- ment has integral or enumeration type that is subject to the integral promotions (_conv.prom_), or a floating point type that is subject to the floating point promotion (_conv.fpprom_), the value of the argu- ment is converted to the promoted type before the call. These promo- tions are referred to 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 argument expression list is unspecified. 9 Recursive calls are permitted, except to the function named main (_basic.start.main_). 10A function call is an lvalue if and only if the result type is a ref- erence. 5.2.3 Explicit type conversion (functional [expr.type.conv] notation) 1 A simple-type-specifier (_dcl.type_) followed by a parenthesized expression-list constructs a value of the specified type given the expression list. If the expression list is a single expression, the type conversion expression is equivalent (in definedness, and if defined in meaning) to the corresponding cast expression (_expr.cast_). If the simple-type-specifier specifies a class type, the class type shall be complete. If the expression list specifies more than a single value, the type shall be a class with a suitably declared constructor (_dcl.init_, _class.ctor_), 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 (_dcl.type.sim- ple_) for a non-array complete object type or the (possibly cv-quali- fied) void type, creates an rvalue of the specified type, whose value is determined by default-initialization (_dcl.init_; 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 (_basic.lval_). ] 5.2.4 Pseudo destructor call [expr.pseudo] 1 The use of a pseudo-destructor-name after a dot . or arrow -> opera- tor 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 operator (), 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. Fur- thermore, 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 designated 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 (_temp.arg.explicit_), and then fol- lowed 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 _________________________ 58) This evaluation happens even if the result is unnecessary to de- termine the value of the entire postfix expression, for example if the id-expression denotes a static member. 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 _class_), the name of a class is also considered a nested member of that class. ] [Note: _basic.lookup.classref_ describes how names are looked up after the . and -> operators. ] 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 _expr.ref_ 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 _expr.ref_, 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 _basic.type.qualifier_. 4 If E2 is declared to have type "reference to T", then E1.E2 is an lvalue; the type of E1.E2 is T. Otherwise, one of the following rules applies. --If E2 is a static data member, and the type of E2 is T, then E1.E2 is an lvalue; the expression designates the named member of the class. The type of E1.E2 is T. --If E2 is a non-static data member, and the type of E1 is "cq1 vq1 X", and the type of E2 is "cq2 vq2 T", the expression designates the named member of the object designated by the 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 mem- ber, then the type of E1.E2 is "vq12 T". If E2 is not declared to be a mutable member, then the type of E1.E2 is "cq12 vq12 T". --If E2 is a (possibly overloaded) member function, function overload resolution (_over.match_) is used to determine whether E1.E2 refers to a static or a non-static member function. --If it refers to a static member function, and the type of E2 is "function of (parameter type list) returning T", then E1.E2 is an lvalue; the expression designates the static member function. The 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 _________________________ 59) Note that if E1 has the type "pointer to class X", then (*(E1)) is an lvalue. left-hand operand of a member function call (_class.mfct_). [Note: any redundant set of parentheses surrounding the expression is ignored (_expr.prim_). ] 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 expres- sion E1.E2 is not an lvalue. The type of E1.E2 is T. 5 [Note: "class objects" can be structures (_class.mem_) and unions (_class.union_). Classes are discussed in clause _class_. ] 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 _depr_. ] The result is an rvalue. The type of the result is the cv-unqualified version of the type of the operand. See also _expr.add_ and _expr.ass_. 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 _expr.pre.incr_. ] 5.2.7 Dynamic cast [expr.dynamic.cast] 1 The result of the expression dynamic_cast(v) is the result of con- verting 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 (_expr.const.cast_). 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 refer- ence 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. [Exam- ple: struct B {}; struct D : B {}; void foo(D* dp) { B* bp = dynamic_cast(dp); // equivalent to B* bp = dp; } --end example] 6 Otherwise, v shall be a pointer to or an lvalue of a polymorphic type (_class.virtual_). 7 If T is "pointer to cv void," then the result is a pointer to the most derived object pointed to by v. Otherwise, a run-time check is applied to see if the object pointed or referred to by v can be con- verted 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 (_lib.bad.cast_). [Example: _________________________ 60) The most derived object (_intro.object_) pointed or referred to by v can contain other B objects as base classes, but these are ignored. 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(*bp); // fails ap = dynamic_cast(bp); // fails bp = dynamic_cast(ap); // fails ap = dynamic_cast(&d); // succeeds bp = dynamic_cast(&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(ap); // fails: yields 0 // f has two D sub-objects E* ep = (E*)ap; // ill-formed: // cast from virtual base E* ep1 = dynamic_cast(ap); // succeeds } --end example] [Note: _class.cdtor_ describes the behavior of a dynamic_cast applied to an object under construction 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 (_lib.type.info_) 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 _lib.type.info_.61) The lifetime of the object referred to by the lvalue extends to the end of the program. Whether or not the destruc- tor 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 poly- morphic class type (_class.virtual_), the result refers to a type_info object representing the type of the most derived object (_intro.object_) (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 (_conv.ptr_), the typeid expression throws the bad_typeid exception (_lib.bad.typeid_). _________________________ 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. 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 repre- senting the static type of the expression. Lvalue-to-rvalue (_conv.lval_), array-to-pointer (_conv.array_), and function-to- pointer (_conv.func_) conversions are not applied to the expression. If the type of the expression is a class type, the class shall be com- pletely-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. 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 (_lib.type.info_) is not included prior to a use of typeid, the program is ill-formed. 7 [Note: _class.cdtor_ 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(v) is the result of con- verting 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 (_expr.const.cast_). 2 An expression e can be explicitly converted to a type T using a static_cast of the form static_cast(e) if the declaration T t(e);" is well-formed, for some invented temporary variable t (_dcl.init_). The effect of such an explicit conversion is the same as performing the declaration and initialization and then using the temporary vari- able as the result of the conversion. The result is an lvalue if T is a reference type (_dcl.ref_), 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 (_class.temporary_), the destructor for that vari- able is not executed until the usual time, and the value of the vari- able is preserved for the purpose of executing the destructor. ] The lvalue-to-rvalue (_conv.lval_), array-to-pointer (_conv.array_), and function-to-pointer (_conv.func_) 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 _class.derived_) from B, if a valid standard conversion from "pointer to D" to "pointer to B" exists (_conv.ptr_), cv2 is the same cv-quali- fication 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. Other- wise, the result of the cast is undefined. [Example: struct B {}; struct D : public B {}; D d; B &br = d; static_cast(br); // produces lvalue to the original d object --end example] 6 The inverse of any standard conversion sequence (clause _conv_), other than the lvalue-to-rvalue (_conv.lval_), array-to-pointer (_conv.array_), function-to-pointer (_conv.func_), and boolean (_conv.bool_) conversions, can be performed explicitly using static_cast subject to the restriction that the explicit conversion does not cast away constness (_expr.const.cast_), and the following additional rules for specific cases: 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 (_dcl.enum_). Otherwise, the result- ing 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 _class.derived_) from B, if a valid standard conver- sion from "pointer to D" to "pointer to B" exists (_conv.ptr_), 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 (_conv.ptr_) 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 con- verted to an rvalue of type "pointer to member of B of type cv2 T", where B is a base class (clause _class.derived_) 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 (_conv.mem_), and cv2 is the same cv-qualification as, or greater cv-qualification than, cv1.63) The null member pointer value (_conv.mem_) is converted to the null member pointer value of the destination type. If class B contains the original member, or is a base or derived class of the class containing the original member, the resulting pointer to member points to the original member. Otherwise, the result of the cast is 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 _expr.mptr.oper_. ] 10An 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(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 (_conv.lval_), array-to-pointer (_conv.array_), and function-to-pointer (_conv.func_) standard conversions are performed on the the expression v. Types shall not be defined in a reinter- pret_cast. Conversions that can be performed explicitly using rein- terpret_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 _expr.const.cast_ for the definition of ``casting away const- ness''. 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 con- verted to a pointer.64) A pointer converted to an integer of suffi- cient size (if any such exists on the implementation) and back to the _________________________ 63) Function types (including those used in pointer to member function types) are never cv-qualified; see _dcl.fct_ . 64) Converting an integral constant expression (_expr.const_) with value zero always yields a null pointer (_conv.ptr_), but converting other expressions that happen to have value zero need not yield a null pointer. 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 (_dcl.fct_) 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 _conv.ptr_ for more details of 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 (_conv.ptr_) 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 explic- itly 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 (_conv.mem_) 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 dif- ferent 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 member of Y of type T2" (where the alignment requirements of T2 are no stricter than those of T1) and back to its original type yields the original pointer to member value. 10An 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 con- verted to the type "pointer to T2" using a reinterpret_cast. That is, a reference cast reinterpret_cast(x) has the same effect as the conversion *reinterpret_cast(&x) with the built-in & and * opera- tors. 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 _________________________ 65) The types may have different cv-qualifiers, subject to the overall restriction that a reinterpret_cast cannot cast away constness. 66) T1 and T2 may have different cv-qualifiers, subject to the overall restriction that a reinterpret_cast cannot cast away constness. copy is made, and constructors (_class.ctor_) or conversion functions (_class.conv_) are not called.67) 5.2.11 Const cast [expr.const.cast] 1 The result of the expression const_cast(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 (_conv.lval_), array-to-pointer (_conv.array_), and function-to-pointer (_conv.func_) standard conver- sions 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 0sfont]I]ize]u'TR]1R]is2]cvR]1R]pointer to2]cvR]1R]pointer to2]R].R].R].cvR]1R]R]pointer]to2]cvR]1T0rfont] and 0sfont]I]ize]u'TR]2R]is2]cvR]2R]pointer to2]cvR]2R]pointer to2]R].R].R].cvR]2R]R]pointer]to2]cvR]2T0rfont] where T is any object type or the void type and where cv1,k and cv2,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 (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 original object. 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 (_conv.qual_), 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 (_conv.ptr_) is converted to the null pointer value of the destination type. The null member pointer value (_conv.mem_) is converted to the null member pointer value of the des- tination 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 _________________________ 67) This is sometimes referred to as a type pun. behavior (_dcl.type.cv_). ] 8 The following rules define the process known as casting away const- ness. In these rules Tn and Xn represent types. For two pointer types: 0sfont]I]ize]u'CW]XCW]12]R]is2]CW]TCW]12]cvR]1R]*R].R].R].cvR]1R]*R]whereTR]1isnotapointertype2]0rfont] 0sfont]I]ize]u'CW]XCW]22]R]is2]CW]TCW]22]cvR]2R]*R].R].R].cvR]2R]*R]whereTR]2isnotapointertype2]0rfont] 0sfont]I]ize]u'KR]is2]minR](NR],MR])0rfont] casting from X1 to X2 casts away constness if, for a non-pointer type T there does not exist an implicit conversion (clause _conv_) from: 0sfont]I]ize]u'TcvR]1R],R](R]*cvR]1R],R](R]*R].R].R].cvR]1R]*0rfont] to 0sfont]I]ize]u'TcvR]2R],R](R]*cvR]2R],R](R]*R].R].R].cvR]2R]*0rfont] 9 Casting from an lvalue of type T1 to an lvalue of type T2 using a ref- erence cast casts away constness if a cast from an rvalue of type "pointer to T1" to the type "pointer to T2" casts away constness. 10Casting from an rvalue of type "pointer to data member of X of type T1" to the type "pointer to data member of Y of type T2" casts away constness if a cast from an rvalue of type "pointer to T1" to the type "pointer to T2" casts away constness. 11For multi-level pointer to members and multi-level mixed pointers and pointer to members (_conv.qual_), 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. ] 5.3 Unary expressions [expr.unary] 1 Expressions with unary operators group right-to-left. _________________________ 68) const_cast is not limited to conversions that cast away a const- qualifier. 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 expres- sion is "pointer to T," the type of the result is "T." [Note: a pointer to an incomplete type (other than cv void ) can be derefer- enced. The lvalue thus obtained can be used in limited ways (to ini- tialize a reference, for example); this lvalue must not be converted to an rvalue, see _conv.lval_. ] 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 non- static data member (_dcl.stc_) 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 mem- ber." Neither does qualified-id, because there is no implicit conver- sion from a qualified-id for a nonstatic member function to the type "pointer to member function" as there is from an lvalue of function type to the type "pointer to function" (_conv.func_). Nor is &unqual- ified-id a pointer to member, even within the scope of the unquali- fied-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 _over_) can be taken only in a context that uniquely determines which version of the over- loaded function is referred to (see _over.over_). [Note: since the context might determine whether the operand is a static or nonstatic member function, the context can also affect whether the expression has type "pointer to function" or "pointer to member function." ] 6 The operand of the unary + operator shall have arithmetic, enumera- tion, 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. 7 The operand of the unary - operator shall have arithmetic or enumera- tion type and the result is the negation of its operand. Integral promotion is performed on integral or enumeration operands. The nega- tive of an unsigned quantity is computed by subtracting its value from 2n, where n is the number of bits in the promoted operand. The type of the result is the type of the promoted operand. 8 The operand of the logical negation operator ! is implicitly con- verted to bool (clause _conv_); 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 per- formed. 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 (_expr.add_) and assignment operators (_expr.ass_) for infor- mation 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 _expr.post.incr_. ] 5.3.3 Sizeof [expr.sizeof] 1 The sizeof operator yields the number of bytes in the object represen- tation 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 (_basic.fundamental_) is implementation-defined. [Note: in particular, sizeof(bool) and sizeof(wchar_t) are implementation-defined.69) ] [Note: See _intro.memory_ for the defini- tion of byte and _basic.types_ for the definition of object represen- tation. ] 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 (_intro.object_). 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 function. 4 The lvalue-to-rvalue (_conv.lval_), array-to-pointer (_conv.array_), and function-to-pointer (_conv.func_) 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 (_lib.support.types_). ] 5.3.4 New [expr.new] 1 The new-expression attempts to create an object of the type-id (_dcl.name_) 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 (_intro.object_, _basic.types_, _class.abstract_). [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 ) _________________________ 69) sizeof(bool) is not required to be 1. 70) The actual size of a base class subobject may be less than the re- sult of applying sizeof to the subobject, due to virtual base classes and less strict padding requirements on base class subobjects. 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 (_basic.stc.dynamic_). [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 prevents ambiguities between declara- tor operators &, *, [], and their expression counterparts. ] [Exam- ple: 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 sur- prising 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 (_basic.compound_): 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 enu- meration 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 ele- ment (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]. ] 6 Every constant-expression in a direct-new-declarator shall be an inte- gral constant expression (_expr.const_) and evaluate to a strictly positive value. The expression in a direct-new-declarator shall have integral type (_basic.fundamental_) with a non-negative value. [Exam- ple: 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-expres- sion). 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 allocate an array with no ele- ments. 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 alloca- tion function (_basic.stc.dynamic.allocation_). If the new-expression terminates by throwing an exception, it may release storage by calling a deallocation function (_basic.stc.dynamic.deallocation_). If the allocated type is a non-array type, the allocation function's name is operator new and the deallocation function's name is operator delete. If the allocated type is an array type, the allocation function's name is operator new[] and the deallocation function's name is operator delete[]. [Note: an implementation shall provide default definitions for the global allocation functions (_basic.stc.dynamic_, _lib.new.delete.single_, _lib.new.delete.array_). A C++ program can provide alternative definitions of these functions (_lib.replace- ment.functions_) and/or class-specific versions (_class.free_). ] 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. 10A new-expression passes the amount of space requested to the alloca- tion function as the first argument of type std::size_t. That argu- ment 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 differ- ence 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 (_basic.types_) 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. ] 11The new-placement syntax is used to supply additional arguments to an allocation function. If used, overload resolution is performed on a function call created by assembling an argument list consisting of the amount of space requested (the first argument) and the expressions in the new-placement part of the new-expression (the second and succeed- ing 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 ref- erencing 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 excep- tion-specification (_except.spec_), throw(), it indicates failure to allocate storage by throwing a bad_alloc exception (clause _except_, _lib.bad.alloc_); it returns a non-null pointer otherwise. If the allocation function is declared with an empty exception-specification, 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. ] 15A 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 (_dcl.init_) 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 (_dcl.init_); --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 (_dcl.init_); --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 initialized to the (possibly converted) value of the expression (_dcl.init_); --Otherwise the new-expression is ill-formed. 16If 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 (_class.free_), and the construc- tor (_class.ctor_). If the new expression creates an array of objects of class type, access and ambiguity control are done for the destruc- tor (_class.dtor_). 17If 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 appro- priate when the called allocation function does not allocate memory; otherwise, it is likely to result in a memory leak. ] 18If the new-expression begins with a unary :: operator, the dealloca- tion 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 deallo- cation 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. 19A declaration of a placement deallocation function matches the decla- ration of a placement allocation function if it has the same number of parameters and, after parameter transformations (_dcl.fct_), 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 func- tion will be called; otherwise, no deallocation function will be called. 20If a new-expression calls a deallocation function, it passes the value returned from the allocation function call as the first argument of _________________________ 71) This may include evaluating a new-initializer and/or calling a constructor. 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 argument as part of the call to the allocation function, it is allowed to make a copy (of the same original value) as part of the call to the deallocation function or to reuse the copy made as part of the call to the allocation function. If the copy is elided in one place, it need not be elided in the other. 21Whether the allocation function is called before evaluating the con- structor arguments or after evaluating the constructor arguments but before entering the constructor is unspecified. It is also unspeci- fied whether the arguments to a constructor are evaluated if the allo- cation 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 (_intro.object_) 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 (_class.conv.fct_) 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 con- verted 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 (_intro.object_) representing a base class of such an object (clause _class.derived_). 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 (_expr.const.cast_) 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 _________________________ 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. 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 (_basic.stc.dynamic.deallocation_), 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 indeterminate. ] 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 _class.base.init_). 7 The delete-expression will call a deallocation function (_basic.stc.dynamic.deallocation_). 8 [Note: An implementation provides default definitions of the global deallocation functions operator delete() for non-arrays (_lib.new.delete.single_) and operator delete[]() for arrays (_lib.new.delete.array_). A C++ program can provide alternative defi- nitions of these functions (_lib.replacement.functions_), and/or class-specific versions (_class.free_). ] 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 func- tion and the destructor (_class.dtor_, _class.free_). 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 _basic.lval_. ] 2 An explicit type conversion can be expressed using functional notation (_expr.type.conv_), a type conversion operator (dynamic_cast, static_cast, reinterpret_cast, const_cast), or the cast notation. _________________________ 73) This implies that an object cannot be deleted using a pointer of type void* because there are no objects of type void. 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 (_class.conv_) is ill-formed. 5 The conversions performed by --a const_cast (_expr.const.cast_), --a static_cast (_expr.static.cast_), --a static_cast followed by a const_cast, --a reinterpret_cast (_expr.reinterpret.cast_), 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 interpretation 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 reinter- pret_cast interpretation is used is unspecified. 7 In addition to those conversions, the following static_cast and rein- terpret_cast operations (optionally followed by a const_cast opera- tion) may be performed using the cast notation of explicit type con- version, 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; --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 refer- ence, 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 _expr.ref_. [Note: it is not possible to use a pointer to member that refers to a mutable member to modify a const class object. For exam- ple, 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 (_conv.mem_), the behavior is undefined. 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 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 unde- fined; otherwise (a/b)*b + a%b is equal to a. If both operands are nonnegative then the remainder is nonnegative; 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 arith- metic conversions are performed for operands of arithmetic or enumera- tion type. additive-expression: multiplicative-expression additive-expression + multiplicative-expression additive-expression - multiplicative-expression For addition, either both operands shall have arithmetic or enumera- tion 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 ver- sions 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. _________________________ 74) According to work underway toward the revision of ISO C, the pre- ferred algorithm for integer division follows the rules defined in the ISO Fortran standard, ISO/IEC 1539:1991, in which the quotient is al- ways rounded toward zero. 3 The result of the binary + operator is the sum of the operands. The result of the binary - operator is the difference 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 subscripts 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 element 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 ele- ments. 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 header (_lib.support.types_). As with any other arithmetic overflow, if the result does not fit in the space provided, the behavior is undefined. In other words, if the expres- sions 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 ptrdiff_t. Moreover, if the expres- sion 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) _________________________ 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 charac- ter pointers is similarly divided by the size of the object originally 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 pro- moted left operand. The behavior is undefined if the right operand is negative, or greater than or equal to the length in bits of the pro- moted 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 quan- tity 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 ). ] 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 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), _________________________ 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 ele- ment" requirements. and >= (greater than or equal to) all yield false or true. The type of the result is bool. 2 The usual arithmetic conversions are performed on operands of arith- metic or enumeration type. Pointer conversions (_conv.ptr_) and qual- ification conversions (_conv.qual_) 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 con- stant, 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 (_conv.qual_) to the type of one of the operands, with a cv-qualifica- tion signature (_conv.qual_) 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 compared, 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 pq 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 pq, 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 (_class.access.spec_) 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 (_class.access.spec_) 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] 1 equality-expression: relational-expression equality-expression == relational-expression equality-expression != relational-expression 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>= <<= &= ^= |= 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 _conv_) 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 (_class.copy_, _over.ass_). 5 [Note: For class objects, assignment is not in general the same as initialization (_dcl.init_, _class.ctor_, _class.init_, _class.copy_). ] 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 refer- ence. 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 (_conv.lval_), array-to-pointer (_conv.array_), and function- to-pointer (_conv.func_) standard conversions are not applied to the left expression. All side effects (_intro.execution_) of the left expression, except for the destruction of temporaries (_class.tempo- rary_), 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 (_expr.call_) and lists of initializers (_dcl.init_) ] the comma operator as described in clause _expr_ 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 inte- gral or enumeration constant: as array bounds (_dcl.array_, _expr.new_), as case expressions (_stmt.switch_), as bit-field lengths (_class.bit_), as enumerator initializers (_dcl.enum_), as static mem- ber initializers (_class.static.data_), and as integral or enumeration non-type template arguments (_temp.arg_). constant-expression: conditional-expression An integral constant-expression can involve only literals (_lex.lit- eral_), enumerators, const variables or static data members of inte- gral or enumeration types initialized with constant expressions (_dcl.init_), non-type template parameters of integral or enumeration types, and sizeof expressions. Floating literals (_lex.fcon_) can appear only if they are cast to integral or enumeration types. Only type conversions to integral or enumeration 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 (_basic.start.init_). Such constant expressions shall evaluate to one of the following: --a null pointer value (_conv.ptr_), --a null member pointer value (_conv.mem_), --an arithmetic constant expression, --an address constant expression, --a reference constant expression, --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 (_lex.icon_), floating literals (_lex.fcon_), enumerators, character literals (_lex.ccon_) and sizeof expressions (_expr.sizeof_). Cast operators in an arithmetic constant expression shall only convert arithmetic 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 (_lex.string_), 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 (_conv.array_) or func- tion (_conv.func_) type. The subscripting operator [] and the class member access . and -> operators, the & and * unary operators, and pointer casts (except dynamic_casts, _expr.dynamic.cast_) 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 inte- gral constant expression. An expression that designates the address of a member or base class of a non-POD class object (clause _class_) is not an address constant expression (_class.cdtor_). Function calls shall not be used in an address constant expression, even if the func- tion 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 (_class.conv.fct_) and except dynamic_casts (_expr.dynamic.cast_)) can be used in the creation of a reference constant expression, but the value of an object shall not be accessed by the use of these opera- tors. If the subscripting operator is used, one of its operands shall be an integral constant expression. An lvalue expression that desig- nates a member or base class of a non-POD class object (clause _class_) is not a reference constant expression (_class.cdtor_). 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 (_expr.unary.op_), optionally preceded by a pointer to member cast (_expr.static.cast_). ______________________________________________________________________ 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 iden- tifier 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 defini- tion. 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 (_conv.lval_), array-to-pointer (_conv.array_), and func- tion-to-pointer (_conv.func_) 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 state- ment 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 compound statement and to supply a null body to an iteration statement such as a while statement (_stmt.while_). ] 6.3 Compound statement or block [stmt.block] 1 So that several statements can be used where one is expected, the com- pound statement (also, and equivalently, called "block") is provided. compound-statement: { statement-seqopt } statement-seq: statement statement-seq statement A compound statement defines a local scope (_basic.scope_). [Note: a declaration is a statement (_stmt.dcl_). ] 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 _stmt.stmt_, the term substatement refers to the contained statement or statements that appear in the syntax notation. The sub- statement in a selection-statement (both substatements, in the else form of the if statement) implicitly defines a local scope (_basic.scope_). If the substatement in a selection-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 substate- ment. [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 (_stmt.iter_). The declarator shall not specify a function or an array. The type-specifier-seq shall not con- tain 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 controlled by the condition. If the name is re-declared in the outer- most block of a substatement controlled by the condition, the declara- tion 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 converted 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 condition" 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 declara- tion. 6.4.1 The if statement [stmt.if] 1 If the condition (_stmt.select_) 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 sev- eral 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 enu- meration type exists (_class.conv_). If the condition is of class type, the condition is converted by calling that conversion function, and the result of the conversion is used in place of the original con- dition 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-expres- sion. The integral constant-expression (_expr.const_) is implicitly _________________________ 76) In other words, the else is associated with the nearest un-elsed if. 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 con- version 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 enclosing 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 state- ment following 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 exe- cuted. 6 case and default labels in themselves do not alter the flow of con- trol, which continues unimpeded across such labels. To exit from a switch, see break, _stmt.break_. [Note: usually, the substatement that is the subject of a switch is compound and case and default labels appear on the top-level statements contained within the (com- pound) substatement, but this is not required. Declarations can appear in the substatement 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. ] 2 The substatement in an iteration-statement implicitly defines a local scope (_basic.scope_) 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 _stmt.select_. --end note] 6.5.1 The while statement [stmt.while] 1 In the while statement the substatement is executed repeatedly until the value of the condition (_stmt.select_) becomes false. The test takes place before each execution of the substatement. 2 When the condition of a while statement is a declaration, the scope of the variable that is declared extends from its point of declaration (_basic.scope.pdecl_) to the end of the while statement. A while statement of the form while (T t = x) statement is equivalent to label: { // start of condition scope T t = x; if (t) { statement goto label; } } // end of condition scope The object created in a condition is destroyed and created with each iteration of the loop. [Example: struct A { int val; A(int i) : val(i) { } ~A() { } operator bool() { return val != 0; } }; int i = 1; while (A a = i) { //... i = 0; } In the while-loop, the constructor and destructor are each called twice, once for the condition that succeeds and once for the condition that fails. ] 6.5.2 The do statement [stmt.do] 1 The expression is implicitly converted to bool; if that is not possi- ble, the program is ill-formed. 2 In the do statement the substatement is executed repeatedly until the value of the expression becomes false. The test takes place after each execution of the statement. 6.5.3 The for statement [stmt.for] 1 The for statement for ( for-init-statement conditionopt ; expressionopt ) statement is equivalent to { for-init-statement while ( condition ) { statement expression ; } } except that names declared in the for-init-statement are in the same declarative-region as those declared in the condition, and except that a continue in statement (not enclosed in another iteration statement) will execute expression before re-evaluating condition. [Note: Thus the first statement specifies initialization for the loop; the condi- tion (_stmt.select_) specifies a test, made before each iteration, such that the loop is exited when the condition becomes false; the expression often specifies incrementing that is done after each itera- tion. ] 2 Either or both of the condition and the expression can be omitted. A missing condition makes the implied while clause equivalent to while(true). 3 If the for-init-statement is a declaration, the scope of the name(s) declared extends to the end of the for-statement. [Example: int i = 42; int a[10]; for (int i = 0; i < 10; i++) a[i] = i; int j = i; // j = 42 --end example] 6.6 Jump statements [stmt.jump] 1 Jump statements unconditionally transfer control. jump-statement: break ; continue ; return expressionopt ; goto identifier ; 2 On exit from a scope (however accomplished), destructors (_class.dtor_) are called for all constructed objects with automatic storage duration (_basic.stc.auto_) (named objects or temporaries) that are declared in that scope, in the reverse order of their decla- ration. Transfer out of a loop, out of a block, or back past an ini- tialized variable with automatic storage duration involves the destruction of variables with automatic storage duration that are in scope at the point transferred from but not at the point transferred to. (See _stmt.dcl_ for transfers into blocks). [Note: However, the program can be terminated (by calling exit() or abort()(_lib.sup- port.start.term_), for example) without destroying class objects with automatic storage duration. ] 6.6.1 The break statement [stmt.break] 1 The break statement shall occur only in an iteration-statement or a switch statement and causes termination of the smallest enclosing iteration-statement or switch statement; control passes to the state- ment following the terminated statement, if any. 6.6.2 The continue statement [stmt.cont] 1 The continue statement shall occur only in an iteration-statement and causes control to pass to the loop-continuation portion of the small- est enclosing iteration-statement, that is, to the end of the loop. More precisely, in each of the statements while (foo) { do { for (;;) { { { { // ... // ... // ... } } } contin: ; contin: ; contin: ; } } while (foo); } a continue not contained in an enclosed iteration statement is equiva- lent to goto contin. 6.6.3 The return statement [stmt.return] 1 A function returns to its caller by the return statement. 2 A return statement without an expression can be used only in functions that do not return a value, that is, a function with the return type void, a constructor (_class.ctor_), or a destructor (_class.dtor_). A return statement with an expression of non-void type can be used only in functions returning a value; the value of the expression is returned to the caller of the function. The expression is implicitly converted to the return type of the function in which it appears. A return statement can involve the construction and copy of a temporary object (_class.temporary_). Flowing off the end of a function is equivalent to a return with no value; this results in undefined behav- ior in a value-returning function. 3 A return statement with an expression of type "cv void" can be used only in functions with a return type of cv void; the expression is evaluated just before the function returns to its caller. 6.6.4 The goto statement [stmt.goto] 1 The goto statement unconditionally transfers control to the statement labeled by the identifier. The identifier shall be a label (_stmt.label_) located in the current function. 6.7 Declaration statement [stmt.dcl] 1 A declaration statement introduces one or more new identifiers into a block; it has the form declaration-statement: block-declaration If an identifier introduced by a declaration was previously declared in an outer block, the outer declaration is hidden for the remainder of the block, after which it resumes its force. 2 Variables with automatic storage duration (_basic.stc.auto_) are ini- tialized each time their declaration-statement is executed. Variables with automatic storage duration declared in the block are destroyed on exit from the block (_stmt.jump_). 3 It is possible to transfer into a block, but not in a way that bypasses declarations with initialization. A program that jumps77) from a point where a local variable with automatic storage duration is not in scope to a point where it is in scope is ill-formed unless the variable has POD type (_basic.types_) and is declared without an ini- tializer (_dcl.init_). [Example: void f() { // ... goto lx; // ill-formed: jump into scope of a // ... ly: X a = 1; // ... lx: goto ly; // OK, jump implies destructor // call for a followed by construction // again immediately following label ly } --end example] 4 The zero-initialization (_dcl.init_) of all local objects with static storage duration (_basic.stc.static_) is performed before any other initialization takes place. A local object of POD type (_basic.types_) with static storage duration initialized with con- stant-expressions is initialized before its block is first entered. An implementation is permitted to perform early initialization of other local objects with static storage duration under the same condi- tions that an implementation is permitted to statically initialize an object with static storage duration in namespace scope (_basic.start.init_). Otherwise such an object is initialized the first time control passes through its declaration; such an object is considered initialized upon the completion of its initialization. If the initialization exits by throwing an exception, the initialization is not complete, so it will be tried again the next time control enters the declaration. If control re-enters the declaration (recur- sively) while the object is being initialized, the behavior is unde- fined. [Example: _________________________ 77) The transfer from the condition of a switch statement to a case label is considered a jump in this respect. int foo(int i) { static int s = foo(2*i); // recursive call - undefined return i+1; } --end example] 5 The destructor for a local object with static storage duration will be executed if and only if the variable was constructed. [Note: _basic.start.term_ describes the order in which local objects with static storage duration are destroyed. ] 6.8 Ambiguity resolution [stmt.ambig] 1 There is an ambiguity in the grammar involving expression-statements and declarations: An expression-statement with a function-style explicit type conversion (_expr.type.conv_) as its leftmost subexpres- sion can be indistinguishable from a declaration where the first declarator starts with a (. In those cases the statement is a decla- ration. [Note: To disambiguate, the whole statement might have to be examined to determine if it is an expression-statement or a declara- tion. This disambiguates many examples. [Example: assuming T is a simple-type-specifier (_dcl.type_), T(a)->m = 7; // expression-statement T(a)++; // expression-statement T(a,5)<(cip); // cast needed to convert const int* to int* *ip = 4; // defined: *ip points to i, a non-const object const int* ciq = new const int (3); // initialized as required int* iq = const_cast(ciq); // cast required *iq = 4; // undefined: modifies a const object 6 For another example class X { public: mutable int i; int j; }; class Y { public: X x; Y(); }; const Y y; y.x.i++; // well-formed: mutable member can be modified y.x.j++; // ill-formed: const-qualified member modified Y* p = const_cast(&y); // cast away const-ness of y p->x.i = 99; // well-formed: mutable member can be modified p->x.j = 99; // undefined: modifies a const member --end example] 7 If an attempt is made to refer to an object defined with a volatile- qualified type through the use of an lvalue with a non-volatile-quali- fied type, the program behaviour is undefined. 8 [Note: volatile is a hint to the implementation to avoid aggressive optimization involving the object because the value of the object might be changed by means undetectable by an implementation. See _intro.execution_ for detailed semantics. In general, the semantics of volatile are intended to be the same in C++ as they are in C. ] 7.1.5.2 Simple type specifiers [dcl.type.simple] 1 The simple type specifiers are simple-type-specifier: ::opt nested-name-specifieropt type-name ::opt nested-name-specifier template template-id char wchar_t bool short int long signed unsigned float double void type-name: class-name enum-name typedef-name The simple-type-specifiers specify either a previously-declared user- defined type or one of the fundamental types (_basic.fundamental_). Table 7 summarizes the valid combinations of simple-type-specifiers and the types they specify. Table 7--simple-type-specifiers and the types they specify +-------------------+----------------------+ |Specifier(s) | Type | +-------------------+----------------------+ |type-name | the type named | |char | "char" | |unsigned char | "unsigned char" | |signed char | "signed char" | |bool | "bool" | |unsigned | "unsigned int" | |unsigned int | "unsigned int" | |signed | "int" | |signed int | "int" | |int | "int" | |unsigned short int | "unsigned short int" | |unsigned short | "unsigned short int" | |unsigned long int | "unsigned long int" | |unsigned long | "unsigned long int" | |signed long int | "long int" | |signed long | "long int" | |long int | "long int" | |long | "long int" | |signed short int | "short int" | |signed short | "short int" | |short int | "short int" | |short | "short int" | |wchar_t | "wchar_t" | |float | "float" | |double | "double" | |long double | "long double" | |void | "void" | +-------------------+----------------------+ When multiple simple-type-specifiers are allowed, they can be freely intermixed with other decl-specifiers in any order. It is implementa- tion-defined whether bit-fields and objects of char type are repre- sented as signed or unsigned quantities. The signed specifier forces char objects and bit-fields to be signed; it is redundant with other integral types. 7.1.5.3 Elaborated type specifiers [dcl.type.elab] 1 elaborated-type-specifier: class-key ::opt nested-name-specifieropt identifier enum ::opt nested-name-specifieropt identifier typename ::opt nested-name-specifier identifier typename ::opt nested-name-specifier templateopt template-id 2 If an elaborated-type-specifier is the sole constituent of a declara- tion, the declaration is ill-formed unless it is an explicit specialization (_temp.expl.spec_), an explicit instantiation (_temp.explicit_) or it has one of the following forms: class-key identifier ; friend class-key identifier ; friend class-key ::identifier ; friend class-key nested-name-specifier identifier ; 3 _basic.lookup.elab_ describes how name lookup proceeds for the identi- fier in an elaborated-type-specifier. If the identifier resolves to a class-name or enum-name, the elaborated-type-specifier introduces it into the declaration the same way a simple-type-specifier introduces its type-name. If the identifier resolves to a typedef-name or a tem- plate type-parameter, the elaborated-type-specifier is ill-formed. [Note: this implies that, within a class template with a template type-parameter T, the declaration friend class T; is ill-formed. ] If name lookup does not find a declaration for the name, the elaborated-type-specifier is ill-formed unless it is of the simple form class-key identifier in which case the identifier is declared as described in _basic.scope.pdecl_. 4 The class-key or enum keyword present in the elaborated-type-specifier shall agree in kind with the declaration to which the name in the elaborated-type-specifier refers. This rule also applies to the form of elaborated-type-specifier that declares a class-name or friend class since it can be construed as referring to the definition of the class. Thus, in any elaborated-type-specifier, the enum keyword shall be used to refer to an enumeration (_dcl.enum_), the union class-key shall be used to refer to a union (clause _class_), and either the class or struct class-key shall be used to refer to a class (clause _class_) declared using the class or struct class-key. 7.2 Enumeration declarations [dcl.enum] 1 An enumeration is a distinct type (_basic.fundamental_) with named constants. Its name becomes an enum-name, within its scope. enum-name: identifier enum-specifier: enum identifieropt { enumerator-listopt } enumerator-list: enumerator-definition enumerator-list , enumerator-definition enumerator-definition: enumerator enumerator = constant-expression enumerator: identifier The identifiers in an enumerator-list are declared as constants, and can appear wherever constants are required. An enumerator-definition with = gives the associated enumerator the value indicated by the con- stant-expression. The constant-expression shall be of integral or enumeration type. If the first enumerator has no initializer, the value of the corresponding constant is zero. An enumerator-definition without an initializer gives the enumerator the value obtained by increasing the value of the previous enumerator by one. 2 [Example: enum { a, b, c=0 }; enum { d, e, f=e+2 }; defines a, c, and d to be zero, b and e to be 1, and f to be 3. ] 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. ] 4 Each enumeration defines a type that is different from all other types. Following the closing brace of an enum-specifier, each enumer- ator has the type of its enumeration. Prior to the closing brace, the type of each enumerator is the type of its initializing value. If an initializer is specified for an enumerator, the initializing value has the same type as the expression. If no initializer is specified for the first enumerator, the type is an unspecified integral type. Oth- erwise the type is the same as the type of the initializing value of the preceding enumerator unless the incremented value is not repre- sentable in that type, in which case the type is an unspecified inte- gral type sufficient to contain the incremented value. 5 The underlying type of an enumeration is an integral type that can represent all the enumerator values defined in the enumeration. It is implementation-defined which integral type is used as the underlying type for an enumeration except that the underlying type shall not be larger than int unless the value of an enumerator cannot fit in an int or unsigned int. If the enumerator-list is empty, the underlying type is as if the enumeration had a single enumerator with value 0. The value of sizeof() applied to an enumeration type, an object of enumer- ation type, or an enumerator, is the value of sizeof() applied to the underlying type. 6 For an enumeration where emin is the smallest enumerator and emax is the largest, the values of the enumeration are the values of the underlying type in the range bmin to bmax, where bmin and bmax are, respectively, the smallest and largest values of the smallest bit- field that can store emin and emax.81) It is possible to define an enumeration that has values not defined by any of its enumerators. 7 Two enumeration types are layout-compatible if they have the same underlying type. _________________________ 81) On a two's-complement machine, bmax is the smallest value greater than or equal to max(abs(emin)-1,abs(emax)) of the form 2M-1; bmin is zero if emin is non-negative and -(bmax+1) otherwise. 8 The value of an enumerator or an object of an enumeration type is con- verted to an integer by integral promotion (_conv.prom_). [Example: enum color { red, yellow, green=20, blue }; color col = red; color* cp = &col; if (*cp == blue) // ... makes color a type describing various colors, and then declares col as an object of that type, and cp as a pointer to an object of that type. The possible values of an object of type color are red, yellow, green, blue; these values can be converted to the integral values 0, 1, 20, and 21. Since enumerations are distinct types, objects of type color can be assigned only values of type color. color c = 1; // error: type mismatch, // no conversion from int to color int i = yellow; // OK: yellow converted to integral value 1 // integral promotion --end example] 9 An expression of arithmetic or enumeration type can be converted to an enumeration type explicitly. The value is unchanged if it is in the range of enumeration values of the enumeration type; otherwise the resulting enumeration value is unspecified. 10The enum-name and each enumerator declared by an enum-specifier is declared in the scope that immediately contains the enum-specifier. These names obey the scope rules defined for all names in (_basic.scope_) and (_basic.lookup_). An enumerator declared in class scope can be referred to using the class member access operators ::, . (dot) and -> (arrow)), see _expr.ref_. [Example: class X { public: enum direction { left='l', right='r' }; int f(int i) { return i==left ? 0 : i==right ? 1 : 2; } }; void g(X* p) { direction d; // error: direction not in scope int i; i = p->f(left); // error: left not in scope i = p->f(X::right); // OK i = p->f(p->left); // OK // ... } --end example] 7.3 Namespaces [basic.namespace] 1 A namespace is an optionally-named declarative region. The name of a namespace can be used to access entities declared in that namespace; that is, the members of the namespace. Unlike other declarative regions, the definition of a namespace can be split over several parts of one or more translation units. 2 A name declared outside all named namespaces, blocks (_stmt.block_) and classes (clause _class_) has global namespace scope (_basic.scope.namespace_). 7.3.1 Namespace definition [namespace.def] 1 The grammar for a namespace-definition is namespace-name: original-namespace-name namespace-alias original-namespace-name: identifier namespace-definition: named-namespace-definition unnamed-namespace-definition named-namespace-definition: original-namespace-definition extension-namespace-definition original-namespace-definition: namespace identifier { namespace-body } extension-namespace-definition: namespace original-namespace-name { namespace-body } unnamed-namespace-definition: namespace { namespace-body } namespace-body: declaration-seqopt 2 The identifier in an original-namespace-definition shall not have been previously defined in the declarative region in which the original- namespace-definition appears. The identifier in an original-names- pace-definition is the name of the namespace. Subsequently in that declarative region, it is treated as an original-namespace-name. 3 The original-namespace-name in an extension-namespace-definition shall have previously been defined in an original-namespace-definition in the same declarative region. 4 Every namespace-definition shall appear in the global scope or in a namespace scope (_basic.scope.namespace_). 5 Because a namespace-definition contains declarations in its namespace- body and a namespace-definition is itself a declaration, it follows that namespace-definitions can be nested. [Example: namespace Outer { int i; namespace Inner { void f() { i++; } // Outer::i int i; void g() { i++; } // Inner::i } } --end example] 7.3.1.1 Unnamed namespaces [namespace.unnamed] 1 An unnamed-namespace-definition behaves as if it were replaced by namespace unique { /* empty body */ } using namespace unique; namespace unique { namespace-body } where all occurrences of unique in a translation unit are replaced by the same identifier and this identifier differs from all other identi- fiers in the entire program.82) [Example: namespace { int i; } // unique::i void f() { i++; } // unique::i++ namespace A { namespace { int i; // A::unique::i int j; // A::unique::j } void g() { i++; } // A::unique::i++ } using namespace A; void h() { i++; // error: unique::i or A::unique::i A::i++; // A::unique::i j++; // A::unique::j } --end example] 2 The use of the static keyword is deprecated when declaring objects in a namespace scope (see annex _depr_); the unnamed-namespace provides a superior alternative. 7.3.1.2 Namespace member definitions [namespace.memdef] 1 Members of a namespace can be defined within that namespace. [Exam- ple: namespace X { void f() { /* ... */ } } _________________________ 82) Although entities in an unnamed namespace might have external linkage, they are effectively qualified by a name unique to their translation unit and therefore can never be seen from any other trans- lation unit. --end example] 2 Members of a named namespace can also be defined outside that names- pace by explicit qualification (_namespace.qual_) of the name being defined, provided that the entity being defined was already declared in the namespace and the definition appears after the point of decla- ration in a namespace that encloses the declaration's namespace. [Example: namespace Q { namespace V { void f(); } void V::f() { /* ... */ } // OK void V::g() { /* ... */ } // error: g() is not yet a member of V namespace V { void g(); } } namespace R { void Q::V::g() { /* ... */ } // error: R doesn't enclose Q } --end example] 3 Every name first declared in a namespace is a member of that names- pace. If a friend declaration in a non-local class first declares a class or function83) the friend class or function is a member of the innermost enclosing namespace. The name of the friend is not found by simple name lookup until a matching declaration is provided in that namespace scope (either before or after the class declaration granting friendship). If a friend function is called, its name may be found by the name lookup that considers functions from namespaces and classes associated with the types of the function arguments (_basic.lookup.koenig_). When looking for a prior declaration of a class or a function declared as a friend, scopes outside the innermost enclosing namespace scope are not considered. [Example: _________________________ 83) this implies that the name of the class or function is unquali- fied. // Assume f and g have not yet been defined. void h(int); namespace A { class X { friend void f(X); // A::f is a friend class Y { friend void g(); // A::g is a friend friend void h(int); // A::h is a friend // ::h not considered }; }; // A::f, A::g and A::h are not visible here X x; void g() { f(x); } // definition of A::g void f(X) { /* ... */} // definition of A::f void h(int) { /* ... */ } // definition of A::h // A::f, A::g and A::h are visible here and known to be friends } using A::x; void h() { A::f(x); A::X::f(x); // error: f is not a member of A::X A::X::Y::g(); // error: g is not a member of A::X::Y } --end example] 7.3.2 Namespace alias [namespace.alias] 1 A namespace-alias-definition declares an alternate name for a names- pace according to the following grammar: namespace-alias: identifier namespace-alias-definition: namespace identifier = qualified-namespace-specifier ; qualified-namespace-specifier: ::opt nested-name-specifieropt namespace-name 2 The identifier in a namespace-alias-definition is a synonym for the name of the namespace denoted by the qualified-namespace-specifier and becomes a namespace-alias. [Note: when looking up a namespace-name in a namespace-alias-definition, only namespace names are considered, see _basic.lookup.udir_. ] 3 In a declarative region, a namespace-alias-definition can be used to redefine a namespace-alias declared in that declarative region to refer only to the namespace to which it already refers. [Example: the following declarations are well-formed: namespace Company_with_very_long_name { /* ... */ } namespace CWVLN = Company_with_very_long_name; namespace CWVLN = Company_with_very_long_name; // OK: duplicate namespace CWVLN = CWVLN; --end example] 4 A namespace-name or namespace-alias shall not be declared as the name of any other entity in the same declarative region. A namespace-name defined at global scope shall not be declared as the name of any other entity in any global scope of the program. No diagnostic is required for a violation of this rule by declarations in different translation units. 7.3.3 The using declaration [namespace.udecl] 1 A using-declaration introduces a name into the declarative region in which the using-declaration appears. That name is a synonym for the name of some entity declared elsewhere. using-declaration: using typenameopt ::opt nested-name-specifier unqualified-id ; using :: unqualified-id ; 2 The member name specified in a using-declaration is declared in the declarative region in which the using-declaration appears. [Note: only the specified name is so declared; specifying an enumeration name in a using-declaration does not declare its enumerators in the using- declaration's declarative region. ] 3 Every using-declaration is a declaration and a member-declaration and so can be used in a class definition. [Example: struct B { void f(char); void g(char); enum E { e }; union { int x; }; }; struct D : B { using B::f; void f(int) { f('c'); } // calls B::f(char) void g(int) { g('c'); } // recursively calls D::g(int) }; --end example] 4 A using-declaration used as a member-declaration shall refer to a mem- ber of a base class of the class being defined, shall refer to a mem- ber of an anonymous union that is a member of a base class of the class being defined, or shall refer to an enumerator for an enumera- tion type that is a member of a base class of the class being defined. [Example: class C { int g(); }; class D2 : public B { using B::f; // OK: B is a base of D2 using B::e; // OK: e is an enumerator of base B using B::x; // OK: x is a union member of base B using C::g; // error: C isn't a base of D2 }; --end example] [Note: since constructors and destructors do not have names, a using-declaration cannot refer to a constructor or a destruc- tor for a base class. Since specializations of member templates for conversion functions are not found by name lookup, they are not con- sidered when a using-declaration specifies a conversion function (_temp.mem_). ] If an assignment operator brought from a base class into a derived class scope has the signature of a copy-assignment operator for the derived class (_class.copy_), the using-declaration does not by itself suppress the implicit declaration of the derived class copy-assignment operator; the copy-assignment operator from the base class is hidden or overridden by the implicitly-declared copy- assignment operator of the derived class, as described below. 5 A using-declaration shall not name a template-id. [Example: class A { public: template void f(T); template struct X { }; }; class B : public A { public: using A::f; // ill-formed using A::X; // ill-formed }; --end example] 6 A using-declaration for a class member shall be a member-declaration. [Example: struct X { int i; static int s; }; void f() { using X::i; // error: X::i is a class member // and this is not a member declaration. using X::s; // error: X::s is a class member // and this is not a member declaration. } --end example] 7 Members declared by a using-declaration can be referred to by explicit qualification just like other member names (_namespace.qual_). In a using-declaration, a prefix :: refers to the global namespace. [Exam- ple: void f(); namespace A { void g(); } namespace X { using ::f; // global f using A::g; // A's g } void h() { X::f(); // calls ::f X::g(); // calls A::g } --end example] 8 A using-declaration is a declaration and can therefore be used repeat- edly where (and only where) multiple declarations are allowed. [Exam- ple: namespace A { int i; } namespace A1 { using A::i; using A::i; // OK: double declaration } void f() { using A::i; using A::i; // error: double declaration } class B { public: int i; }; class X : public B { using B::i; using B::i; // error: double member declaration }; --end example] 9 The entity declared by a using-declaration shall be known in the con- text using it according to its definition at the point of the using- declaration. Definitions added to the namespace after the using-dec- laration are not considered when a use of the name is made. [Example: namespace A { void f(int); } using A::f; // f is a synonym for A::f; // that is, for A::f(int). namespace A { void f(char); } void foo() { f('a'); // calls f(int), } // even though f(char) exists. void bar() { using A::f; // f is a synonym for A::f; // that is, for A::f(int) and A::f(char). f('a'); // calls f(char) } --end example] [Note: partial specializations of class templates are found by looking up the primary class template and then considering all partial specializations of that template. If a using-declaration names a class template, partial specializations introduced after the using-declaration are effectively visible because the primary template is visible (_temp.class.spec_). ] 10Since a using-declaration is a declaration, the restrictions on decla- rations of the same name in the same declarative region (_basic.scope_) also apply to using-declarations. [Example: namespace A { int x; } namespace B { int i; struct g { }; struct x { }; void f(int); void f(double); void g(char); // OK: hides struct g } void func() { int i; using B::i; // error: i declared twice void f(char); using B::f; // OK: each f is a function f(3.5); // calls B::f(double) using B::g; g('a'); // calls B::g(char) struct g g1; // g1 has class type B::g using B::x; using A::x; // OK: hides struct B::x x = 99; // assigns to A::x struct x x1; // x1 has class type B::x } --end example] 11If a function declaration in namespace scope or block scope has the same name and the same parameter types as a function introduced by a using-declaration, the program is ill-formed. [Note: two using-decla- rations may introduce functions with the same name and the same param- eter types. If, for a call to an unqualified function name, function overload resolution selects the functions introduced by such using- declarations, the function call is ill-formed. [Example: namespace B { void f(int); void f(double); } namespace C { void f(int); void f(double); void f(char); } void h() { using B::f; // B::f(int) and B::f(double) using C::f; // C::f(int), C::f(double), and C::f(char) f('h'); // calls C::f(char) f(1); // error: ambiguous: B::f(int) or C::f(int) ? void f(int); // error: // f(int) conflicts with C::f(int) and B::f(int) } --end example] ] 12When a using-declaration brings names from a base class into a derived class scope, member functions in the derived class override and/or hide member functions with the same name and parameter types in a base class (rather than conflicting). [Example: struct B { virtual void f(int); virtual void f(char); void g(int); void h(int); }; struct D : B { using B::f; void f(int); // OK: D::f(int) overrides B::f(int); using B::g; void g(char); // OK using B::h; void h(int); // OK: D::h(int) hides B::h(int) }; void k(D* p) { p->f(1); // calls D::f(int) p->f('a'); // calls B::f(char) p->g(1); // calls B::g(int) p->g('a'); // calls D::g(char) } --end example] [Note: two using-declarations may introduce functions with the same name and the same parameter types. If, for a call to an unqualified function name, function overload resolution selects the functions introduced by such using-declarations, the function call is ill-formed. ] 13For the purpose of overload resolution, the functions which are intro- duced by a using-declaration into a derived class will be treated as though they were members of the derived class. In particular, the implicit this parameter shall be treated as if it were a pointer to the derived class rather than to the base class. This has no effect on the type of the function, and in all other respects the function remains a member of the base class. 14All instances of the name mentioned in a using-declaration shall be accessible. In particular, if a derived class uses a using-declara- tion to access a member of a base class, the member name shall be accessible. If the name is that of an overloaded member function, then all functions named shall be accessible. The base class members mentioned by a using-declaration shall be visible in the scope of at least one of the direct base classes of the class where the using-dec- laration is specified. [Note: because a using-declaration designates a base class member (and not a member subobject or a member function of a base class subobject), a using-declaration cannot be used to resolve inherited member ambiguities. For example, struct A { int x(); }; struct B : A { }; struct C : A { using A::x; int x(int); }; struct D : B, C { using C::x; int x(double); }; int f(D* d) { return d->x(); // ambiguous: B::x or C::x } ] 15The alias created by the using-declaration has the usual accessibility for a member-declaration. [Example: class A { private: void f(char); public: void f(int); protected: void g(); }; class B : public A { using A::f; // error: A::f(char) is inaccessible public: using A::g; // B::g is a public synonym for A::g }; --end example] 16[Note: use of access-declarations (_class.access.dcl_) is deprecated; member using-declarations provide a better alternative. ] 7.3.4 Using directive [namespace.udir] 1 using-directive: using namespace ::opt nested-name-specifieropt namespace-name ; A using-directive shall not appear in class scope, but may appear in namespace scope or in block scope. [Note: when looking up a names- pace-name in a using-directive, only namespace names are considered, see _basic.lookup.udir_. ] 2 A using-directive specifies that the names in the nominated namespace can be used in the scope in which the using-directive appears after the using-directive. During unqualified name lookup (_basic.lookup.unqual_), the names appear as if they were declared in the nearest enclosing namespace which contains both the using-direc- tive and the nominated namespace. [Note: in this context, "contains" means "contains directly or indirectly". ] A using-directive does not add any members to the declarative region in which it appears. [Exam- ple: namespace A { int i; namespace B { namespace C { int i; } using namespace A::B::C; void f1() { i = 5; // OK, C::i visible in B and hides A::i } } namespace D { using namespace B; using namespace C; void f2() { i = 5; // ambiguous, B::C::i or A::i? } } void f3() { i = 5; // uses A::i } } void f4() { i = 5; // ill-formed; neither i is visible } ] 3 The using-directive is transitive: if a scope contains a using-direc- tive that nominates a second namespace that itself contains using- directives, the effect is as if the using-directives from the second namespace also appeared in the first. [Example: namespace M { int i; } namespace N { int i; using namespace M; } void f() { using namespace N; i = 7; // error: both M::i and N::i are visible } For another example, namespace A { int i; } namespace B { int i; int j; namespace C { namespace D { using namespace A; int j; int k; int a = i; // B::i hides A::i } using namespace D; int k = 89; // no problem yet int l = k; // ambiguous: C::k or D::k int m = i; // B::i hides A::i int n = j; // D::j hides B::j } } --end example] 4 If a namespace is extended by an extended-namespace-definition after a using-directive for that namespace is given, the additional members of the extended namespace and the members of namespaces nominated by using-directives in the extended-namespace-definition can be used after the extended-namespace-definition. 5 If name lookup finds a declaration for a name in two different names- paces, and the declarations do not declare the same entity and do not declare functions, the use of the name is ill-formed. [Note: in par- ticular, the name of an object, function or enumerator does not hide the name of a class or enumeration declared in a different namespace. For example, namespace A { class X { }; extern "C" int g(); extern "C++" int h(); } namespace B { void X(int); extern "C" int g(); extern "C++" int h(); } using namespace A; using namespace B; void f() { X(1); // error: name X found in two namespaces g(); // okay: name g refers to the same entity h(); // error: name h found in two namespaces } --end note] 6 During overload resolution, all functions from the transitive search are considered for argument matching. The set of declarations found by the transitive search is unordered. [Note: in particular, the order in which namespaces were considered and the relationships among the namespaces implied by the using-directives do not cause preference to be given to any of the declarations found by the search. ] An ambiguity exists if the best match finds two functions with the same signature, even if one is in a namespace reachable through using- directives in the namespace of the other.84) [Example: namespace D { int d1; void f(char); } using namespace D; int d1; // OK: no conflict with D::d1 namespace E { int e; void f(int); } namespace D { // namespace extension int d2; using namespace E; void f(int); } _________________________ 84) During name lookup in a class hierarchy, some ambiguities may be resolved by considering whether one member hides the other along some paths (_class.member.lookup_). There is no such disambiguation when considering the set of names found as a result of following using-di- rectives. void f() { d1++; // error: ambiguous ::d1 or D::d1? ::d1++; // OK D::d1++; // OK d2++; // OK: D::d2 e++; // OK: E::e f(1); // error: ambiguous: D::f(int) or E::f(int)? f('a'); // OK: D::f(char) } --end example] 7.4 The asm declaration [dcl.asm] 1 An asm declaration has the form asm-definition: asm ( string-literal ) ; The meaning of an asm declaration is implementation-defined. [Note: Typically it is used to pass information through the implementation to an assembler. ] 7.5 Linkage specifications [dcl.link] 1 All function types, function names, and variable names have a language linkage. [Note: Some of the properties associated with an entity with language linkage are specific to each implementation and are not described here. For example, a particular language linkage may be associated with a particular form of representing names of objects and functions with external linkage, or with a particular calling conven- tion, etc. ] The default language linkage of all function types, function names, and variable names is C++ language linkage. Two func- tion types with different language linkages are distinct types even if they are otherwise identical. 2 Linkage (_basic.link_) between C++ and non-C++ code fragments can be achieved using a linkage-specification: linkage-specification: extern string-literal { declaration-seqopt } extern string-literal declaration The string-literal indicates the required language linkage. The mean- ing of the string-literal is implementation-defined. A linkage-speci- fication with a string that is unknown to the implementation is ill- formed. When the string-literal in a linkage-specification names a programming language, the spelling of the programming language's name is implementation-defined. [Note: it is recommended that the spelling be taken from the document defining that language, for example Ada (not ADA) and Fortran or FORTRAN (depending on the vintage). The semantics of a language linkage other than C++ or C are implementa- tion-defined. ] 3 Every implementation shall provide for linkage to functions written in the C programming language, "C", and linkage to C++ functions, "C++". [Example: complex sqrt(complex); // C++ linkage by default extern "C" { double sqrt(double); // C linkage } --end example] 4 Linkage specifications nest. When linkage specifications nest, the innermost one determines the language linkage. A linkage specifica- tion does not establish a scope. A linkage-specification shall occur only in namespace scope (_basic.scope_). In a linkage-specification, the specified language linkage applies to the function types of all function declarators, function names, and variable names introduced by the declaration(s). [Example: extern "C" void f1(void(*pf)(int)); // the name f1 and its function type have C language // linkage; pf is a pointer to a C function extern "C" typedef void FUNC(); FUNC f2; // the name f2 has C++ language linkage and the // function's type has C language linkage extern "C" FUNC f3; // the name of function f3 and the function's type // have C language linkage void (*pf2)(FUNC*); // the name of the variable pf2 has C++ linkage and // the type of pf2 is pointer to C++ function that // takes one parameter of type pointer to C function --end example] A C language linkage is ignored for the names of class members and the member function type of class member functions. [Example: extern "C" typedef void FUNC_c(); class C { void mf1(FUNC_c*); // the name of the function mf1 and the member // function's type have C++ language linkage; the // parameter has type pointer to C function FUNC_c mf2; // the name of the function mf2 and the member // function's type have C++ language linkage static FUNC_c* q; // the name of the data member q has C++ language // linkage and the data member's type is pointer to // C function }; extern "C" { class X { void mf(); // the name of the function mf and the member // function's type have C++ language linkage void mf2(void(*)()); // the name of the function mf2 has C++ language // linkage; the parameter has type pointer to // C function }; } --end example] 5 If two declarations of the same function or object specify different linkage-specifications (that is, the linkage-specifications of these declarations specify different string-literals), the program is ill- formed if the declarations appear in the same translation unit, and the one definition rule (_basic.def.odr_) applies if the declarations appear in different translation units. Except for functions with C++ linkage, a function declaration without a linkage specification shall not precede the first linkage specification for that function. A function can be declared without a linkage specification after an explicit linkage specification has been seen; the linkage explicitly specified in the earlier declaration is not affected by such a func- tion declaration. 6 At most one function with a particular name can have C language link- age. Two declarations for a function with C language linkage with the same function name (ignoring the namespace names that qualify it) that appear in different namespace scopes refer to the same function. Two declarations for an object with C language linkage with the same name (ignoring the namespace names that qualify it) that appear in differ- ent namespace scopes refer to the same object. [Note: because of the one definition rule (_basic.def.odr_), only one definition for a func- tion or object with C linkage may appear in the program; that is, such a function or object must not be defined in more than one namespace scope. For example, namespace A { extern "C" int f(); extern "C" int g() { return 1; } extern "C" int h(); } namespace B { extern "C" int f(); // A::f and B::f refer // to the same function extern "C" int g() { return 1; } // ill-formed, the function g // with C language linkage // has two definitions } int A::f() { return 98; } // definition for the function f // with C language linkage extern "C" int h() { return 97; } // definition for the function h // with C language linkage // A::h and ::h refer to the same function --end note] 7 Except for functions with internal linkage, a function first declared in a linkage-specification behaves as a function with external link- age. [Example: extern "C" double f(); static double f(); // error is ill-formed (_dcl.stc_). ] The form of linkage-specification that contains a braced-enclosed declaration-seq does not affect whether the contained declarations are definitions or not (_basic.def_); the form of linkage-specification directly containing a single declaration is treated as an extern specifier (_dcl.stc_) for the purpose of deter- mining whether the contained declaration is a definition. [Example: extern "C" int i; // declaration extern "C" { int i; // definition } --end example] A linkage-specification directly containing a single declaration shall not specify a storage class. [Example: extern "C" static void f(); // error --end example] 8 [Note: because the language linkage is part of a function type, when a pointer to C function (for example) is dereferenced, the function to which it refers is considered a C function. ] 9 Linkage from C++ to objects defined in other languages and to objects defined in C++ from other languages is implementation-defined and lan- guage-dependent. Only where the object layout strategies of two lan- guage implementations are similar enough can such linkage be achieved. ______________________________________________________________________ 8 Declarators [dcl.decl] ______________________________________________________________________ 1 A declarator declares a single object, function, or type, within a declaration. The init-declarator-list appearing in a declaration is a comma-separated sequence of declarators, each of which can have an initializer. init-declarator-list: init-declarator init-declarator-list , init-declarator init-declarator: declarator initializeropt 2 The two components of a declaration are the specifiers decl-specifier- seq; _dcl.spec_) and the declarators init-declarator-list). The spec- ifiers indicate the type, storage class or other properties of the objects, functions or typedefs being declared. The declarators spec- ify the names of these objects, functions or typedefs, and (option- ally) modify the type of the specifiers with operators such as * (pointer to) and () (function returning). Initial values can also be specified in a declarator; initializers are discussed in _dcl.init_ and _class.init_. 3 Each init-declarator in a declaration is analyzed separately as if it was in a declaration by itself.85) _________________________ 85) A declaration with several declarators is usually equivalent to the corresponding sequence of declarations each with a single declara- tor. That is T D1, D2, ... Dn; is usually equvalent to T D1; T D2; ... T Dn; where T is a decl-specifier-seq and each Di is a init-declarator. The exception occurs when a name introduced by one of the declarators hides a type name used by the dcl-specifiers, so that when the same dcl-specifiers are used in a subsequent declaration, they do not have the same meaning, as in struct S { ... }; S S, T; // declare two instances of struct S which is not equivalent to struct S { ... }; S S; S T; // error 4 Declarators have the syntax declarator: direct-declarator ptr-operator declarator direct-declarator: declarator-id direct-declarator ( parameter-declaration-clause ) cv-qualifier-seqopt exception-specificationopt direct-declarator [ constant-expressionopt ] ( declarator ) ptr-operator: * cv-qualifier-seqopt & ::opt nested-name-specifier * cv-qualifier-seqopt cv-qualifier-seq: cv-qualifier cv-qualifier-seqopt cv-qualifier: const volatile declarator-id: id-expression ::opt nested-name-specifieropt type-name A class-name has special meaning in a declaration of the class of that name and when qualified by that name using the scope resolution opera- tor :: (_expr.prim_, _class.ctor_, _class.dtor_). 8.1 Type names [dcl.name] 1 To specify type conversions explicitly, and as an argument of sizeof, new, or typeid, the name of a type shall be specified. This can be done with a type-id, which is syntactically a declaration for an object or function of that type that omits the name of the object or function. type-id: type-specifier-seq abstract-declaratoropt type-specifier-seq: type-specifier type-specifier-seqopt abstract-declarator: ptr-operator abstract-declaratoropt direct-abstract-declarator direct-abstract-declarator: direct-abstract-declaratoropt ( parameter-declaration-clause ) cv-qualifier-seqopt exception-specificationopt direct-abstract-declaratoropt [ constant-expressionopt ] ( abstract-declarator ) It is possible to identify uniquely the location in the abstract- declarator where the identifier would appear if the construction were a declarator in a declaration. The named type is then the same as the type of the hypothetical identifier. [Example: int // int i int * // int *pi int *[3] // int *p[3] int (*)[3] // int (*p3i)[3] int *() // int *f() int (*)(double) // int (*pf)(double) name respectively the types int," "pointer to int," "array of 3 point- ers to int," "pointer to array of 3 int," "function of (no parameters) returning pointer to int," and "pointer to a function of double) returning int.'' ] 2 A type can also be named (often more easily) by using a typedef (_dcl.typedef_). 8.2 Ambiguity resolution [dcl.ambig.res] 1 The ambiguity arising from the similarity between a function-style cast and a declaration mentioned in _stmt.ambig_ can also occur in the context of a declaration. In that context, the choice is between a function declaration with a redundant set of parentheses around a parameter name and an object declaration with a function-style cast as the initializer. Just as for the ambiguities mentioned in _stmt.ambig_, the resolution is to consider any construct that could possibly be a declaration a declaration. [Note: a declaration can be explicitly disambiguated by a nonfunction-style cast, by a = to indi- cate initialization or by removing the redundant parentheses around the parameter name. ] [Example: struct S { S(int); }; void foo(double a) { S w(int(a)); // function declaration S x(int()); // function declaration S y((int)a); // object declaration S z = int(a); // object declaration } --end example] 2 The ambiguity arising from the similarity between a function-style cast and a type-id can occur in different contexts. The ambiguity appears as a choice between a function-style cast expression and a declaration of a type. The resolution is that any construct that could possibly be a type-id in its syntactic context shall be consid- ered a type-id. 3 [Example: #include char *p; void *operator new(size_t, int); void foo() { const int x = 63; new (int(*p)) int; // new-placement expression new (int(*[x])); // new type-id } 4 For another example, template struct S { T *p; }; S x; // type-id S y; // expression (ill-formed) 5 For another example, void foo() { sizeof(int(1)); // expression sizeof(int()); // type-id (ill-formed) } 6 For another example, void foo() { (int(1)); // expression (int())1; // type-id (ill-formed) } --end example] 7 Another ambiguity arises in a parameter-declaration-clause of a func- tion declaration, or in a type-id that is the operand of a sizeof or typeid operator, when a type-name is nested in parentheses. In this case, the choice is between the declaration of a parameter of type pointer to function and the declaration of a parameter with redundant parentheses around the declarator-id. The resolution is to consider the type-name as a simple-type-specifier rather than a declarator-id. [Example: class C { }; void f(int(C)) { } // void f(int (*fp)(C c)) { } // not: void f(int C); int g(C); void foo() { f(1); // error: cannot convert 1 to function pointer f(g); // OK } For another example, class C { }; void h(int *(C[10])); // void h(int *(*_fp)(C _parm[10])); // not: void h(int *C[10]); --end example] 8.3 Meaning of declarators [dcl.meaning] 1 A list of declarators appears after an optional (clause _dcl.dcl_) decl-specifier-seq (_dcl.spec_). Each declarator contains exactly one declarator-id; it names the identifier that is declared. The id- expression of a declarator-id shall be a simple identifier except for the declaration of some special functions (_class.conv_, _class.dtor_, _over.oper_) and for the declaration of template specializations or partial specializations (_temp.spec_). A declarator-id shall not be qualified except for the definition of a member function (_class.mfct_) or static data member (_class.static_) or nested class (_class.nest_) outside of its class, the definition or explicit instantiation of a function, variable or class member of a namespace outside of its namespace, or the definition of a previously declared explicit specialization outside of its namespace, or the declaration of a friend function that is a member of another class or namespace (_class.friend_). When the declarator-id is qualified, the declara- tion shall refer to a previously declared member of the class or namespace to which the qualifier refers, and the member shall not have been introduced by a using-declaration in the scope of the class or namespace nominated by the nested-name-specifier of the declarator-id. [Note: if the qualifier is the global :: scope resolution operator, the declarator-id refers to a name declared in the global namespace scope. ] In the qualified declarator-id for a class or namespace mem- ber definition that appears outside of the member's class or names- pace, the nested-name-specifier shall not name any of the namespaces that enclose the member's definition. [Example: namespace A { struct B { void f(); }; void A::B::f() { } // ill-formed: the declarator must not be // qualified with A:: } --end example] 2 An auto, static, extern, register, mutable, friend, inline, virtual, or typedef specifier applies directly to each declarator-id in a init- declarator-list; the type specified for each declarator-id depends on both the decl-specifier-seq and its declarator. 3 Thus, a declaration of a particular identifier has the form T D where T is a decl-specifier-seq and D is a declarator. Following is a recursive procedure for determining the type specified for the con- tained declarator-id by such a declaration. 4 First, the decl-specifier-seq determines a type. In a declaration T D the decl-specifier-seq T determines the type T." [Example: in the declaration int unsigned i; the type specifiers int unsigned determine the type unsigned int" (_dcl.type.simple_). ] 5 In a declaration T D where D is an unadorned identifier the type of this identifier is T." 6 In a declaration T D where D has the form ( D1 ) the type of the contained declarator-id is the same as that of the contained declarator-id in the declaration T D1 Parentheses do not alter the type of the embedded declarator-id, but they can alter the binding of complex declarators. 8.3.1 Pointers [dcl.ptr] 1 In a declaration T D where D has the form * cv-qualifier-seqopt D1 and the type of the identifier in the declaration T D1 is "derived- declarator-type-list T," then the type of the identifier of D is "derived-declarator-type-list cv-qualifier-seq pointer to T." The cv- qualifiers apply to the pointer and not to the object pointed to. 2 [Example: the declarations const int ci = 10, *pc = &ci, *const cpc = pc, **ppc; int i, *p, *const cp = &i; declare ci, a constant integer; pc, a pointer to a constant integer; cpc, a constant pointer to a constant integer, ppc, a pointer to a pointer to a constant integer; i, an integer; p, a pointer to integer; and cp, a constant pointer to integer. The value of ci, cpc, and cp cannot be changed after initialization. The value of pc can be changed, and so can the object pointed to by cp. Examples of some correct operations are i = ci; *cp = ci; pc++; pc = cpc; pc = p; ppc = &pc; Examples of ill-formed operations are ci = 1; // error ci++; // error *pc = 2; // error cp = &ci; // error cpc++; // error p = pc; // error ppc = &p; // error Each is unacceptable because it would either change the value of an object declared const or allow it to be changed through a cv-unquali- fied pointer later, for example: *ppc = &ci; // OK, but would make p point to ci ... // ... because of previous error *p = 5; // clobber ci --end example] 3 See also _expr.ass_ and _dcl.init_. 4 [Note: there are no pointers to references; see _dcl.ref_. Since the address of a bit-field (_class.bit_) cannot be taken, a pointer can never point to a bit-field. ] 8.3.2 References [dcl.ref] 1 In a declaration T D where D has the form & D1 and the type of the identifier in the declaration T D1 is "derived- declarator-type-list T," then the type of the identifier of D is "derived-declarator-type-list reference to T." Cv-qualified refer- ences are ill-formed except when the cv-qualifiers are introduced through the use of a typedef (_dcl.typedef_) or of a template type argument (_temp.arg_), in which case the cv-qualifiers are ignored. [Example: in typedef int& A; const A aref = 3; // ill-formed; // non-const reference initialized with rvalue the type of aref is "reference to int", not "const reference to int". ] [Note: a reference can be thought of as a name of an object. ] A declarator that specifies the type "reference to cv void" is ill- formed. 2 [Example: void f(double& a) { a += 3.14; } // ... double d = 0; f(d); declares a to be a reference parameter of f so the call f(d) will add 3.14 to d. int v[20]; // ... int& g(int i) { return v[i]; } // ... g(3) = 7; declares the function g() to return a reference to an integer so g(3)=7 will assign 7 to the fourth element of the array v. For another example, struct link { link* next; }; link* first; void h(link*& p) // p is a reference to pointer { p->next = first; first = p; p = 0; } void k() { link* q = new link; h(q); } declares p to be a reference to a pointer to link so h(q) will leave q with the value zero. See also _dcl.init.ref_. ] 3 It is unspecified whether or not a reference requires storage (_basic.stc_). 4 There shall be no references to references, no arrays of references, and no pointers to references. The declaration of a reference shall contain an initializer (_dcl.init.ref_) except when the declaration contains an explicit extern specifier (_dcl.stc_), is a class member (_class.mem_) declaration within a class declaration, or is the decla- ration of a parameter or a return type (_dcl.fct_); see _basic.def_. A reference shall be initialized to refer to a valid object or func- tion. [Note: in particular, a null reference cannot exist in a well- defined program, because the only way to create such a reference would be to bind it to the "object" obtained by dereferencing a null pointer, which causes undefined behavior. As described in _class.bit_, a reference cannot be bound directly to a bit-field. ] 8.3.3 Pointers to members [dcl.mptr] 1 In a declaration T D where D has the form ::opt nested-name-specifier * cv-qualifier-seqopt D1 and the nested-name-specifier names a class, and the type of the iden- tifier in the declaration T D1 is "derived-declarator-type-list T," then the type of the identifier of D is "derived-declarator-type-list cv-qualifier-seq pointer to member of class nested-name-specifier of type T." 2 [Example: class X { public: void f(int); int a; }; class Y; int X::* pmi = &X::a; void (X::* pmf)(int) = &X::f; double X::* pmd; char Y::* pmc; declares pmi, pmf, pmd and pmc to be a pointer to a member of X of type int, a pointer to a member of X of type void(int), a pointer to a member of X of type double and a pointer to a member of Y of type char respectively. The declaration of pmd is well-formed even though X has no members of type double. Similarly, the declaration of pmc is well- formed even though Y is an incomplete type. pmi and pmf can be used like this: X obj; //... obj.*pmi = 7; // assign 7 to an integer // member of obj (obj.*pmf)(7); // call a function member of obj // with the argument 7 --end example] 3 A pointer to member shall not point to a static member of a class (_class.static_), a member with reference type, or cv void." [Note: see also _expr.unary_ and _expr.mptr.oper_. The type "pointer to mem- ber" is distinct from the type "pointer", that is, a pointer to member is declared only by the pointer to member declarator syntax, and never by the pointer declarator syntax. There is no "reference-to-member" type in C++. ] 8.3.4 Arrays [dcl.array] 1 In a declaration T D where D has the form D1 [constant-expressionopt] and the type of the identifier in the declaration T D1 is derived- declarator-type-list T," then the type of the identifier of D is an array type. T is called the array element type; this type shall not be a reference type, the (possibly cv-qualified) type void, a function type or an abstract class type. If the constant-expression (_expr.const_) is present, it shall be an integral constant expression and its value shall be greater than zero. The constant expression specifies the bound of (number of elements in) the array. If the value of the constant expression is N, the array has N elements num- bered 0 to N-1, and the type of the identifier of D is "derived- declarator-type-list array of N T." An object of array type contains a contiguously allocated non-empty set of N sub-objects of type T. If the constant expression is omitted, the type of the identifier of D is "derived-declarator-type-list array of unknown bound of T," an incom- plete object type. The type "derived-declarator-type-list array of N T" is a different type from the type "derived-declarator-type-list array of unknown bound of T," see _basic.types_. Any type of the form "cv-qualifier-seq array of N T" is adjusted to "array of N cv-quali- fier-seq T," and similarly for "array of unknown bound of T." [Exam- ple: typedef int A[5], AA[2][3]; typedef const A CA; // type is ``array of 5 const int'' typedef const AA CAA; // type is ``array of 2 array of 3 const int'' --end example] [Note: an "array of N cv-qualifier-seq T" has cv-qual- ified type; such an array has internal linkage unless explicitly declared extern (_dcl.type.cv_) and must be initialized as specified in _dcl.init_. ] 2 An array can be constructed from one of the fundamental types (except void), from a pointer, from a pointer to member, from a class, from an enumeration type, or from another array. 3 When several "array of" specifications are adjacent, a multidimen- sional array is created; the constant expressions that specify the bounds of the arrays can be omitted only for the first member of the sequence. [Note: this elision is useful for function parameters of array types, and when the array is external and the definition, which allocates storage, is given elsewhere. ] The first constant-expres- sion can also be omitted when the declarator is followed by an ini- tializer (_dcl.init_). In this case the bound is calculated from the number of initial elements (say, N) supplied (_dcl.init.aggr_), and the type of the identifier of D is "array of N T." 4 [Example: float fa[17], *afp[17]; declares an array of float numbers and an array of pointers to float numbers. For another example, static int x3d[3][5][7]; declares a static three-dimensional array of integers, with rank 3x5x7. In complete detail, x3d is an array of three items; each item is an array of five arrays; each of the latter arrays is an array of seven integers. Any of the expressions x3d, x3d[i], x3d[i][j], x3d[i][j][k] can reasonably appear in an expression. ] 5 [Note: conversions affecting lvalues of array type are described in _conv.array_. Objects of array types cannot be modified, see _basic.lval_. ] 6 Except where it has been declared for a class (_over.sub_), the sub- script operator [] is interpreted in such a way that E1[E2] is identi- cal to *((E1)+(E2)). Because of the conversion rules that apply to +, if E1 is an array and E2 an integer, then E1[E2] refers to the E2-th member of E1. Therefore, despite its asymmetric appearance, sub- scripting is a commutative operation. 7 A consistent rule is followed for multidimensional arrays. If E is an n-dimensional array of rank ixjx...xk, then E appearing in an expres- sion is converted to a pointer to an (n-1)-dimensional array with rank jx...xk. If the * operator, either explicitly or implicitly as a result of subscripting, is applied to this pointer, the result is the pointed-to (n-1)-dimensional array, which itself is immediately con- verted into a pointer. 8 [Example: consider int x[3][5]; Here x is a 3x5 array of integers. When x appears in an expression, it is converted to a pointer to (the first of three) five-membered arrays of integers. In the expression x[i], which is equivalent to *(x+i), x is first converted to a pointer as described; then x+i is converted to the type of x, which involves multiplying i by the length of the object to which the pointer points, namely five integer objects. The results are added and indirection applied to yield an array (of five integers), which in turn is converted to a pointer to the first of the integers. If there is another subscript the same argument applies again; this time the result is an integer. ] 9 [Note: it follows from all this that arrays in C++ are stored row-wise (last subscript varies fastest) and that the first subscript in the declaration helps determine the amount of storage consumed by an array but plays no other part in subscript calculations. ] 8.3.5 Functions [dcl.fct] 1 In a declaration T D where D has the form D1 ( parameter-declaration-clause ) cv-qualifier-seqopt exception-specificationopt and the type of the contained declarator-id in the declaration T D1 is derived-declarator-type-list T," the type of the declarator-id in D is "derived-declarator-type-list function of (parameter-declaration- clause) cv-qualifier-seqopt returning T"; a type of this form is a function type86). parameter-declaration-clause: parameter-declaration-listopt ...opt parameter-declaration-list , ... parameter-declaration-list: parameter-declaration parameter-declaration-list , parameter-declaration parameter-declaration: decl-specifier-seq declarator decl-specifier-seq declarator = assignment-expression decl-specifier-seq abstract-declaratoropt decl-specifier-seq abstract-declaratoropt = assignment-expression 2 The parameter-declaration-clause determines the arguments that can be specified, and their processing, when the function is called. [Note: the parameter-declaration-clause is used to convert the arguments specified on the function call; see _expr.call_. ] If the parameter- declaration-clause is empty, the function takes no arguments. The parameter list (void) is equivalent to the empty parameter list. Except for this special case, void shall not be a parameter type (though types derived from void, such as void*, can). If the parame- ter-declaration-clause terminates with an ellipsis, the number of arguments shall be equal to or greater than the number of parameters specified. Where syntactically correct, ", ..." is synonymous with "...". [Example: the declaration int printf(const char*, ...); declares a function that can be called with varying numbers and types of arguments. printf("hello world"); printf("a=%d b=%d", a, b); However, the first argument must be of a type that can be converted to a const char*. ] [Note: the standard header contains a mechanism for accessing arguments passed using the ellipsis (see _expr.call_ and _lib.support.runtime_). ] 3 A single name can be used for several different functions in a single scope; this is function overloading (clause _over_). All declarations for a function with a given parameter list shall agree exactly both in the type of the value returned and in the number and type of parame- ters; the presence or absence of the ellipsis is considered part of the function type. The type of a function is determined using the following rules. The type of each parameter is determined from its own decl-specifier-seq and declarator. After determining the type of each parameter, any parameter of type "array of T" or "function returning T" is adjusted to be "pointer to T" or "pointer to function returning T," respectively. After producing the list of parameter types, several transformations take place upon these types to deter- mine the function type. Any cv-qualifier modifying a parameter type _________________________ 86) As indicated by the syntax, cv-qualifiers are a significant compo- nent in function return types. is deleted. [Example: the type void(*)(const int) becomes void(*)(int) --end example] Such cv-qualifiers affect only the defi- nition of the parameter within the body of the function; they do not affect the function type. If a storage-class-specifier modifies a parameter type, the specifier is deleted. [Example: register char* becomes char* --end example] Such storage-class-specifiers affect only the definition of the parameter within the body of the function; they do not affect the function type. The resulting list of trans- formed parameter types is the function's parameter type list. 4 A cv-qualifier-seq shall only be part of the function type for a non- static member function, the function type to which a pointer to member refers, or the top-level function type of a function typedef declara- tion. The effect of a cv-qualifier-seq in a function declarator is not the same as adding cv-qualification on top of the function type, i.e., it does not create a cv-qualified function type. In fact, if at any time in the determination of a type a cv-qualified function type is formed, the program is ill-formed. [Example: typedef void F(); struct S { const F f; // ill-formed: // not equivalent to: void f() const; }; --end example] The return type, the parameter type list and the cv- qualifier-seq, but not the default arguments (_dcl.fct.default_) or the exception specification (_except.spec_), are part of the function type. [Note: function types are checked during the assignments and initializations of pointer-to-functions, reference-to-functions, and pointer-to-member-functions. ] 5 [Example: the declaration int fseek(FILE*, long, int); declares a function taking three arguments of the specified types, and returning int (_dcl.type_). ] 6 If the type of a parameter includes a type of the form "pointer to array of unknown bound of T" or "reference to array of unknown bound of T," the program is ill-formed.87) Functions shall not have a return type of type array or function, although they may have a return type of type pointer or reference to such things. There shall be no arrays of functions, although there can be arrays of pointers to functions. Types shall not be defined in return or parameter types. The type of a parameter or the return type for a function declaration that is not a definition may be an incomplete class type. _________________________ 87) This excludes parameters of type "ptr-arr-seq T2" where T2 is "pointer to array of unknown bound of T" and where ptr-arr-seq means any sequence of "pointer to" and "array of" derived declarator types. This exclusion applies to the parameters of the function, and if a pa- rameter is a pointer to function or pointer to member function then to its parameters also, etc. 7 A typedef of function type may be used to declare a function but shall not be used to define a function (_dcl.fct.def_). [Example: typedef void F(); F fv; // OK: equivalent to void fv(); F fv { } // ill-formed void fv() { } // OK: definition of fv --end example] A typedef of a function type whose declarator includes a cv-qualifier-seq shall be used only to declare the function type for a nonstatic member function, to declare the function type to which a pointer to member refers, or to declare the top-level function type of another function typedef declaration. [Example: typedef int FIC(int) const; FIC f; // ill-formed: does not declare a member function struct S { FIC f; // OK }; FIC S::*pm = &S::f; // OK --end example] 8 An identifier can optionally be provided as a parameter name; if pre- sent in a function definition (_dcl.fct.def_), it names a parameter (sometimes called "formal argument"). [Note: in particular, parameter names are also optional in function definitions and names used for a parameter in different declarations and the definition of a function need not be the same. If a parameter name is present in a function declaration that is not a definition, it cannot be used outside of the parameter-declaration-clause since it goes out of scope at the end of the function declarator (_basic.scope_). ] 9 [Example: the declaration int i, *pi, f(), *fpi(int), (*pif)(const char*, const char*); (*fpif(int))(int); declares an integer i, a pointer pi to an integer, a function f taking no arguments and returning an integer, a function fpi taking an inte- ger argument and returning a pointer to an integer, a pointer pif to a function which takes two pointers to constant characters and returns an integer, a function fpif taking an integer argument and returning a pointer to a function that takes an integer argument and returns an integer. It is especially useful to compare fpi and pif. The binding of *fpi(int) is *(fpi(int)), so the declaration suggests, and the same construction in an expression requires, the calling of a function fpi, and then using indirection through the (pointer) result to yield an integer. In the declarator (*pif)(const char*, const char*), the extra parentheses are necessary to indicate that indirection through a pointer to a function yields a function, which is then called. ] [Note: typedefs are sometimes convenient when the return type of a function is complex. For example, the function fpif above could have been declared typedef int IFUNC(int); IFUNC* fpif(int); --end note] 8.3.6 Default arguments [dcl.fct.default] 1 If an expression is specified in a parameter declaration this expres- sion is used as a default argument. Default arguments will be used in calls where trailing arguments are missing. 2 [Example: the declaration void point(int = 3, int = 4); declares a function that can be called with zero, one, or two argu- ments of type int. It can be called in any of these ways: point(1,2); point(1); point(); The last two calls are equivalent to point(1,4) and point(3,4), respectively. ] 3 A default argument expression shall be specified only in the parame- ter-declaration-clause of a function declaration or in a template- parameter (_temp.param_). If it is specified in a parameter-declara- tion-clause, it shall not occur within a declarator or abstract- declarator of a parameter-declaration.88) 4 For non-template functions, default arguments can be added in later declarations of a function in the same scope. Declarations in differ- ent scopes have completely distinct sets of default arguments. That is, declarations in inner scopes do not acquire default arguments from declarations in outer scopes, and vice versa. In a given function declaration, all parameters subsequent to a parameter with a default argument shall have default arguments supplied in this or previous declarations. A default argument shall not be redefined by a later declaration (not even to the same value). [Example: void f(int, int); void f(int, int = 7); void h() { f(3); // OK, calls f(3, 7) void f(int = 1, int); // error: does not use default // from surrounding scope } _________________________ 88) This means that default arguments cannot appear, for example, in declarations of pointers to functions, references to functions, or typedef declarations. void m() { void f(int, int); // has no defaults f(4); // error: wrong number of arguments void f(int, int = 5); // OK f(4); // OK, calls f(4, 5); void f(int, int = 5); // error: cannot redefine, even to // same value } void n() { f(6); // OK, calls f(6, 7) } --end example] For a given inline function defined in different translation units, the accumulated sets of default arguments at the end of the translation units shall be the same; see _basic.def.odr_. 5 A default argument expression is implicitly converted (clause _conv_) to the parameter type. The default argument expression has the same semantic constraints as the initializer expression in a declaration of a variable of the parameter type, using the copy-initialization seman- tics (_dcl.init_). The names in the expression are bound, and the semantic constraints are checked, at the point where the default argu- ment expression appears. Name lookup and checking of semantic con- straints for default arguments in function templates and in member functions of class templates are performed as described in _temp.inst_. [Example: in the following code, g will be called with the value f(1): int a = 1; int f(int); int g(int x = f(a)); // default argument: f(::a) void h() { a = 2; { int a = 3; g(); // g(f(::a)) } } --end example] [Note: in member function declarations, names in default argument expressions are looked up as described in _basic.lookup.unqual_. Access checking applies to names in default argument expressions as described in clause _class.access_. ] 6 The default arguments in a member function definition that appears outside of the class definition are added to the set of default argu- ments provided by the member function declaration in the class defini- tion. [Example: class C { void f(int i = 3); void g(int i, int j = 99); }; void C::f(int i = 3) // error: default argument already { } // specified in class scope void C::g(int i = 88, int j) // in this translation unit, { } // C::g can be called with no argument --end example] 7 Local variables shall not be used in default argument expressions. [Example: void f() { int i; extern void g(int x = i); // error // ... } --end example] 8 The keyword this shall not be used in a default argument of a member function. [Example: class A { void f(A* p = this) { } // error }; --end example] 9 Default arguments are evaluated each time the function is called. The order of evaluation of function arguments is unspecified. Conse- quently, parameters of a function shall not be used in default argu- ment expressions, even if they are not evaluated. Parameters of a function declared before a default argument expression are in scope and can hide namespace and class member names. [Example: int a; int f(int a, int b = a); // error: parameter a // used as default argument typedef int I; int g(float I, int b = I(2)); // error: parameter I found int h(int a, int b = sizeof(a)); // error, parameter a used // in default argument --end example] Similarly, a nonstatic member shall not be used in a default argument expression, even if it is not evaluated, unless it appears as the id-expression of a class member access expression (_expr.ref_) or unless it is used to form a pointer to member (_expr.unary.op_). [Example: the declaration of X::mem1() in the fol- lowing example is ill-formed because no object is supplied for the nonstatic member X::a used as an initializer. int b; class X { int a; int mem1(int i = a); // error: nonstatic member a // used as default argument int mem2(int i = b); // OK; use X::b static int b; }; The declaration of X::mem2() is meaningful, however, since no object is needed to access the static member X::b. Classes, objects, and members are described in clause _class_. ] A default argument is not part of the type of a function. [Example: int f(int = 0); void h() { int j = f(1); int k = f(); // OK, means f(0) } int (*p1)(int) = &f; int (*p2)() = &f; // error: type mismatch --end example] When a declaration of a function is introduced by way of a using-declaration (_namespace.udecl_), any default argument information associated with the declaration is made known as well. If the function is redeclared thereafter in the namespace with additional default arguments, the additional arguments are also known at any point following the redeclaration where the using-declaration is in scope. 10A virtual function call (_class.virtual_) uses the default arguments in the declaration of the virtual function determined by the static type of the pointer or reference denoting the object. An overriding function in a derived class does not acquire default arguments from the function it overrides. [Example: struct A { virtual void f(int a = 7); }; struct B : public A { void f(int a); }; void m() { B* pb = new B; A* pa = pb; pa->f(); // OK, calls pa->B::f(7) pb->f(); // error: wrong number of arguments for B::f() } --end example] 8.4 Function definitions [dcl.fct.def] 1 Function definitions have the form function-definition: decl-specifier-seqopt declarator ctor-initializeropt function-body decl-specifier-seqopt declarator function-try-block function-body: compound-statement The declarator in a function-definition shall have the form D1 ( parameter-declaration-clause ) cv-qualifier-seqopt exception-specificationopt as described in _dcl.fct_. A function shall be defined only in names- pace or class scope. 2 [Example: a simple example of a complete function definition is int max(int a, int b, int c) { int m = (a > b) ? a : b; return (m > c) ? m : c; } Here int is the decl-specifier-seq; max(int a, int b, int c) is the declarator; { /* ... */ } is the function-body. ] 3 A ctor-initializer is used only in a constructor; see _class.ctor_ and _class.init_. 4 A cv-qualifier-seq can be part of a non-static member function decla- ration, non-static member function definition, or pointer to member function only; see _class.this_. It is part of the function type. 5 [Note: unused parameters need not be named. For example, void print(int a, int) { printf("a = %d\n",a); } --end note] 8.5 Initializers [dcl.init] 1 A declarator can specify an initial value for the identifier being declared. The identifier designates an object or reference being ini- tialized. The process of initialization described in the remainder of _dcl.init_ applies also to initializations specified by other syntac- tic contexts, such as the initialization of function parameters with argument expressions (_expr.call_) or the initialization of return values (_stmt.return_). initializer: = initializer-clause ( expression-list ) initializer-clause: assignment-expression { initializer-list ,opt } { } initializer-list: initializer-clause initializer-list , initializer-clause 2 Automatic, register, static, and external variables of namespace scope can be initialized by arbitrary expressions involving literals and previously declared variables and functions. [Example: int f(int); int a = 2; int b = f(a); int c(b); --end example] 3 [Note: default argument expressions are more restricted; see _dcl.fct.default_. 4 The order of initialization of static objects is described in _basic.start_ and _stmt.dcl_. ] 5 To zero-initialize storage for an object of type T means: --if T is a scalar type (_basic.types_), the storage is set to the value of 0 (zero) converted to T; --if T is a non-union class type, the storage for each nonstatic data member and each base-class subobject is zero-initialized; --if T is a union type, the storage for its first data member89) is zero-initialized; --if T is an array type, the storage for each element is zero-initial- ized; --if T is a reference type, no initialization is performed. To default-initialize an object of type T means: --if T is a non-POD class type (clause _class_), the default construc- tor for T is called (and the initialization is ill-formed if T has no accessible default constructor); --if T is an array type, each element is default-initialized; --otherwise, the storage for the object is zero-initialized. A program that calls for default-initialization of an entity of refer- ence type is ill-formed. If T is a cv-qualified type, the cv-unquali- fied version of T is used for these definitions of zero-initialization and default-initialization. 6 The memory occupied by any object of static storage duration shall be zero-initialized at program startup before any other initialization takes place. [Note: in some cases, additional initialization is done later. ] 7 An object whose initializer is an empty set of parentheses, i.e., (), shall be default-initialized. 8 [Note: since () is not permitted by the syntax for initializer, X a(); is not the declaration of an object of class X, but the declaration of a function taking no argument and returning an X. The form () is per- mitted in certain other initialization contexts (_expr.new_, _expr.type.conv_, _class.base.init_). ] _________________________ 89) This member must not be static, by virtue of the requirements in _class.union_. 9 If no initializer is specified for an object, and the object is of (possibly cv-qualified) non-POD class type (or array thereof), the object shall be default-initialized; if the object is of const-quali- fied type, the underlying class type shall have a user-declared default constructor. Otherwise, if no initializer is specified for an object, the object and its subobjects, if any, have an indeterminate initial value90); if the object or any of its subobjects are of const- qualified type, the program is ill-formed. 10An initializer for a static member is in the scope of the member's class. [Example: int a; struct X { static int a; static int b; }; int X::a = 1; int X::b = a; // X::b = X::a --end example] 11The form of initialization (using parentheses or =) is generally insignificant, but does matter when the entity being initialized has a class type; see below. A parenthesized initializer can be a list of expressions only when the entity being initialized has a class type. 12The initialization that occurs in argument passing, function return, throwing an exception (_except.throw_), handling an exception (_except.handle_), and brace-enclosed initializer lists (_dcl.init.aggr_) is called copy-initialization and is equivalent to the form T x = a; The initialization that occurs in new expressions (_expr.new_), static_cast expressions (_expr.static.cast_), functional notation type conversions (_expr.type.conv_), and base and member initializers (_class.base.init_) is called direct-initialization and is equivalent to the form T x(a); 13If T is a scalar type, then a declaration of the form T x = { a }; is equivalent to T x = a; 14The semantics of initializers are as follows. The destination type is the type of the object or reference being initialized and the source type is the type of the initializer expression. The source type is not defined when the initializer is brace-enclosed or when it is a _________________________ 90) This does not apply to aggregate objects with automatic storage duration initialized with an incomplete brace-enclosed initializer- list; see _dcl.init.aggr_. parenthesized list of expressions. --If the destination type is a reference type, see _dcl.init.ref_. --If the destination type is an array of characters or an array of wchar_t, and the initializer is a string literal, see _dcl.init.string_. --Otherwise, if the destination type is an array, see _dcl.init.aggr_. --If the destination type is a (possibly cv-qualified) class type: --If the class is an aggregate (_dcl.init.aggr_), and the initial- izer is a brace-enclosed list, see _dcl.init.aggr_. --If the initialization is direct-initialization, or if it is copy- initialization where the cv-unqualified version of the source type is the same class as, or a derived class of, the class of the des- tination, constructors are considered. The applicable construc- tors are enumerated (_over.match.ctor_), and the best one is cho- sen through overload resolution (_over.match_). The constructor so selected is called to initialize the object, with the initial- izer expression(s) as its argument(s). If no constructor applies, or the overload resolution is ambiguous, the initialization is ill-formed. --Otherwise (i.e., for the remaining copy-initialization cases), user-defined conversion sequences that can convert from the source type to the destination type or (when a conversion function is used) to a derived class thereof are enumerated as described in _over.match.copy_, and the best one is chosen through overload resolution (_over.match_). If the conversion cannot be done or is ambiguous, the initialization is ill-formed. The function selected is called with the initializer expression as its argu- ment; if the function is a constructor, the call initializes a temporary of the destination type. The result of the call (which is the temporary for the constructor case) is then used to direct- initialize, according to the rules above, the object that is the destination of the copy-initialization. In certain cases, an implementation is permitted to eliminate the copying inherent in this direct-initialization by constructing the intermediate result directly into the object being initialized; see _class.temporary_, _class.copy_. --Otherwise, if the source type is a (possibly cv-qualified) class type, conversion functions are considered. The applicable conver- sion functions are enumerated (_over.match.conv_), and the best one is chosen through overload resolution (_over.match_). The user- defined conversion so selected is called to convert the initializer expression into the object being initialized. If the conversion cannot be done or is ambiguous, the initialization is ill-formed. --Otherwise, the initial value of the object being initialized is the (possibly converted) value of the initializer expression. Standard conversions (clause _conv_) will be used, if necessary, to convert the initializer expression to the cv-unqualified version of the des- tination type; no user-defined conversions are considered. If the conversion cannot be done, the initialization is ill-formed. [Note: an expression of type "cv1 T" can initialize an object of type "cv2 T" independently of the cv-qualifiers cv1 and cv2. int a; const int b = a; int c = b; --end note] 8.5.1 Aggregates [dcl.init.aggr] 1 An aggregate is an array or a class (clause _class_) with no user- declared constructors (_class.ctor_), no private or protected non- static data members (clause _class.access_), no base classes (clause _class.derived_), and no virtual functions (_class.virtual_). 2 When an aggregate is initialized the initializer can be an initial- izer-clause consisting of a brace-enclosed, comma-separated list of initializers for the members of the aggregate, written in increasing subscript or member order. If the aggregate contains subaggregates, this rule applies recursively to the members of the subaggregate. [Example: struct A { int x; struct B { int i; int j; } b; } a = { 1, { 2, 3 } }; initializes a.x with 1, a.b.i with 2, a.b.j with 3. ] 3 An aggregate that is a class can also be initialized with a single expression not enclosed in braces, as described in _dcl.init_. 4 An array of unknown size initialized with a brace-enclosed initial- izer-list containing n initializers, where n shall be greater than zero, is defined as having n elements (_dcl.array_). [Example: int x[] = { 1, 3, 5 }; declares and initializes x as a one-dimensional array that has three elements since no size was specified and there are three initializers. ] An empty initializer list {} shall not be used as the initializer for an array of unknown bound.91) 5 Static data members are not considered members of the class for pur- poses of aggregate initialization. [Example: _________________________ 91) The syntax provides for empty initializer-lists, but nonetheless C++ does not have zero length arrays. struct A { int i; static int s; int j; } a = { 1, 2 }; Here, the second initializer 2 initializes a.j and not the static data member A::s. ] 6 An initializer-list is ill-formed if the number of initializers exceeds the number of members or elements to initialize. [Example: char cv[4] = { 'a', 's', 'd', 'f', 0 }; // error is ill-formed. ] 7 If there are fewer initializers in the list than there are members in the aggregate, then each member not explicitly initialized shall be default-initialized (_dcl.init_). [Example: struct S { int a; char* b; int c; }; S ss = { 1, "asdf" }; initializes ss.a with 1, ss.b with "asdf", and ss.c with the value of an expression of the form int(), that is, 0. ] 8 An initializer for an aggregate member that is an empty class shall have the form of an empty initializer-list {}. [Example: struct S { }; struct A { S s; int i; } a = { { } , 3 }; --end example] An empty initializer-list can be used to initialize any aggregate. If the aggregate is not an empty class, then each mem- ber of the aggregate shall be initialized with a value of the form T() (_expr.type.conv_), where T represents the type of the uninitialized member. 9 If an incomplete or empty initializer-list leaves a member of refer- ence type uninitialized, the program is ill-formed. 10When initializing a multi-dimensional array, the initializers initial- ize the elements with the last (rightmost) index of the array varying the fastest (_dcl.array_). [Example: int x[2][2] = { 3, 1, 4, 2 }; initializes x[0][0] to 3, x[0][1] to 1, x[1][0] to 4, and x[1][1] to 2. On the other hand, float y[4][3] = { { 1 }, { 2 }, { 3 }, { 4 } }; initializes the first column of y (regarded as a two-dimensional array) and leaves the rest zero. ] 11Braces can be elided in an initializer-list as follows. If the ini- tializer-list begins with a left brace, then the succeeding comma-sep- arated list of initializers initializes the members of a subaggregate; it is erroneous for there to be more initializers than members. If, however, the initializer-list for a subaggregate does not begin with a left brace, then only enough initializers from the list are taken to initialize the members of the subaggregate; any remaining initializers are left to initialize the next member of the aggregate of which the current subaggregate is a member. [Example: float y[4][3] = { { 1, 3, 5 }, { 2, 4, 6 }, { 3, 5, 7 }, }; is a completely-braced initialization: 1, 3, and 5 initialize the first row of the array y[0], namely y[0][0], y[0][1], and y[0][2]. Likewise the next two lines initialize y[1] and y[2]. The initializer ends early and therefore y[3]'s elements are initialized as if explic- itly initialized with an expression of the form float(), that is, are initialized with 0.0. In the following example, braces in the ini- tializer-list are elided; however the initializer-list has the same effect as the completely-braced initializer-list of the above example, float y[4][3] = { 1, 3, 5, 2, 4, 6, 3, 5, 7 }; The initializer for y begins with a left brace, but the one for y[0] does not, therefore three elements from the list are used. Likewise the next three are taken successively for y[1] and y[2]. --end exam- ple] 12All implicit type conversions (clause _conv_) are considered when ini- tializing the aggregate member with an initializer from an initial- izer-list. If the initializer can initialize a member, the member is initialized. Otherwise, if the member is itself a non-empty subaggre- gate, brace elision is assumed and the initializer is considered for the initialization of the first member of the subaggregate. [Example: struct A { int i; operator int(); }; struct B { A a1, a2; int z; }; A a; B b = { 4, a, a }; Braces are elided around the initializer for b.a1.i. b.a1.i is ini- tialized with 4, b.a2 is initialized with a, b.z is initialized with whatever a.operator int() returns. ] 13[Note: An aggregate array or an aggregate class may contain members of a class type with a user-declared constructor (_class.ctor_). Ini- tialization of these aggregate objects is described in _class.expl.init_. ] 14When an aggregate with static storage duration is initialized with a brace-enclosed initializer-list, if all the member initializer expres- sions are constant expressions, and the aggregate is a POD type, the initialization shall be done during the static phase of initialization (_basic.start.init_); otherwise, it is unspecified whether the ini- tialization of members with constant expressions takes place during the static phase or during the dynamic phase of initialization. 15When a union is initialized with a brace-enclosed initializer, the braces shall only contain an initializer for the first member of the union. [Example: union u { int a; char* b; }; u a = { 1 }; u b = a; u c = 1; // error u d = { 0, "asdf" }; // error u e = { "asdf" }; // error --end example] [Note: as described above, the braces around the ini- tializer for a union member can be omitted if the union is a member of another aggregate. ] 8.5.2 Character arrays [dcl.init.string] 1 A char array (whether plain char, signed char, or unsigned char) can be initialized by a string-literal (optionally enclosed in braces); a wchar_t array can be initialized by a wide string-literal (optionally enclosed in braces); successive characters of the string-literal ini- tialize the members of the array. [Example: char msg[] = "Syntax error on line %s\n"; shows a character array whose members are initialized with a string- literal. Note that because '\n' is a single character and because a trailing '\0' is appended, sizeof(msg) is 25. ] 2 There shall not be more initializers than there are array elements. [Example: char cv[4] = "asdf"; // error is ill-formed since there is no space for the implied trailing '\0'. ] 8.5.3 References [dcl.init.ref] 1 A variable declared to be a T&, that is "reference to type T" (_dcl.ref_), shall be initialized by an object, or function, of type T or by an object that can be converted into a T. [Example: int g(int); void f() { int i; int& r = i; // r refers to i r = 1; // the value of i becomes 1 int* p = &r; // p points to i int& rr = r; // rr refers to what r refers to, // that is, to i int (&rg)(int) = g; // rg refers to the function g rg(i); // calls function g int a[3]; int (&ra)[3] = a; // ra refers to the array a ra[1] = i; // modifies a[1] } --end example] 2 A reference cannot be changed to refer to another object after ini- tialization. Note that initialization of a reference is treated very differently from assignment to it. Argument passing (_expr.call_) and function value return (_stmt.return_) are initializations. 3 The initializer can be omitted for a reference only in a parameter declaration (_dcl.fct_), in the declaration of a function return type, in the declaration of a class member within its class declaration (_class.mem_), and where the extern specifier is explicitly used. [Example: int& r1; // error: initializer missing extern int& r2; // OK --end example] 4 Given types "cv1 T1" and "cv2 T2," "cv1 T1" is reference-related to "cv2 T2" if T1 is the same type as T2, or T1 is a base class of T2. "cv1 T1" is reference-compatible with "cv2 T2" if T1 is reference- related to T2 and cv1 is the same cv-qualification as, or greater cv- qualification than, cv2. For purposes of overload resolution, cases for which cv1 is greater cv-qualification than cv2 are identified as reference-compatible with added qualification (see _over.ics.rank_). In all cases where the reference-related or reference-compatible rela- tionship of two types is used to establish the validity of a reference binding, and T1 is a base class of T2, a program that necessitates such a binding is ill-formed if T1 is an inaccessible (clause _class.access_) or ambiguous (_class.member.lookup_) base class of T2. 5 A reference to type "cv1 T1" is initialized by an expression of type "cv2 T2" as follows: --If the initializer expression 6 --is an lvalue (but not an lvalue for a bit-field), and "cv1 T1" is reference-compatible with "cv2 T2," or --has a class type (i.e., T2 is a class type) and can be implicitly converted to an lvalue of type "cv3 T3," where "cv1 T1" is refer- ence-compatible with "cv3 T3" 92) (this conversion is selected by enumerating the applicable conversion functions (_over.match.ref_) and choosing the best one through overload resolution (_over.match_)), then 7 the reference is bound directly to the initializer expression lvalue in the first case, and the reference is bound to the lvalue result of the conversion in the second case. In these cases the reference is said to bind directly to the initializer expression. [Note: the usual lvalue-to-rvalue (_conv.lval_), array-to-pointer (_conv.array_), and function-to-pointer (_conv.func_) standard con- versions are not needed, and therefore are suppressed, when such direct bindings to lvalues are done. ] [Example: double d = 2.0; double& rd = d; // rd refers to d const double& rcd = d; // rcd refers to d struct A { }; struct B : public A { } b; A& ra = b; // ra refers to A sub-object in b const A& rca = b; // rca refers to A sub-object in b --end example] 8 --Otherwise, the reference shall be to a non-volatile const type (i.e., cv1 shall be const). [Example: double& rd2 = 2.0; // error: not an lvalue and reference // not const int i = 2; double& rd3 = i; // error: type mismatch and reference // not const --end example] --If the initializer expression is an rvalue, with T2 a class type, and "cv1 T1" is reference-compatible with "cv2 T2," the reference is bound in one of the following ways (the choice is implementa- tion-defined): --The reference is bound to the object represented by the rvalue (see _basic.lval_) or to a sub-object within that object. --A temporary of type "cv1 T2" [sic] is created, and a constructor is called to copy the entire rvalue object into the temporary. The reference is bound to the temporary or to a sub-object within the temporary.93) _________________________ 92) This requires a conversion function (_class.conv.fct_) returning a reference type. 93) Clearly, if the reference initialization being processed is one for the first argument of a copy constructor call, an implementation must eventually choose the first alternative (binding without copying) to avoid infinite recursion. 9 The constructor that would be used to make the copy shall be callable whether or not the copy is actually done. [Example: struct A { }; struct B : public A { } b; extern B f(); const A& rca = f(); // Either bound to the A sub-object of the // B rvalue, or the entire B object is copied // and the reference is bound to the // A sub-object of the copy --end example] 10 --Otherwise, a temporary of type "cv1 T1" is created and initialized from the initializer expression using the rules for a non-refer- ence copy initialization (_dcl.init_). The reference is then bound to the temporary. If T1 is reference-related to T2, cv1 must be the same cv-qualification as, or greater cv-qualification than, cv2; otherwise, the program is ill-formed. [Example: const double& rcd2 = 2; // rcd2 refers to temporary // with value 2.0 const volatile int cvi = 1; const int& r = cvi; // error: type qualifiers dropped --end example] 11 [Note: _class.temporary_ describes the lifetime of temporaries bound to references. ] ______________________________________________________________________ 9 Classes [class] ______________________________________________________________________ 1 A class is a type. Its name becomes a class-name (_class.name_) within its scope. class-name: identifier template-id Class-specifiers and elaborated-type-specifiers (_dcl.type.elab_) are used to make class-names. An object of a class consists of a (possi- bly empty) sequence of members and base class objects. class-specifier: class-head { member-specificationopt } class-head: class-key identifieropt base-clauseopt class-key nested-name-specifier identifier base-clauseopt class-key nested-name-specifieropt template-id base-clauseopt class-key: class struct union 2 A class-name is inserted into the scope in which it is declared imme- diately after the class-name is seen. The class-name is also inserted into the scope of the class itself. For purposes of access checking, the inserted class name is treated as if it were a public member name. A class-specifier is commonly referred to as a class definition. A class is considered defined after the closing brace of its class-spec- ifier has been seen even though its member functions are in general not yet defined. 3 Complete objects and member subobjects of class type shall have nonzero size.94) [Note: class objects can be assigned, passed as argu- ments to functions, and returned by functions (except objects of classes for which copying has been restricted; see _class.copy_). Other plausible operators, such as equality comparison, can be defined by the user; see _over.oper_. ] 4 A structure is a class defined with the class-key struct; its members and base classes (clause _class.derived_) are public by default (clause _class.access_). A union is a class defined with the class- key union; its members are public by default and it holds only one data member at a time (_class.union_). [Note: aggregates of class _________________________ 94) Base class subobjects are not so constrained. type are described in _dcl.init.aggr_. ] A POD-struct is an aggregate class that has no non-static data members of type pointer to member, non-POD-struct, non-POD-union (or array of such types) or reference, and has no user-defined copy assignment operator and no user-defined destructor. Similarly, a POD-union is an aggregate union that has no non-static data members of type pointer to member, non-POD-struct, non-POD-union (or array of such types) or reference, and has no user- defined copy assignment operator and no user-defined destructor. A POD class is a class that is either a POD-struct or a POD-union. 9.1 Class names [class.name] 1 A class definition introduces a new type. [Example: struct X { int a; }; struct Y { int a; }; X a1; Y a2; int a3; declares three variables of three different types. This implies that a1 = a2; // error: Y assigned to X a1 = a3; // error: int assigned to X are type mismatches, and that int f(X); int f(Y); declare an overloaded (clause _over_) function f() and not simply a single function f() twice. For the same reason, struct S { int a; }; struct S { int a; }; // error, double definition is ill-formed because it defines S twice. ] 2 A class definition introduces the class name into the scope where it is defined and hides any class, object, function, or other declaration of that name in an enclosing scope (_basic.scope_). If a class name is declared in a scope where an object, function, or enumerator of the same name is also declared, then when both declarations are in scope, the class can be referred to only using an elaborated-type-specifier (_basic.lookup.elab_). [Example: struct stat { // ... }; stat gstat; // use plain stat to // define variable int stat(struct stat*); // redeclare stat as function void f() { struct stat* ps; // struct prefix needed // to name struct stat // ... stat(ps); // call stat() // ... } --end example] A declaration consisting solely of class-key identifier ; is either a redeclaration of the name in the current scope or a forward declaration of the identifier as a class name. It introduces the class name into the current scope. [Example: struct s { int a; }; void g() { struct s; // hide global struct s // with a local declaration s* p; // refer to local struct s struct s { char* p; }; // define local struct s struct s; // redeclaration, has no effect } --end example] [Note: Such declarations allow definition of classes that refer to each other. [Example: class Vector; class Matrix { // ... friend Vector operator*(Matrix&, Vector&); }; class Vector { // ... friend Vector operator*(Matrix&, Vector&); }; Declaration of friends is described in _class.friend_, operator func- tions in _over.oper_. ] ] 3 An elaborated-type-specifier (_dcl.type.elab_) can also be used as a type-specifier as part of a declaration. It differs from a class dec- laration in that if a class of the elaborated name is in scope the elaborated name will refer to it. [Example: struct s { int a; }; void g(int s) { struct s* p = new struct s; // global s p->a = s; // local s } --end example] 4 [Note: The declaration of a class name takes effect immediately after the identifier is seen in the class definition or elaborated-type- specifier. For example, class A * A; first specifies A to be the name of a class and then redefines it as the name of a pointer to an object of that class. This means that the elaborated form class A must be used to refer to the class. Such artistry with names can be confusing and is best avoided. ] 5 A typedef-name (_dcl.typedef_) that names a class is a class-name, but shall not be used in an elaborated-type-specifier; see also _dcl.type- def_. 9.2 Class members [class.mem] member-specification: member-declaration member-specificationopt access-specifier : member-specificationopt member-declaration: decl-specifier-seqopt member-declarator-listopt ; function-definition ;opt ::opt nested-name-specifier templateopt unqualified-id ; using-declaration template-declaration member-declarator-list: member-declarator member-declarator-list , member-declarator member-declarator: declarator pure-specifieropt declarator constant-initializeropt identifieropt : constant-expression pure-specifier: = 0 constant-initializer: = constant-expression 1 The member-specification in a class definition declares the full set of members of the class; no member can be added elsewhere. Members of a class are data members, member functions (_class.mfct_), nested types, and enumerators. Data members and member functions are static or nonstatic; see _class.static_. Nested types are classes (_class.name_, _class.nest_) and enumerations (_dcl.enum_) defined in the class, and arbitrary types declared as members by use of a typedef declaration (_dcl.typedef_). The enumerators of an enumeration (_dcl.enum_) defined in the class are members of the class. Except when used to declare friends (_class.friend_) or to introduce the name of a member of a base class into a derived class (_names- pace.udecl_,_class.access.dcl_), member-declarations declare members of the class, and each such member-declaration shall declare at least one member name of the class. A member shall not be declared twice in the member-specification, except that a nested class or member class template can be declared and then later defined. 2 A class is considered a completely-defined object type (_basic.types_) (or complete type) at the closing } of the class-specifier. Within the class member-specification, the class is regarded as complete within function bodies, default arguments and constructor ctor-ini- tializers (including such things in nested classes). Otherwise it is regarded as incomplete within its own class member-specification. 3 [Note: a single name can denote several function members provided their types are sufficiently different (clause _over_). ] 4 A member-declarator can contain a constant-initializer only if it declares a static member (_class.static_) of integral or enumeration type, see _class.static.data_. 5 A member can be initialized using a constructor; see _class.ctor_. [Note: see clause _special_ for a description of constructors and other special member functions. ] 6 A member shall not be auto, extern, or register. 7 The decl-specifier-seq is omitted in constructor, destructor, and con- version function declarations only. The member-declarator-list can be omitted only after a class-specifier, an enum-specifier, or a decl- specifier-seq of the form friend elaborated-type-specifier. A pure- specifier shall be used only in the declaration of a virtual function (_class.virtual_). 8 static (_class.static_) members that are class objects shall be objects of previously defined classes. In particular, a class cl shall not contain an object of class cl, but it can contain a pointer or reference to an object of class cl. When an array is used as the type of a nonstatic member all dimensions shall be specified. 9 Except when used to form a pointer to member (_expr.unary.op_), when used in the body of a nonstatic member function of its class or of a class derived from its class (_class.mfct.nonstatic_), or when used in a mem-initializer for a constructor for its class or for a class derived from its class (_class.base.init_), a nonstatic data or func- tion member of a class shall only be referred to with the class member access syntax (_expr.ref_). 10[Note: the type of a nonstatic member function is an ordinary function type, and the type of a nonstatic data member is an ordinary object type. There are no special member function types or data member types. ] 11[Example: A simple example of a class definition is struct tnode { char tword[20]; int count; tnode *left; tnode *right; }; which contains an array of twenty characters, an integer, and two pointers to similar structures. Once this definition has been given, the declaration tnode s, *sp; declares s to be a tnode and sp to be a pointer to a tnode. With these declarations, sp->count refers to the count member of the struc- ture to which sp points; s.left refers to the left subtree pointer of the structure s; and s.right->tword[0] refers to the initial character of the tword member of the right subtree of s. ] 12Nonstatic data members of a (non-union) class declared without an intervening access-specifier are allocated so that later members have higher addresses within a class object. The order of allocation of nonstatic data members separated by an access-specifier is unspecified (_class.access.spec_). Implementation alignment requirements might cause two adjacent members not to be allocated immediately after each other; so might requirements for space for managing virtual functions (_class.virtual_) and virtual base classes (_class.mi_). 13If T is the name of a class, then each of the following shall have a name different from T: --every data member of class T; --every member of class T that is itself a type; --every enumerator of every member of class T that is an enumerated type; and --every member of every anonymous union that is a member of class T. 14Two POD-struct (clause _class_) types are layout-compatible if they have the same number of members, and corresponding members (in order) have layout-compatible types (_basic.types_). 15Two POD-union (clause _class_) types are layout-compatible if they have the same number of members, and corresponding members (in any order) have layout-compatible types (_basic.types_). 16If a POD-union contains two or more POD-structs that share a common initial sequence, and if the POD-union object currently contains one of these POD-structs, it is permitted to inspect the common initial part of any of them. Two POD-structs share a common initial sequence if corresponding members have layout-compatible types (and, for bit- fields, the same widths) for a sequence of one or more initial mem- bers. 17A pointer to a POD-struct object, suitably converted using a reinter- pret_cast, points to its initial member (or if that member is a bit- field, then to the unit in which it resides) and vice versa. [Note: There might therefore be unnamed padding within a POD-struct object, but not at its beginning, as necessary to achieve appropriate align- ment. ] 9.3 Member functions [class.mfct] 1 Functions declared in the definition of a class, excluding those declared with a friend specifier (_class.friend_), are called member functions of that class. A member function may be declared static in which case it is a static member function of its class (_class.static_); otherwise it is a nonstatic member function of its class (_class.mfct.nonstatic_, _class.this_). 2 A member function may be defined (_dcl.fct.def_) in its class defini- tion, in which case it is an inline member function (_dcl.fct.spec_), or it may be defined outside of its class definition if it has already been declared but not defined in its class definition. A member func- tion definition that appears outside of the class definition shall appear in a namespace scope enclosing the class definition. Except for member function definitions that appear outside of a class defini- tion, and except for explicit specializations of template member func- tions (_temp.spec_) appearing outside of the class definition, a mem- ber function shall not be redeclared. 3 An inline member function (whether static or nonstatic) may also be defined outside of its class definition provided either its declara- tion in the class definition or its definition outside of the class definition declares the function as inline. [Note: member functions of a class in namespace scope have external linkage. Member functions of a local class (_class.local_) have no linkage. See _basic.link_. ] 4 There shall be at most one definition of a non-inline member function in a program; no diagnostic is required. There may be more than one inline member function definition in a program. See _basic.def.odr_ and _dcl.fct.spec_. 5 If the definition of a member function is lexically outside its class definition, the member function name shall be qualified by its class name using the :: operator. [Note: a name used in a member function definition (that is, in the parameter-declaration-clause including the default arguments (_dcl.fct.default_), or in the member function body, or, for a constructor function (_class.ctor_), in a mem-initializer expression (_class.base.init_)) is looked up as described in _basic.lookup_. ] [Example: struct X { typedef int T; static T count; void f(T); }; void X::f(T t = count) { } The member function f of class X is defined in global scope; the nota- tion X::f specifies that the function f is a member of class X and in the scope of class X. In the function definition, the parameter type T refers to the typedef member T declared in class X and the default argument count refers to the static data member count declared in class X. ] 6 A static local variable in a member function always refers to the same object, whether or not the member function is inline. 7 Member functions may be mentioned in friend declarations after their class has been defined. 8 Member functions of a local class shall be defined inline in their class definition, if they are defined at all. 9 [Note: a member function can be declared (but not defined) using a typedef for a function type. The resulting member function has exactly the same type as it would have if the function declarator were provided explicitly, see _dcl.fct_. For example, typedef void fv(void); typedef void fvc(void) const; struct S { fv memfunc1; // equivalent to: void memfunc1(void); void memfunc2(); fvc memfunc3; // equivalent to: void memfunc3(void) const; }; fv S::* pmfv1 = &S::memfunc1; fv S::* pmfv2 = &S::memfunc2; fvc S::* pmfv3 = &S::memfunc3; Also see _temp.arg_. ] 9.3.1 Nonstatic member functions [class.mfct.nonstatic] 1 A nonstatic member function may be called for an object of its class type, or for an object of a class derived (clause _class.derived_) from its class type, using the class member access syntax (_expr.ref_, _over.match.call_). A nonstatic member function may also be called directly using the function call syntax (_expr.call_, _over.match.call_) --from within the body of a member function of its class or of a class derived from its class, or --from a mem-initializer (_class.base.init_) for a constructor for its class or for a class derived from its class. If a nonstatic member function of a class X is called for an object that is not of type X, or of a type derived from X, the behavior is undefined. 2 When an id-expression (_expr.prim_) that is not part of a class member access syntax (_expr.ref_) and not used to form a pointer to member (_expr.unary.op_) is used in the body of a nonstatic member function of class X or used in the mem-initializer for a constructor of class X, if name lookup (_basic.lookup.unqual_) resolves the name in the id- expression to a nonstatic nontype member of class X or of a base class of X, the id-expression is transformed into a class member access expression (_expr.ref_) using (*this) (_class.this_) as the postfix- expression to the left of the . operator. The member name then refers to the member of the object for which the function is called. Similarly during name lookup, when an unqualified-id (_expr.prim_) used in the definition of a member function for class X resolves to a static member, an enumerator or a nested type of class X or of a base class of X, the unqualified-id is transformed into a qualified-id (_expr.prim_) in which the nested-name-specifier names the class of the member function. [Example: struct tnode { char tword[20]; int count; tnode *left; tnode *right; void set(char*, tnode* l, tnode* r); }; void tnode::set(char* w, tnode* l, tnode* r) { count = strlen(w)+1; if (sizeof(tword)<=count) perror("tnode string too long"); strcpy(tword,w); left = l; right = r; } void f(tnode n1, tnode n2) { n1.set("abc",&n2,0); n2.set("def",0,0); } In the body of the member function tnode::set, the member names tword, count, left, and right refer to members of the object for which the function is called. Thus, in the call n1.set("abc",&n2,0), tword refers to n1.tword, and in the call n2.set("def",0,0), it refers to n2.tword. The functions strlen, perror, and strcpy are not members of the class tnode and should be declared elsewhere.95) ] 3 A nonstatic member function may be declared const, volatile, or const volatile. These cv-qualifiers affect the type of the this pointer (_class.this_). They also affect the function type (_dcl.fct_) of the member function; a member function declared const is a const member function, a member function declared volatile is a volatile member function and a member function declared const volatile is a const volatile member function. [Example: struct X { void g() const; void h() const volatile; }; X::g is a const member function and X::h is a const volatile member function. ] 4 A nonstatic member function may be declared virtual (_class.virtual_) or pure virtual (_class.abstract_). 9.3.2 The this pointer [class.this] 1 In the body of a nonstatic (_class.mfct_) member function, the keyword this is a non-lvalue expression whose value is the address of the object for which the function is called. The type of this in a member function of a class X is X*. If the member function is declared const, the type of this is const X*, if the member function is declared volatile, the type of this is volatile X*, and if the member function is declared const volatile, the type of this is const volatile X*. 2 In a const member function, the object for which the function is called is accessed through a const access path; therefore, a const _________________________ 95) See, for example, (_lib.c.strings_). member function shall not modify the object and its non-static data members. [Example: struct s { int a; int f() const; int g() { return a++; } int h() const { return a++; } // error }; int s::f() const { return a; } The a++ in the body of s::h is ill-formed because it tries to modify (a part of) the object for which s::h() is called. This is not allowed in a const member function because this is a pointer to const; that is, *this has const type. ] 3 Similarly, volatile semantics (_dcl.type.cv_) apply in volatile member functions when accessing the object and its non-static data members. 4 A cv-qualified member function can be called on an object-expression (_expr.ref_) only if the object-expression is as cv-qualified or less- cv-qualified than the member function. [Example: void k(s& x, const s& y) { x.f(); x.g(); y.f(); y.g(); // error } The call y.g() is ill-formed because y is const and s::g() is a non- const member function, that is, s::g() is less-qualified than the object-expression y. ] 5 Constructors (_class.ctor_) and destructors (_class.dtor_) shall not be declared const, volatile or const volatile. [Note: However, these functions can be invoked to create and destroy objects with cv-quali- fied types, see (_class.ctor_) and (_class.dtor_). ] 9.4 Static members [class.static] 1 A data or function member of a class may be declared static in a class definition, in which case it is a static member of the class. 2 A static member s of class X may be referred to using the qualified-id expression X::s; it is not necessary to use the class member access syntax (_expr.ref_) to refer to a static member. A static member may be referred to using the class member access syntax, in which case the object-expression is always evaluated. [Example: class process { public: static void reschedule(); }; process& g(); void f() { process::reschedule(); // OK: no object necessary g().reschedule(); // g() is called } --end example] A static member may be referred to directly in the scope of its class or in the scope of a class derived (clause _class.derived_) from its class; in this case, the static member is referred to as if a qualified-id expression was used, with the nested- name-specifier of the qualified-id naming the class scope from which the static member is referenced. [Example: int g(); struct X { static int g(); }; struct Y : X { static int i; }; int Y::i = g(); // equivalent to Y::g(); --end example] 3 If an unqualified-id (_expr.prim_) is used in the definition of a static member following the member's declarator-id, and name lookup (_basic.lookup.unqual_) finds that the unqualified-id refers to a static member, enumerator, or nested type of the member's class (or of a base class of the member's class), the unqualified-id is transformed into a qualified-id expression in which the nested-name-specifier names the class scope from which the member is referenced. The defi- nition of a static member shall not use directly the names of the non- static members of its class or of a base class of its class (including as operands of the sizeof operator). The definition of a static mem- ber may only refer to these members to form pointer to members (_expr.unary.op_) or with the class member access syntax (_expr.ref_). 4 Static members obey the usual class member access rules (clause _class.access_). When used in the declaration of a class member, the static specifier shall only be used in the member declarations that appear within the member-specification of the class declaration. [Note: it cannot be specified in member declarations that appear in namespace scope. ] 9.4.1 Static member functions [class.static.mfct] 1 [Note: the rules described in _class.mfct_ apply to static member functions. ] 2 [Note: a static member function does not have a this pointer (_class.this_). ] A static member function shall not be virtual. There shall not be a static and a nonstatic member function with the same name and the same parameter types (_over.load_). A static member function shall not be declared const, volatile, or const volatile. 9.4.2 Static data members [class.static.data] 1 A static data member is not part of the subobjects of a class. There is only one copy of a static data member shared by all the objects of the class. 2 The declaration of a static data member in its class definition is not a definition and may be of an incomplete type other than cv-qualified void. The definition for a static data member shall appear in a namespace scope enclosing the member's class definition. In the defi- nition at namespace scope, the name of the static data member shall be qualified by its class name using the :: operator. The initializer expression in the definition of a static data member is in the scope of its class (_basic.scope.class_). [Example: class process { static process* run_chain; static process* running; }; process* process::running = get_main(); process* process::run_chain = running; The static data member run_chain of class process is defined in global scope; the notation process::run_chain specifies that the member run_chain is a member of class process and in the scope of class pro- cess. In the static data member definition, the initializer expres- sion refers to the static data member running of class process. ] 3 [Note: once the static data member has been defined, it exists even if no objects of its class have been created. [Example: in the example above, run_chain and running exist even if no objects of class process are created by the program. ] ] 4 If a static data member is of const integral or const enumeration type, its declaration in the class definition can specify a constant- initializer which shall be an integral constant expression (_expr.const_). In that case, the member can appear in integral con- stant expressions within its scope. The member shall still be defined in a namespace scope if it is used in the program and the namespace scope definition shall not contain an initializer. 5 There shall be exactly one definition of a static data member that is used in a program; no diagnostic is required; see _basic.def.odr_. Unnamed classes and classes contained directly or indirectly within unnamed classes shall not contain static data members. [Note: this is because there is no mechanism to provide the definitions for such static data members. ] 6 Static data members of a class in namespace scope have external link- age (_basic.link_). A local class shall not have static data members. 7 Static data members are initialized and destroyed exactly like non- local objects (_basic.start.init_, _basic.start.term_). 8 A static data member shall not be mutable (_dcl.stc_). 9.5 Unions [class.union] 1 In a union, at most one of the data members can be active at any time, that is, the value of at most one of the data members can be stored in a union at any time. [Note: one special guarantee is made in order to simplify the use of unions: If a POD-union contains several POD- structs that share a common initial sequence (_class.mem_), and if an object of this POD-union type contains one of the POD-structs, it is permitted to inspect the common initial sequence of any of POD-struct members; see _class.mem_. ] The size of a union is sufficient to con- tain the largest of its data members. Each data member is allocated as if it were the sole member of a struct. A union can have member functions (including constructors and destructors), but not virtual (_class.virtual_) functions. A union shall not have base classes. A union shall not be used as a base class. An object of a class with a non-trivial constructor (_class.ctor_), a non-trivial copy constructor (_class.copy_), a non-trivial destructor (_class.dtor_), or a non- trivial copy assignment operator (_over.ass_, _class.copy_) cannot be a member of a union, nor can an array of such objects. If a union contains a static data member, or a member of reference type, the pro- gram is ill-formed. 2 A union of the form union { member-specification } ; is called an anonymous union; it defines an unnamed object of unnamed type. The member-specification of an anonymous union shall only define non-static data members. [Note: nested types and functions cannot be declared within an anonymous union. ] The names of the mem- bers of an anonymous union shall be distinct from the names of any other entity in the scope in which the anonymous union is declared. For the purpose of name lookup, after the anonymous union definition, the members of the anonymous union are considered to have been defined in the scope in which the anonymous union is declared. [Example: void f() { union { int a; char* p; }; a = 1; // ... p = "Jennifer"; // ... } Here a and p are used like ordinary (nonmember) variables, but since they are union members they have the same address. ] 3 Anonymous unions declared in a named namespace or in the global names- pace shall be declared static. Anonymous unions declared at block scope shall be declared with any storage class allowed for a block- scope variable, or with no storage class. A storage class is not allowed in a declaration of an anonymous union in a class scope. An anonymous union shall not have private or protected members (clause _class.access_). An anonymous union shall not have function members. 4 A union for which objects or pointers are declared is not an anonymous union. [Example: union { int aa; char* p; } obj, *ptr = &obj; aa = 1; // error ptr->aa = 1; // OK The assignment to plain aa is ill formed since the member name is not visible outside the union, and even if it were visible, it is not associated with any particular object. ] [Note: Initialization of unions with no user-declared constructors is described in (_dcl.init.aggr_). ] 9.6 Bit-fields [class.bit] 1 A member-declarator of the form identifieropt : constant-expression specifies a bit-field; its length is set off from the bit-field name by a colon. The bit-field attribute is not part of the type of the class member. The constant-expression shall be an integral constant- expression with a value greater than or equal to zero. The constant- expression may be larger than the number of bits in the object repre- sentation (_basic.types_) of the bit-field's type; in such cases the extra bits are used as padding bits and do not participate in the value representation (_basic.types_) of the bit-field. Allocation of bit-fields within a class object is implementation-defined. Alignment of bit-fields is implementation-defined. Bit-fields are packed into some addressable allocation unit. [Note: bit-fields straddle alloca- tion units on some machines and not on others. Bit-fields are assigned right-to-left on some machines, left-to-right on others. ] 2 A declaration for a bit-field that omits the identifier declares an unnamed bit-field. Unnamed bit-fields are not members and cannot be initialized. [Note: an unnamed bit-field is useful for padding to conform to externally-imposed layouts. ] As a special case, an unnamed bit-field with a width of zero specifies alignment of the next bit-field at an allocation unit boundary. Only when declaring an unnamed bit-field may the constant-expression be a value equal to zero. 3 A bit-field shall not be a static member. A bit-field shall have integral or enumeration type (_basic.fundamental_). It is implementa- tion-defined whether a plain (neither explicitly signed nor unsigned) char, short, int or long bit-field is signed or unsigned. A bool value can successfully be stored in a bit-field of any nonzero size. The address-of operator & shall not be applied to a bit-field, so there are no pointers to bit-fields. A non-const reference shall not be bound to a bit-field (_dcl.init.ref_). [Note: if the initializer for a reference of type const T& is an lvalue that refers to a bit- field, the reference is bound to a temporary initialized to hold the value of the bit-field; the reference is not bound to the bit-field directly. See _dcl.init.ref_. ] 4 If the value true or false is stored into a bit-field of type bool of any size (including a one bit bit-field), the original bool value and the value of the bit-field shall compare equal. If the value of an enumerator is stored into a bit-field of the same enumeration type and the number of bits in the bit-field is large enough to hold all the values of that enumeration type, the original enumerator value and the value of the bit-field shall compare equal. [Example: enum BOOL { f=0, t=1 }; struct A { BOOL b:1; }; A a; void f() { a.b = t; if (a.b == t) // shall yield true { /* ... */ } } --end example] 9.7 Nested class declarations [class.nest] 1 A class can be defined within another class. A class defined within another is called a nested class. The name of a nested class is local to its enclosing class. The nested class is in the scope of its enclosing class. Except by using explicit pointers, references, and object names, declarations in a nested class can use only type names, static members, and enumerators from the enclosing class. [Example: int x; int y; class enclose { public: int x; static int s; class inner { void f(int i) { int a = sizeof(x); // error: refers to enclose::x x = i; // error: assign to enclose::x s = i; // OK: assign to enclose::s ::x = i; // OK: assign to global x y = i; // OK: assign to global y } void g(enclose* p, int i) { p->x = i; // OK: assign to enclose::x } }; }; inner* p = 0; // error: inner not in scope --end example] 2 Member functions and static data members of a nested class can be defined in a namespace scope enclosing the definition of their class. [Example: class enclose { public: class inner { static int x; void f(int i); }; }; int enclose::inner::x = 1; void enclose::inner::f(int i) { /* ... */ } --end example] 3 If class X is defined in a namespace scope, a nested class Y may be declared in class X and later defined in the definition of class X or be later defined in a namespace scope enclosing the definition of class X. [Example: class E { class I1; // forward declaration of nested class class I2; class I1 {}; // definition of nested class }; class E::I2 {}; // definition of nested class --end example] 4 Like a member function, a friend function (_class.friend_) defined within a nested class is in the lexical scope of that class; it obeys the same rules for name binding as a static member function of that class (_class.static_) and has no special access rights to members of an enclosing class. 9.8 Local class declarations [class.local] 1 A class can be defined within a function definition; such a class is called a local class. The name of a local class is local to its enclosing scope. The local class is in the scope of the enclosing scope, and has the same access to names outside the function as does the enclosing function. Declarations in a local class can use only type names, static variables, extern variables and functions, and enu- merators from the enclosing scope. [Example: int x; void f() { static int s ; int x; extern int g(); struct local { int g() { return x; } // error: x is auto int h() { return s; } // OK int k() { return ::x; } // OK int l() { return g(); } // OK }; // ... } local* p = 0; // error: local not in scope --end example] 2 An enclosing function has no special access to members of the local class; it obeys the usual access rules (clause _class.access_). Mem- ber functions of a local class shall be defined within their class definition, if they are defined at all. 3 If class X is a local class a nested class Y may be declared in class X and later defined in the definition of class X or be later defined in the same scope as the definition of class X. A class nested within a local class is a local class. 4 A local class shall not have static data members. 9.9 Nested type names [class.nested.type] 1 Type names obey exactly the same scope rules as other names. In par- ticular, type names defined within a class definition cannot be used outside their class without qualification. [Example: class X { public: typedef int I; class Y { /* ... */ }; I a; }; I b; // error Y c; // error X::Y d; // OK X::I e; // OK --end example] ______________________________________________________________________ 10 Derived classes [class.derived] ______________________________________________________________________ 1 A list of base classes can be specified in a class definition using the notation: base-clause: : base-specifier-list base-specifier-list: base-specifier base-specifier-list , base-specifier base-specifier: ::opt nested-name-specifieropt class-name virtual access-specifieropt ::opt nested-name-specifieropt class-name access-specifier virtualopt ::opt nested-name-specifieropt class-name access-specifier: private protected public The class-name in a base-specifier shall not be an incompletely defined class (clause _class_); this class is called a direct base class for the class being declared. During the lookup for a base class name, non-type names are ignored (_basic.scope.hiding_). If the name found is not a class-name, the program is ill-formed. A class B is a base class of a class D if it is a direct base class of D or a direct base class of one of D's base classes. A class is an indirect base class of another if it is a base class but not a direct base class. A class is said to be (directly or indirectly) derived from its (direct or indirect) base classes. [Note: See clause _class.access_ for the meaning of access-specifier. ] Unless rede- fined in the derived class, members of a base class are also consid- ered to be members of the derived class. The base class members are said to be inherited by the derived class. Inherited members can be referred to in expressions in the same manner as other members of the derived class, unless their names are hidden or ambiguous (_class.mem- ber.lookup_). [Note: the scope resolution operator :: (_expr.prim_) can be used to refer to a direct or indirect base member explicitly. This allows access to a name that has been redefined in the derived class. A derived class can itself serve as a base class subject to access control; see _class.access.base_. A pointer to a derived class can be implicitly converted to a pointer to an accessible unambiguous base class (_conv.ptr_). An lvalue of a derived class type can be bound to a reference to an accessible unambiguous base class (_dcl.init.ref_). ] 2 The base-specifier-list specifies the type of the base class subob- jects contained in an object of the derived class type. [Example: class Base { public: int a, b, c; }; class Derived : public Base { public: int b; }; class Derived2 : public Derived { public: int c; }; Here, an object of class Derived2 will have a sub-object of class Derived which in turn will have a sub-object of class Base. ] 3 The order in which the base class subobjects are allocated in the most derived object (_intro.object_) is unspecified. [Note: a derived class and its base class sub-objects can be represented by a directed acyclic graph (DAG) where an arrow means "directly derived from." A DAG of sub-objects is often referred to as a "sub-object lattice." Base | | Derived | Derived2 The arrows need not have a physical representation in memory. ] 4 [Note: initialization of objects representing base classes can be specified in constructors; see _class.base.init_. ] 5 [Note: A base class subobject might have a layout (_basic.stc_) dif- ferent from the layout of a most derived object of the same type. A base class subobject might have a polymorphic behavior (_class.cdtor_) different from the polymorphic behavior of a most derived object of the same type. A base class subobject may be of zero size (clause _class_); however, two subobjects that have the same class type and that belong to the same most derived object must not be allocated at the same address (_expr.eq_). ] 10.1 Multiple base classes [class.mi] 1 A class can be derived from any number of base classes. [Note: the use of more than one direct base class is often called multiple inher- itance. ] [Example: class A { /* ... */ }; class B { /* ... */ }; class C { /* ... */ }; class D : public A, public B, public C { /* ... */ }; --end example] 2 [Note: the order of derivation is not significant except as specified by the semantics of initialization by constructor (_class.base.init_), cleanup (_class.dtor_), and storage layout (_class.mem_, _class.access.spec_). ] 3 A class shall not be specified as a direct base class of a derived class more than once. [Note: a class can be an indirect base class more than once and can be a direct and an indirect base class. There are limited things that can be done with such a class. The non-static data members and member functions of the direct base class cannot be referred to in the scope of the derived class. However, the static members, enumerations and types can be unambiguously referred to. ] [Example: class X { /* ... */ }; class Y : public X, public X { /* ... */ }; // ill-formed class L { public: int next; /* ... */ }; class A : public L { /* ... */ }; class B : public L { /* ... */ }; class C : public A, public B { void f(); /* ... */ }; // well-formed class D : public A, public L { void f(); /* ... */ }; // well-formed --end example] 4 A base class specifier that does not contain the keyword virtual, specifies a nonvirtual base class. A base class specifier that con- tains the keyword virtual, specifies a virtual base class. For each distinct occurrence of a nonvirtual base class in the class lattice of the most derived class, the most derived object (_intro.object_) shall contain a corresponding distinct base class subobject of that type. For each distinct base class that is specified virtual, the most derived object shall contain a single base class subobject of that type. [Example: for an object of class type C, each distinct occur- rence of a (non-virtual) base class L in the class lattice of C corre- sponds one-to-one with a distinct L subobject within the object of type C. Given the class C defined above, an object of class C will have two sub-objects of class L as shown below. L L | | | | A B C In such lattices, explicit qualification can be used to specify which subobject is meant. The body of function C::f could refer to the mem- ber next of each L subobject: void C::f() { A::next = B::next; } // well-formed Without the A:: or B:: qualifiers, the definition of C::f above would be ill-formed because of ambiguity (_class.member.lookup_). 5 For another example, class V { /* ... */ }; class A : virtual public V { /* ... */ }; class B : virtual public V { /* ... */ }; class C : public A, public B { /* ... */ }; for an object c of class type C, a single subobject of type V is shared by every base subobject of c that is declared to have a virtual base class of type V. Given the class C defined above, an object of class C will have one subobject of class V, as shown below. V A B C 6 A class can have both virtual and nonvirtual base classes of a given type. class B { /* ... */ }; class X : virtual public B { /* ... */ }; class Y : virtual public B { /* ... */ }; class Z : public B { /* ... */ }; class AA : public X, public Y, public Z { /* ... */ }; For an object of class AA, all virtual occurrences of base class B in the class lattice of AA correspond to a single B subobject within the object of type AA, and every other occurrence of a (non-virtual) base class B in the class lattice of AA corresponds one-to-one with a dis- tinct B subobject within the object of type AA. Given the class AA defined above, class AA has two sub-objects of class B: Z's B and the virtual B shared by X and Y, as shown below. B B | | X Y Z AA --end example] 10.2 Member name lookup [class.member.lookup] 1 Member name lookup determines the meaning of a name id-expression) in a class scope (_basic.scope.class_). Name lookup can result in an ambiguity, in which case the program is ill-formed. For an id-expres- sion, name lookup begins in the class scope of this; for a qualified- id, name lookup begins in the scope of the nested-name-specifier. Name lookup takes place before access control (_basic.lookup_, clause _class.access_). 2 The following steps define the result of name lookup in a class scope, C. First, every declaration for the name in the class and in each of its base class sub-objects is considered. A member name f in one sub- object B hides a member name f in a sub-object A if A is a base class sub-object of B. Any declarations that are so hidden are eliminated from consideration. Each of these declarations that was introduced by a using-declaration is considered to be from each sub-object of C that is of the type containing the declaration designated by the using-declaration.96) If the resulting set of declarations are not all _________________________ 96) Note that using-declarations cannot be used to resolve inherited from sub-objects of the same type, or the set has a nonstatic member and includes members from distinct sub-objects, there is an ambiguity and the program is ill-formed. Otherwise that set is the result of the lookup. 3 [Example: class A { public: int a; int (*b)(); int f(); int f(int); int g(); }; class B { int a; int b(); public: int f(); int g; int h(); int h(int); }; class C : public A, public B {}; void g(C* pc) { pc->a = 1; // error: ambiguous: A::a or B::a pc->b(); // error: ambiguous: A::b or B::b pc->f(); // error: ambiguous: A::f or B::f pc->f(1); // error: ambiguous: A::f or B::f pc->g(); // error: ambiguous: A::g or B::g pc->g = 1; // error: ambiguous: A::g or B::g pc->h(); // OK pc->h(1); // OK } --end example] [Example: struct U { static int i; }; struct V : U { }; struct W : U { using U::i; }; struct X : V, W { void foo(); }; void X::foo() { i; // finds U::i in two ways: as W::i and U::i in V // no ambiguity because U::i is static } --end example] 4 If the name of an overloaded function is unambiguously found, over- loading resolution (_over.match_) also takes place before access con- trol. Ambiguities can often be resolved by qualifying a name with its class name. [Example: _________________________ member ambiguities; see _namespace.udecl_. class A { public: int f(); }; class B { public: int f(); }; class C : public A, public B { int f() { return A::f() + B::f(); } }; --end example] 5 A static member, a nested type or an enumerator defined in a base class T can unambiguously be found even if an object has more than one base class subobject of type T. Two base class subobjects share the nonstatic member subobjects of their common virtual base classes. [Example: class V { public: int v; }; class A { public: int a; static int s; enum { e }; }; class B : public A, public virtual V {}; class C : public A, public virtual V {}; class D : public B, public C { }; void f(D* pd) { pd->v++; // OK: only one v (virtual) pd->s++; // OK: only one s (static) int i = pd->e; // OK: only one e (enumerator) pd->a++; // error, ambiguous: two as in D } --end example] 6 When virtual base classes are used, a hidden declaration can be reached along a path through the sub-object lattice that does not pass through the hiding declaration. This is not an ambiguity. The iden- tical use with nonvirtual base classes is an ambiguity; in that case there is no unique instance of the name that hides all the others. [Example: class V { public: int f(); int x; }; class W { public: int g(); int y; }; class B : public virtual V, public W { public: int f(); int x; int g(); int y; }; class C : public virtual V, public W { }; class D : public B, public C { void glorp(); }; W V W B C D The names defined in V and the left hand instance of W are hidden by those in B, but the names defined in the right hand instance of W are not hidden at all. void D::glorp() { x++; // OK: B::x hides V::x f(); // OK: B::f() hides V::f() y++; // error: B::y and C's W::y g(); // error: B::g() and C's W::g() } --end example] 7 An explicit or implicit conversion from a pointer to or an lvalue of a derived class to a pointer or reference to one of its base classes shall unambiguously refer to a unique object representing the base class. [Example: class V { }; class A { }; class B : public A, public virtual V { }; class C : public A, public virtual V { }; class D : public B, public C { }; void g() { D d; B* pb = &d; A* pa = &d; // error, ambiguous: C's A or B's A? V* pv = &d; // OK: only one V sub-object } --end example] 10.3 Virtual functions [class.virtual] 1 Virtual functions support dynamic binding and object-oriented program- ming. A class that declares or inherits a virtual function is called a polymorphic class. 2 If a virtual member function vf is declared in a class Base and in a class Derived, derived directly or indirectly from Base, a member function vf with the same name and same parameter list as Base::vf is declared, then Derived::vf is also virtual (whether or not it is so declared) and it overrides97) Base::vf. For convenience we say that _________________________ 97) A function with the same name but a different parameter list (clause _over_) as a virtual function is not necessarily virtual and does not override. The use of the virtual specifier in the declara- tion of an overriding function is legal but redundant (has empty se- mantics). Access control (clause _class.access_) is not considered in any virtual function overrides itself. Then in any well-formed class, for each virtual function declared in that class or any of its direct or indirect base classes there is a unique final overrider that over- rides that function and every other overrider of that function. The rules for member lookup (_class.member.lookup_) are used to determine the final overrider for a virtual function in the scope of a derived class but ignoring names introduced by using-declarations. [Example: struct A { virtual void f(); }; struct B : virtual A { virtual void f(); }; struct C : B , virtual A { using A::f; }; void foo() { C c; c.f(); // calls B::f, the final overrider c.C::f(); // calls A::f because of the using-declaration } --end example] 3 [Note: a virtual member function does not have to be visible to be overridden, for example, struct B { virtual void f(); }; struct D : B { void f(int); }; struct D2 : D { void f(); }; the function f(int) in class D hides the virtual function f() in its base class B; D::f(int) is not a virtual function. However, f() declared in class D2 has the same name and the same parameter list as B::f(), and therefore is a virtual function that overrides the func- tion B::f() even though B::f() is not visible in class D2. ] 4 Even though destructors are not inherited, a destructor in a derived class overrides a base class destructor declared virtual; see _class.dtor_ and _class.free_. 5 The return type of an overriding function shall be either identical to the return type of the overridden function or covariant with the classes of the functions. If a function D::f overrides a function B::f, the return types of the functions are covariant if they satisfy the following criteria: --both are pointers to classes or references to classes98) _________________________ determining overriding. 98) Multi-level pointers to classes or references to multi-level --the class in the return type of B::f is the same class as the class in the return type of D::f or, is an unambiguous direct or indirect base class of the class in the return type of D::f and is accessible in D --both pointers or references have the same cv-qualification and the class type in the return type of D::f has the same cv-qualification as or less cv-qualification than the class type in the return type of B::f. If the return type of D::f differs from the return type of B::f, the class type in the return type of D::f shall be complete at the point of declaration of D::f or shall be the class type D. When the over- riding function is called as the final overrider of the overridden function, its result is converted to the type returned by the (stati- cally chosen) overridden function (_expr.call_). [Example: class B {}; class D : private B { friend class Derived; }; struct Base { virtual void vf1(); virtual void vf2(); virtual void vf3(); virtual B* vf4(); virtual B* vf5(); void f(); }; struct No_good : public Base { D* vf4(); // error: B (base class of D) inaccessible }; class A; struct Derived : public Base { void vf1(); // virtual and overrides Base::vf1() void vf2(int); // not virtual, hides Base::vf2() char vf3(); // error: invalid difference in return type only D* vf4(); // OK: returns pointer to derived class A* vf5(); // error: returns pointer to incomplete class void f(); }; _________________________ pointers to classes are not allowed. void g() { Derived d; Base* bp = &d; // standard conversion: // Derived* to Base* bp->vf1(); // calls Derived::vf1() bp->vf2(); // calls Base::vf2() bp->f(); // calls Base::f() (not virtual) B* p = bp->vf4(); // calls Derived::pf() and converts the // result to B* Derived* dp = &d; D* q = dp->vf4(); // calls Derived::pf() and does not // convert the result to B* dp->vf2(); // ill-formed: argument mismatch } --end example] 6 [Note: the interpretation of the call of a virtual function depends on the type of the object for which it is called (the dynamic type), whereas the interpretation of a call of a nonvirtual member function depends only on the type of the pointer or reference denoting that object (the static type) (_expr.call_). ] 7 [Note: the virtual specifier implies membership, so a virtual function cannot be a nonmember (_dcl.fct.spec_) function. Nor can a virtual function be a static member, since a virtual function call relies on a specific object for determining which function to invoke. A virtual function declared in one class can be declared a friend in another class. ] 8 A virtual function declared in a class shall be defined, or declared pure (_class.abstract_) in that class, or both; but no diagnostic is required (_basic.def.odr_). 9 [Example: here are some uses of virtual functions with multiple base classes: struct A { virtual void f(); }; struct B1 : A { // note non-virtual derivation void f(); }; struct B2 : A { void f(); }; struct D : B1, B2 { // D has two separate A sub-objects }; void foo() { D d; // A* ap = &d; // would be ill-formed: ambiguous B1* b1p = &d; A* ap = b1p; D* dp = &d; ap->f(); // calls D::B1::f dp->f(); // ill-formed: ambiguous } In class D above there are two occurrences of class A and hence two occurrences of the virtual member function A::f. The final overrider of B1::A::f is B1::f and the final overrider of B2::A::f is B2::f. 10The following example shows a function that does not have a unique final overrider: struct A { virtual void f(); }; struct VB1 : virtual A { // note virtual derivation void f(); }; struct VB2 : virtual A { void f(); }; struct Error : VB1, VB2 { // ill-formed }; struct Okay : VB1, VB2 { void f(); }; Both VB1::f and VB2::f override A::f but there is no overrider of both of them in class Error. This example is therefore ill-formed. Class Okay is well formed, however, because Okay::f is a final overrider. 11The following example uses the well-formed classes from above. struct VB1a : virtual A { // does not declare f }; struct Da : VB1a, VB2 { }; void foe() { VB1a* vb1ap = new Da; vb1ap->f(); // calls VB2::f } --end example] 12Explicit qualification with the scope operator (_expr.prim_) sup- presses the virtual call mechanism. [Example: class B { public: virtual void f(); }; class D : public B { public: void f(); }; void D::f() { /* ... */ B::f(); } Here, the function call in D::f really does call B::f and not D::f. ] 10.4 Abstract classes [class.abstract] 1 The abstract class mechanism supports the notion of a general concept, such as a shape, of which only more concrete variants, such as circle and square, can actually be used. An abstract class can also be used to define an interface for which derived classes provide a variety of implementations. 2 An abstract class is a class that can be used only as a base class of some other class; no objects of an abstract class can be created except as sub-objects of a class derived from it. A class is abstract if it has at least one pure virtual function. [Note: such a function might be inherited: see below. ] A virtual function is specified pure by using a pure-specifier (_class.mem_) in the function declaration in the class declaration. A pure virtual function need be defined only if explicitly called with the qualified-id syntax (_expr.prim_). [Example: class point { /* ... */ }; class shape { // abstract class point center; // ... public: point where() { return center; } void move(point p) { center=p; draw(); } virtual void rotate(int) = 0; // pure virtual virtual void draw() = 0; // pure virtual // ... }; --end example] [Note: a function declaration cannot provide both a pure-specifier and a definition --end note] [Example: struct C { virtual void f() { }=0; // ill-formed }; --end example] 3 An abstract class shall not be used as a parameter type, as a function return type, or as the type of an explicit conversion. Pointers and references to an abstract class can be declared. [Example: shape x; // error: object of abstract class shape* p; // OK shape f(); // error void g(shape); // error shape& h(shape&); // OK --end example] 4 A class is abstract if it contains or inherits at least one pure vir- tual function for which the final overrider is pure virtual. [Exam- ple: class ab_circle : public shape { int radius; public: void rotate(int) {} // ab_circle::draw() is a pure virtual }; Since shape::draw() is a pure virtual function ab_circle::draw() is a pure virtual by default. The alternative declaration, class circle : public shape { int radius; public: void rotate(int) {} void draw(); // a definition is required somewhere }; would make class circle nonabstract and a definition of circle::draw() must be provided. ] 5 [Note: an abstract class can be derived from a class that is not abstract, and a pure virtual function may override a virtual function which is not pure. ] 6 Member functions can be called from a constructor (or destructor) of an abstract class; the effect of making a virtual call (_class.vir- tual_) to a pure virtual function directly or indirectly for the object being created (or destroyed) from such a constructor (or destructor) is undefined. ______________________________________________________________________ 11 Member access control [class.access] ______________________________________________________________________ 1 A member of a class can be --private; that is, its name can be used only by members and friends of the class in which it is declared. --protected; that is, its name can be used only by members and friends of the class in which it is declared, and by members and friends of classes derived from this class (see _class.protected_). --public; that is, its name can be used anywhere without access restriction. 2 Members of a class defined with the keyword class are private by default. Members of a class defined with the keywords struct or union are public by default. [Example: class X { int a; // X::a is private by default }; struct S { int a; // S::a is public by default }; --end example] 3 Access control is applied uniformly to all names, whether the names are referred to from declarations or expressions. [Note: access con- trol applies to names nominated by friend declarations (_class.friend_) and using-declarations (_namespace.udecl_). ] In the case of overloaded function names, access control is applied to the function selected by overload resolution. [Note: because access con- trol applies to names, if access control is applied to a typedef name, only the accessibility of the typedef name itself is considered. The accessibility of the entity referred to by the typedef is not consid- ered. For example, class A { class B { }; public: typedef B BB; }; void f() { A::BB x; // OK, typedef name A::BB is public A::B y; // access error, A::B is private } --end note] 4 It should be noted that it is access to members and base classes that is controlled, not their visibility. Names of members are still visi- ble, and implicit conversions to base classes are still considered, when those members and base classes are inaccessible. The interpreta- tion of a given construct is established without regard to access con- trol. If the interpretation established makes use of inaccessible member names or base classes, the construct is ill-formed. 5 All access controls in clause _class.access_ affect the ability to access a class member name from a particular scope. The access con- trol for names used in the definition of a class member that appears outside of the member's class definition is done as if the entire mem- ber definition appeared in the scope of the member's class. In par- ticular, access controls apply as usual to member names accessed as part of a function return type, even though it is not possible to determine the access privileges of that use without first parsing the rest of the function declarator. Similarly, access control for implicit calls to the constructors, the conversion functions, or the destructor called to create and destroy a static data member is per- formed as if these calls appeared in the scope of the member's class. [Example: class A { typedef int I; // private member I f(); friend I g(I); static I x; }; A::I A::f() { return 0; } A::I g(A::I p = A::x); A::I g(A::I p) { return 0; } A::I A::x = 0; Here, all the uses of A::I are well-formed because A::f and A::x are members of class A and g is a friend of class A. This implies, for example, that access checking on the first use of A::I must be deferred until it is determined that this use of A::I is as the return type of a member of class A. ] 6 In the definition of a member of a nested class that appears outside of its class definition, the name of the member may be qualified by the names of enclosing classes of the member's class even if these names are private members of their enclosing classes. [Example: class D { class E { static int m; }; }; int D::E::m = 1; // OK, no access error on private E --end example] 7 The names in a default argument expression (_dcl.fct.default_) are bound at the point of declaration, and access is checked at that point rather than at any points of use of the default argument expression. Access checking for default arguments in function templates and in member functions of class templates are performed as described in _temp.inst_. 11.1 Access specifiers [class.access.spec] 1 Member declarations can be labeled by an access-specifier (clause _class.derived_): access-specifier : member-specificationopt An access-specifier specifies the access rules for members following it until the end of the class or until another access-specifier is encountered. [Example: class X { int a; // X::a is private by default: class used public: int b; // X::b is public int c; // X::c is public }; --end example] Any number of access specifiers is allowed and no par- ticular order is required. [Example: struct S { int a; // S::a is public by default: struct used protected: int b; // S::b is protected private: int c; // S::c is private public: int d; // S::d is public }; --end example] 2 The order of allocation of data members with separate access-specifier labels is unspecified (_class.mem_). 3 When a member is redeclared within its class definition, the access specified at its redeclaration shall be the same as at its initial declaration. [Example: struct S { class A; private: class A { }; // error: cannot change access }; --end example] 11.2 Accessibility of base classes and base [class.access.base] class members 1 If a class is declared to be a base class (clause _class.derived_) for another class using the public access specifier, the public members of the base class are accessible as public members of the derived class and protected members of the base class are accessible as protected members of the derived class. If a class is declared to be a base class for another class using the protected access specifier, the pub- lic and protected members of the base class are accessible as pro- tected members of the derived class. If a class is declared to be a base class for another class using the private access specifier, the public and protected members of the base class are accessible as pri- vate members of the derived class99). 2 In the absence of an access-specifier for a base class, public is assumed when the derived class is declared struct and private is assumed when the class is declared class. [Example: class B { /* ... */ }; class D1 : private B { /* ... */ }; class D2 : public B { /* ... */ }; class D3 : B { /* ... */ }; // B private by default struct D4 : public B { /* ... */ }; struct D5 : private B { /* ... */ }; struct D6 : B { /* ... */ }; // B public by default class D7 : protected B { /* ... */ }; struct D8 : protected B { /* ... */ }; Here B is a public base of D2, D4, and D6, a private base of D1, D3, and D5, and a protected base of D7 and D8. --end example] 3 [Note: A member of a private base class might be inaccessible as an inherited member name, but accessible directly. Because of the rules on pointer conversions (_conv.ptr_) and explicit casts (_expr.cast_), a conversion from a pointer to a derived class to a pointer to an inaccessible base class might be ill-formed if an implicit conversion is used, but well-formed if an explicit cast is used. For example, class B { public: int mi; // nonstatic member static int si; // static member }; class D : private B { }; class DD : public D { void f(); }; _________________________ 99) As specified previously in clause _class.access_, private members of a base class remain inaccessible even to derived classes unless friend declarations within the base class declaration are used to grant access explicitly. void DD::f() { mi = 3; // error: mi is private in D si = 3; // error: si is private in D B b; b.mi = 3; // OK (b.mi is different from this->mi) b.si = 3; // OK (b.si is different from this->si) B::si = 3; // OK B* bp1 = this; // error: B is a private base class B* bp2 = (B*)this; // OK with cast bp2->mi = 3; // OK: access through a pointer to B. } --end note] 4 A base class is said to be accessible if an invented public member of the base class is accessible. If a base class is accessible, one can implicitly convert a pointer to a derived class to a pointer to that base class (_conv.ptr_, _conv.mem_). [Note: it follows that members and friends of a class X can implicitly convert an X* to a pointer to a private or protected immediate base class of X. ] The access to a member is affected by the class in which the member is named. This naming class is the class in which the member name was looked up and found. [Note: this class can be explicit, e.g., when a qualified-id is used, or implicit, e.g., when a class member access operator (_expr.ref_) is used (including cases where an implicit this->" is added. If both a class member access operator and a qualified-id are used to name the member (as in p->T::m), the class naming the member is the class named by the nested-name-specifier of the qualified-id (that is, T). If the member m is accessible when named in the naming class according to the rules below, the access to m is nonetheless ill-formed if the type of p cannot be implicitly converted to type T (for example, if T is an inaccessible base class of p's class). ] A member m is accessible when named in class N if --m as a member of N is public, or --m as a member of N is private, and the reference occurs in a member or friend of class N, or --m as a member of N is protected, and the reference occurs in a mem- ber or friend of class N, or in a member or friend of a class P derived from N, where m as a member of P is private or protected, or --there exists a base class B of N that is accessible at the point of reference, and m is accessible when named in class B. [Example: class B; class A { private: int i; friend void f(B*); }; class B : public A { }; void f(B* p) { p->i = 1; // OK: B* can be implicitly cast to A*, // and f has access to i in A } --end example] 11.3 Access declarations [class.access.dcl] 1 The access of a member of a base class can be changed in the derived class by mentioning its qualified-id in the derived class declaration. Such mention is called an access declaration. The effect of an access declaration qualified-id ; is defined to be equivalent to the declara- tion using qualified-id ;.100) 2 [Example: class A { public: int z; int z1; }; class B : public A { int a; public: int b, c; int bf(); protected: int x; int y; }; _________________________ 100) Access declarations are deprecated; member using-declarations (_namespace.udecl_) provide a better means of doing the same things. In earlier versions of the C++ language, access declarations were more limited; they were generalized and made equivalent to using-declara- tions in the interest of simplicity. Programmers are encouraged to use using-declarations, rather than the new capabilities of access declarations, in new code. class D : private B { int d; public: B::c; // adjust access to B::c B::z; // adjust access to A::z A::z1; // adjust access to A::z1 int e; int df(); protected: B::x; // adjust access to B::x int g; }; class X : public D { int xf(); }; int ef(D&); int ff(X&); The external function ef can use only the names c, z, z1, e, and df. Being a member of D, the function df can use the names b, c, z, z1, bf, x, y, d, e, df, and g, but not a. Being a member of B, the func- tion bf can use the members a, b, c, z, z1, bf, x, and y. The func- tion xf can use the public and protected names from D, that is, c, z, z1, e, and df (public), and x, and g (protected). Thus the external function ff has access only to c, z, z1, e, and df. If D were a pro- tected or private base class of X, xf would have the same privileges as before, but ff would have no access at all. ] 11.4 Friends [class.friend] 1 A friend of a class is a function or class that is not a member of the class but is permitted to use the private and protected member names from the class. The name of a friend is not in the scope of the class, and the friend is not called with the member access operators (_expr.ref_) unless it is a member of another class. [Example: the following example illustrates the differences between members and friends: class X { int a; friend void friend_set(X*, int); public: void member_set(int); }; void friend_set(X* p, int i) { p->a = i; } void X::member_set(int i) { a = i; } void f() { X obj; friend_set(&obj,10); obj.member_set(10); } --end example] 2 Declaring a class to be a friend implies that the names of private and protected members from the class granting friendship can be accessed in declarations of members of the befriended class. [Note: this means that access to private and protected names is also granted to member functions of the friend class (as if the functions were each friends) and to the static data member definitions of the friend class. This also means that private and protected type names from the class grant- ing friendship can be used in the base-clause of a nested class of the friend class. However, the declarations of members of classes nested within the friend class cannot access the names of private and pro- tected members from the class granting friendship. Also, because the base-clause of the friend class is not part of its member declara- tions, the base-clause of the friend class cannot access the names of the private and protected members from the class granting friendship. For example, class A { class B { }; friend class X; }; class X : A::B { // ill-formed: A::B cannot be accessed // in the base-clause for X A::B mx; // OK: A::B used to declare member of X class Y : A::B { // OK: A::B used to declare member of X A::B my; // ill-formed: A::B cannot be accessed // to declare members of nested class of X }; }; ] An elaborated-type-specifier shall be used in a friend declaration for a class.101) A class shall not be defined in a friend declaration. [Example: class X { enum { a=100 }; friend class Y; }; class Y { int v[X::a]; // OK, Y is a friend of X }; class Z { int v[X::a]; // error: X::a is private }; --end example] 3 A function first declared in a friend declaration has external linkage (_basic.link_). Otherwise, the function retains its previous linkage (_dcl.stc_). 4 When a friend declaration refers to an overloaded name or operator, only the function specified by the parameter types becomes a friend. A member function of a class X can be a friend of a class Y. [Exam- ple: _________________________ 101) The class-key of the elaborated-type-specifier is required. class Y { friend char* X::foo(int); // ... }; --end example] 5 A function can be defined in a friend declaration of a class if and only if the class is a non-local class (_class.local_), the function name is unqualified, and the function has namespace scope. [Example: class M { friend void f() { } // definition of global f, a friend of M, // not the definition of a member function }; --end example] Such a function is implicitly inline. A friend func- tion defined in a class is in the (lexical) scope of the class in which it is defined. A friend function defined outside the class is not (_basic.lookup.unqual_). 6 No storage-class-specifier shall appear in the decl-specifier-seq of a friend declaration. 7 A name nominated by a friend declaration shall be accessible in the scope of the class containing the friend declaration. The meaning of the friend declaration is the same whether the friend declaration appears in the private, protected or public (_class.mem_) portion of the class member-specification. 8 Friendship is neither inherited nor transitive. [Example: class A { friend class B; int a; }; class B { friend class C; }; class C { void f(A* p) { p->a++; // error: C is not a friend of A // despite being a friend of a friend } }; class D : public B { void f(A* p) { p->a++; // error: D is not a friend of A // despite being derived from a friend } }; --end example] 9 If a friend declaration appears in a local class (_class.local_) and the name specified is an unqualified name, a prior declaration is looked up without considering scopes that are outside the innermost enclosing non-class scope. For a friend function declaration, if there is no prior declaration, the program is ill-formed. For a friend class declaration, if there is no prior declaration, the class that is specified belongs to the innermost enclosing non-class scope, but if it is subsequently referenced, its name is not found by name lookup until a matching declaration is provided in the innermost enclosing nonclass scope. [Example: class X; void a(); void f() { class Y; extern void b(); class A { friend class X; // OK, but X is a local class, not ::X friend class Y; // OK friend class Z; // OK, introduces local class Z friend void a(); // error, ::a is not considered friend void b(); // OK friend void c(); // error }; X *px; // OK, but ::X is found Z *pz; // error, no Z is found } --end example] 11.5 Protected member access [class.protected] 1 When a friend or a member function of a derived class references a protected nonstatic member of a base class, an access check applies in addition to those described earlier in clause _class.access_.102) Except when forming a pointer to member (_expr.unary.op_), the access must be through a pointer to, reference to, or object of the derived class itself (or any class derived from that class) (_expr.ref_). If the access is to form a pointer to member, the nested-name-specifier shall name the derived class (or any class derived from that class). [Example: class B { protected: int i; static int j; }; class D1 : public B { }; class D2 : public B { friend void fr(B*,D1*,D2*); void mem(B*,D1*); }; _________________________ 102) This additional check does not apply to other members, e.g. static data members or enumerator member constants. void fr(B* pb, D1* p1, D2* p2) { pb->i = 1; // ill-formed p1->i = 2; // ill-formed p2->i = 3; // OK (access through a D2) p2->B::i = 4; // OK (access through a D2, even though // naming class is B) int B::* pmi_B = &B::i; // ill-formed int B::* pmi_B2 = &D2::i; // OK (type of &D2::i is int B::*) B::j = 5; // OK (because refers to static member) D2::j =6; // OK (because refers to static member) } void D2::mem(B* pb, D1* p1) { pb->i = 1; // ill-formed p1->i = 2; // ill-formed i = 3; // OK (access through this) B::i = 4; // OK (access through this, qualification ignored) int B::* pmi_B = &B::i; // ill-formed int B::* pmi_B2 = &D2::i; // OK j = 5; // OK (because j refers to static member) B::j = 6; // OK (because B::j refers to static member) } void g(B* pb, D1* p1, D2* p2) { pb->i = 1; // ill-formed p1->i = 2; // ill-formed p2->i = 3; // ill-formed } --end example] 11.6 Access to virtual functions [class.access.virt] 1 The access rules (clause _class.access_) for a virtual function are determined by its declaration and are not affected by the rules for a function that later overrides it. [Example: class B { public: virtual int f(); }; class D : public B { private: int f(); }; void f() { D d; B* pb = &d; D* pd = &d; pb->f(); // OK: B::f() is public, // D::f() is invoked pd->f(); // error: D::f() is private } --end example] Access is checked at the call point using the type of the expression used to denote the object for which the member function is called B* in the example above). The access of the member function in the class in which it was defined D in the example above) is in general not known. 11.7 Multiple access [class.paths] 1 If a name can be reached by several paths through a multiple inheri- tance graph, the access is that of the path that gives most access. [Example: class W { public: void f(); }; class A : private virtual W { }; class B : public virtual W { }; class C : public A, public B { void f() { W::f(); } // OK }; Since W::f() is available to C::f() along the public path through B, access is allowed. ] 11.8 Nested classes [class.access.nest] 1 The members of a nested class have no special access to members of an enclosing class, nor to classes or functions that have granted friend- ship to an enclosing class; the usual access rules (clause _class.access_) shall be obeyed. The members of an enclosing class have no special access to members of a nested class; the usual access rules (clause _class.access_) shall be obeyed. [Example: class E { int x; class B { }; class I { B b; // error: E::B is private int y; void f(E* p, int i) { p->x = i; // error: E::x is private } }; int g(I* p) { return p->y; // error: I::y is private } }; --end example] 2 [Note: because a base-clause for a nested class is part of the decla- ration of the nested class itself (and not part of the declarations of the members of the nested class), the base-clause may refer to the private members of the enclosing class. For example, class C { class A { }; A *p; // OK class B : A // OK { A *q; // OK because of injection of name A in A C::A *r; // error, C::A is inaccessible B *s; // OK because of injection of name B in B C::B *t; // error, C::B is inaccessible }; }; --end note] ______________________________________________________________________ 12 Special member functions [special] ______________________________________________________________________ 1 The default constructor (_class.ctor_), copy constructor and copy assignment operator (_class.copy_), and destructor (_class.dtor_) are special member functions. The implementation will implicitly declare these member functions for a class type when the program does not explicitly declare them, except as noted in _class.ctor_. The imple- mentation will implicitly define them if they are used, as specified in _class.ctor_, _class.dtor_ and _class.copy_. Programs shall not define implicitly-declared special member functions. Programs may explicitly refer to implicitly declared special member functions. [Example: a program may explicitly call, take the address of or form a pointer to member to an implicitly declared special member function. struct A { }; // implicitly-declared A::operator= struct B : A { B& operator=(const B &); }; B& B::operator=(const B& s) { this->A::operator=(s); // well-formed } --end example] [Note: the special member functions affect the way objects of class type are created, copied, and destroyed, and how val- ues can be converted to values of other types. Often such special member functions are called implicitly. ] 2 Special member functions obey the usual access rules (clause _class.access_). [Example: declaring a constructor protected ensures that only derived classes and friends can create objects using it. ] 12.1 Constructors [class.ctor] 1 Constructors do not have names. A special declarator syntax using an optional function-specifier (_dcl.fct.spec_) followed by the construc- tor's class name followed by a parameter list is used to declare or define the constructor. In such a declaration, optional parentheses around the constructor class name are ignored. [Example: class C { public: C(); // declares the constructor }; C::C() { } // defines the constructor --end example] 2 A constructor is used to initialize objects of its class type. Because constructors do not have names, they are never found during name lookup; however an explicit type conversion using the functional notation (_expr.type.conv_) will cause a constructor to be called to initialize an object. [Note: for initialization of objects of class type see _class.init_. ] 3 A typedef-name that names a class is a class-name (_dcl.typedef_); however, a typedef-name that names a class shall not be used as the identifier in the declarator for a constructor declaration. 4 A constructor shall not be virtual (_class.virtual_) or static (_class.static_). A constructor can be invoked for a const, volatile or const volatile object. A constructor shall not be declared const, volatile, or const volatile (_class.this_). const and volatile seman- tics (_dcl.type.cv_) are not applied on an object under construction. Such semantics only come into effect once the constructor for the most derived object (_intro.object_) ends. 5 A default constructor for a class X is a constructor of class X that can be called without an argument. If there is no user-declared con- structor for class X, a default constructor is implicitly declared. An implicitly-declared default constructor is an inline public member of its class. A constructor is trivial if it is an implicitly- declared default constructor and if: --its class has no virtual functions (_class.virtual_) and no virtual base classes (_class.mi_), and --all the direct base classes of its class have trivial constructors, and --for all the nonstatic data members of its class that are of class type (or array thereof), each such class has a trivial constructor. 6 Otherwise, the constructor is non-trivial. 7 An implicitly-declared default constructor for a class is implicitly defined when it is used to create an object of its class type (_intro.object_). The implicitly-defined default constructor performs the set of initializations of the class that would be performed by a user-written default constructor for that class with an empty mem-ini- tializer-list (_class.base.init_) and an empty function body. If that user-written default constructor would be ill-formed, the program is ill-formed. Before the implicitly-declared default constructor for a class is implicitly defined, all the implicitly-declared default con- structors for its base classes and its nonstatic data members shall have been implicitly defined. [Note: an implicitly-declared default constructor has an exception-specification (_except.spec_). ] 8 Default constructors are called implicitly to create class objects of static or automatic storage duration (_basic.stc.static_, _basic.stc.auto_) defined without an initializer (_dcl.init_), are called to create class objects of dynamic storage duration (_basic.stc.dynamic_) created by a new-expression in which the new- initializer is omitted (_expr.new_), or are called when the explicit type conversion syntax (_expr.type.conv_) is used. A program is ill- formed if the default constructor for an object is implicitly used and the constructor is not accessible (clause _class.access_). 9 [Note: _class.base.init_ describes the order in which constructors for base classes and non-static data members are called and describes how arguments can be specified for the calls to these constructors. ] 10A copy constructor for a class X is a constructor with a first parame- ter of type X& or of type const X&. [Note: see _class.copy_ for more information on copy constructors. ] 11A union member shall not be of a class type (or array thereof) that has a non-trivial constructor. 12No return type (not even void) shall be specified for a constructor. A return statement in the body of a constructor shall not specify a return value. The address of a constructor shall not be taken. 13A functional notation type conversion (_expr.type.conv_) can be used to create new objects of its type. [Note: The syntax looks like an explicit call of the constructor. ] [Example: complex zz = complex(1,2.3); cprint( complex(7.8,1.2) ); --end example] An object created in this way is unnamed. [Note: _class.temporary_ describes the lifetime of temporary objects. ] [Note: explicit constructor calls do not yield lvalues, see _basic.lval_. ] 14[Note: some language constructs have special semantics when used dur- ing construction; see _class.base.init_ and _class.cdtor_. ] 15During the construction of a const object, if the value of the object or any of its subobjects is accessed through an lvalue that is not obtained, directly or indirectly, from the constructor's this pointer, the value of the object or subobject thus obtained is unspecified. [Example: struct C; void no_opt(C*); struct C { int c; C() : c(0) { no_opt(this); } }; const C cobj; void no_opt(C* cptr) { int i = cobj.c * 100; // value of cobj.c is unspecified cptr->c = 1; cout << cobj.c * 100 // value of cobj.c is unspecified << '\n'; } --end example] 12.2 Temporary objects [class.temporary] 1 Temporaries of class type are created in various contexts: binding an rvalue to a reference (_dcl.init.ref_), returning an rvalue (_stmt.return_), a conversion that creates an rvalue (_conv.lval_, _expr.static.cast_, _expr.const.cast_, _expr.cast_), throwing an exception (_except.throw_), entering a handler (_except.handle_), and in some initializations (_dcl.init_). [Note: the lifetime of excep- tion objects is described in _except.throw_. ] Even when the creation of the temporary object is avoided (_class.copy_), all the semantic restrictions must be respected as if the temporary object was created. [Example: even if the copy constructor is not called, all the semantic restrictions, such as accessibility (clause _class.access_), shall be satisfied. ] 2 [Example: class X { // ... public: // ... X(int); X(const X&); ~X(); }; X f(X); void g() { X a(1); X b = f(X(2)); a = f(a); } Here, an implementation might use a temporary in which to construct X(2) before passing it to f() using X's copy-constructor; alterna- tively, X(2) might be constructed in the space used to hold the argu- ment. Also, a temporary might be used to hold the result of f(X(2)) before copying it to b using X's copy-constructor; alternatively, f()'s result might be constructed in b. On the other hand, the expression a=f(a) requires a temporary for either the argument a or the result of f(a) to avoid undesired aliasing of a. ] 3 When an implementation introduces a temporary object of a class that has a non-trivial constructor (_class.ctor_), it shall ensure that a constructor is called for the temporary object. Similarly, the destructor shall be called for a temporary with a non-trivial destruc- tor (_class.dtor_). Temporary objects are destroyed as the last step in evaluating the full-expression (_intro.execution_) that (lexically) contains the point where they were created. This is true even if that evaluation ends in throwing an exception. 4 There are two contexts in which temporaries are destroyed at a differ- ent point than the end of the full-expression. The first context is when an expression appears as an initializer for a declarator defining an object. In that context, the temporary that holds the result of the expression shall persist until the object's initialization is com- plete. The object is initialized from a copy of the temporary; during this copying, an implementation can call the copy constructor many times; the temporary is destroyed after it has been copied, before or when the initialization completes. If many temporaries are created by the evaluation of the initializer, the temporaries are destroyed in reverse order of the completion of their construction. 5 The second context is when a reference is bound to a temporary. The temporary to which the reference is bound or the temporary that is the complete object to a subobject of which the temporary is bound per- sists for the lifetime of the reference except as specified below. A temporary bound to a reference member in a constructor's ctor-initial- izer (_class.base.init_) persists until the constructor exits. A tem- porary bound to a reference parameter in a function call (_expr.call_) persists until the completion of the full expression containing the call. A temporary bound to the returned value in a function return statement (_stmt.return_) persists until the function exits. In all these cases, the temporaries created during the evaluation of the expression initializing the reference, except the temporary to which the reference is bound, are destroyed at the end of the full-expres- sion in which they are created and in the reverse order of the comple- tion of their construction. If the lifetime of two or more tempo- raries to which references are bound ends at the same point, these temporaries are destroyed at that point in the reverse order of the completion of their construction. In addition, the destruction of temporaries bound to references shall take into account the ordering of destruction of objects with static or automatic storage duration (_basic.stc.static_, _basic.stc.auto_); that is, if obj1 is an object with static or automatic storage duration created before the temporary is created, the temporary shall be destroyed before obj1 is destroyed; if obj2 is an object with static or automatic storage duration created after the temporary is created, the temporary shall be destroyed after obj2 is destroyed. [Example: class C { // ... public: C(); C(int); friend C operator+(const C&, const C&); ~C(); }; C obj1; const C& cr = C(16)+C(23); C obj2; the expression C(16)+C(23) creates three temporaries. A first tempo- rary T1 to hold the result of the expression C(16), a second temporary T2 to hold the result of the expression C(23), and a third temporary T3 to hold the result of the addition of these two expressions. The temporary T3 is then bound to the reference cr. It is unspecified whether T1 or T2 is created first. On an implementation where T1 is created before T2, it is guaranteed that T2 is destroyed before T1. The temporaries T1 and T2 are bound to the reference parameters of operator+; these temporaries are destroyed at the end of the full expression containing the call to operator+. The temporary T3 bound to the reference cr is destroyed at the end of cr's lifetime, that is, at the end of the program. In addition, the order in which T3 is destroyed takes into account the destruction order of other objects with static storage duration. That is, because obj1 is constructed before T3, and T3 is constructed before obj2, it is guaranteed that obj2 is destroyed before T3, and that T3 is destroyed before obj1. ] 12.3 Conversions [class.conv] 1 Type conversions of class objects can be specified by constructors and by conversion functions. These conversions are called user-defined conversions and are used for implicit type conversions (clause _conv_), for initialization (_dcl.init_), and for explicit type con- versions (_expr.cast_, _expr.static.cast_). 2 User-defined conversions are applied only where they are unambiguous (_class.member.lookup_, _class.conv.fct_). Conversions obey the access control rules (clause _class.access_). Access control is applied after ambiguity resolution (_basic.lookup_). 3 [Note: See _over.match_ for a discussion of the use of conversions in function calls as well as examples below. ] 4 At most one user-defined conversion (constructor or conversion func- tion) is implicitly applied to a single value. [Example: class X { // ... public: operator int(); }; class Y { // ... public: operator X(); }; Y a; int b = a; // error: // a.operator X().operator int() not tried int c = X(a); // OK: a.operator X().operator int() --end example] 5 User-defined conversions are used implicitly only if they are unam- biguous. A conversion function in a derived class does not hide a conversion function in a base class unless the two functions convert to the same type. Function overload resolution (_over.match.best_) selects the best conversion function to perform the conversion. [Example: class X { public: // ... operator int(); }; class Y : public X { public: // ... operator char(); }; void f(Y& a) { if (a) { // ill-formed: // X::operator int() or Y::operator char() // ... } } --end example] 12.3.1 Conversion by constructor [class.conv.ctor] 1 A constructor declared without the function-specifier explicit that can be called with a single parameter specifies a conversion from the type of its first parameter to the type of its class. Such a con- structor is called a converting constructor. [Example: class X { // ... public: X(int); X(const char*, int =0); }; void f(X arg) { X a = 1; // a = X(1) X b = "Jessie"; // b = X("Jessie",0) a = 2; // a = X(2) f(3); // f(X(3)) } --end example] 2 An explicit constructor constructs objects just like non-explicit con- structors, but does so only where the direct-initialization syntax (_dcl.init_) or where casts (_expr.static.cast_, _expr.cast_) are explicitly used. A default constructor may be an explicit construc- tor; such a constructor will be used to perform default-initialization (_dcl.init_). [Example: class Z { public: explicit Z(); explicit Z(int); // ... }; Z a; // OK: default-initialization performed Z a1 = 1; // error: no implicit conversion Z a3 = Z(1); // OK: direct initialization syntax used Z a2(1); // OK: direct initialization syntax used Z* p = new Z(1); // OK: direct initialization syntax used Z a4 = (Z)1; // OK: explicit cast used Z a5 = static_cast(1); // OK: explicit cast used --end example] 3 A copy-constructor (_class.copy_) is a converting constructor. An implicitly-declared copy constructor is not an explicit constructor; it may be called for implicit type conversions. 12.3.2 Conversion functions [class.conv.fct] 1 A member function of a class X with a name of the form conversion-function-id: operator conversion-type-id conversion-type-id: type-specifier-seq conversion-declaratoropt conversion-declarator: ptr-operator conversion-declaratoropt specifies a conversion from X to the type specified by the conversion- type-id. Such member functions are called conversion functions. Classes, enumerations, and typedef-names shall not be declared in the type-specifier-seq. Neither parameter types nor return type can be specified. The type of a conversion function (_dcl.fct_) is "function taking no parameter returning conversion-type-id." A conversion func- tion is never used to convert a (possibly cv-qualified) object to the (possibly cv-qualified) same object type (or a reference to it), to a (possibly cv-qualified) base class of that type (or a reference to it), or to (possibly cv-qualified) void.103) _________________________ 2 [Example: class X { // ... public: operator int(); }; void f(X a) { int i = int(a); i = (int)a; i = a; } In all three cases the value assigned will be converted by X::operator int(). --end example] 3 User-defined conversions are not restricted to use in assignments and initializations. [Example: void g(X a, X b) { int i = (a) ? 1+a : 0; int j = (a&&b) ? a+b : i; if (a) { // ... } } --end example] 4 The conversion-type-id shall not represent a function type nor an array type. The conversion-type-id in a conversion-function-id is the longest possible sequence of conversion-declarators. [Note: this pre- vents ambiguities between the declarator operator * and its expression counterparts. [Example: &ac.operator int*i; // syntax error: // parsed as: &(ac.operator int *) i // not as: &(ac.operator int)*i The * is the pointer declarator and not the multiplication operator. ] ] 5 Conversion functions are inherited. 6 Conversion functions can be virtual. 12.4 Destructors [class.dtor] 1 A special declarator syntax using an optional function-specifier (_dcl.fct.spec_) followed by ~ followed by the destructor's class name followed by an empty parameter list is used to declare the destructor in a class definition. In such a declaration, the ~ followed by the destructor's class name can be enclosed in optional parentheses; such parentheses are ignored. A typedef-name that names a class is a _________________________ 103) Even though never directly called to perform a conversion, such conversion functions can be declared and can potentially be reached through a call to a virtual conversion function in a base class class-name (_dcl.typedef_); however, a typedef-name that names a class shall not be used as the identifier in the declarator for a destructor declaration. 2 A destructor is used to destroy objects of its class type. A destruc- tor takes no parameters, and no return type can be specified for it (not even void). The address of a destructor shall not be taken. A destructor shall not be static. A destructor can be invoked for a const, volatile or const volatile object. A destructor shall not be declared const, volatile or const volatile (_class.this_). const and volatile semantics (_dcl.type.cv_) are not applied on an object under destruction. Such semantics stop being into effect once the destruc- tor for the most derived object (_intro.object_) starts. 3 If a class has no user-declared destructor, a destructor is declared implicitly. An implicitly-declared destructor is an inline public member of its class. A destructor is trivial if it is an implicitly- declared destructor and if: --all of the direct base classes of its class have trivial destructors and --for all of the non-static data members of its class that are of class type (or array thereof), each such class has a trivial destructor. 4 Otherwise, the destructor is non-trivial. 5 An implicitly-declared destructor is implicitly defined when it is used to destroy an object of its class type (_basic.stc_). A program is ill-formed if the class for which a destructor is implicitly defined has: --a non-static data member of class type (or array thereof) with an inaccessible destructor, or --a base class with an inaccessible destructor. Before the implicitly-declared destructor for a class is implicitly defined, all the implicitly-declared destructors for its base classes and its nonstatic data members shall have been implicitly defined. [Note: an implicitly-declared destructor has an exception-specifica- tion (_except.spec_). ] 6 A destructor for class X calls the destructors for X's direct members, the destructors for X's direct base classes and, if X is the type of the most derived class (_class.base.init_), its destructor calls the destructors for X's virtual base classes. All destructors are called as if they were referenced with a qualified name, that is, ignoring any possible virtual overriding destructors in more derived classes. Bases and members are destroyed in the reverse order of the completion of their constructor (see _class.base.init_). A return statement (_stmt.return_) in a destructor might not directly return to the caller; before transferring control to the caller, the destructors for the members and bases are called. Destructors for elements of an array are called in reverse order of their construction (see _class.init_). 7 A destructor can be declared virtual (_class.virtual_) or pure virtual (_class.abstract_); if any objects of that class or any derived class are created in the program, the destructor shall be defined. If a class has a base class with a virtual destructor, its destructor (whether user- or implicitly- declared) is virtual. 8 [Note: some language constructs have special semantics when used dur- ing destruction; see _class.cdtor_. ] 9 A union member shall not be of a class type (or array thereof) that has a non-trivial destructor. 10Destructors are invoked implicitly (1) for a constructed object with static storage duration (_basic.stc.static_) at program termination (_basic.start.term_), (2) for a constructed object with automatic storage duration (_basic.stc.auto_) when the block in which the object is created exits (_stmt.dcl_), (3) for a constructed temporary object when the lifetime of the temporary object ends (_class.temporary_), (4) for a constructed object allocated by a new-expression (_expr.new_), through use of a delete-expression (_expr.delete_), (5) in several situations due to the handling of exceptions (_except.han- dle_). A program is ill-formed if an object of class type or array thereof is declared and the destructor for the class is not accessible at the point of the declaration. Destructors can also be invoked explicitly. 11At the point of definition of a virtual destructor (including an implicit definition (_class.copy_)), non-placement operator delete shall be looked up in the scope of the destructor's class (_basic.lookup.unqual_) and if found shall be accessible and unambigu- ous. [Note: this assures that an operator delete corresponding to the dynamic type of an object is available for the delete-expression (_class.free_). ] 12In an explicit destructor call, the destructor name appears as a ~ followed by a type-name that names the destructor's class type. The invocation of a destructor is subject to the usual rules for member functions (_class.mfct_), that is, if the object is not of the destructor's class type and not of a class derived from the destruc- tor's class type, the program has undefined behavior (except that invoking delete on a null pointer has no effect). [Example: struct B { virtual ~B() { } }; struct D : B { ~D() { } }; D D_object; typedef B B_alias; B* B_ptr = &D_object; void f() { D_object.B::~B(); // calls B's destructor B_ptr->~B(); // calls D's destructor B_ptr->~B_alias(); // calls D's destructor B_ptr->B_alias::~B(); // calls B's destructor B_ptr->B_alias::~B_alias(); // error, no B_alias in class B } --end example] [Note: an explicit destructor call must always be written using a member access operator (_expr.ref_); in particular, the unary-expression ~X() in a member function is not an explicit destructor call (_expr.unary.op_). ] 13[Note: explicit calls of destructors are rarely needed. One use of such calls is for objects placed at specific addresses using a new- expression with the placement option. Such use of explicit placement and destruction of objects can be necessary to cope with dedicated hardware resources and for writing memory management facilities. For example, void* operator new(size_t, void* p) { return p; } struct X { // ... X(int); ~X(); }; void f(X* p); void g() // rare, specialized use: { char* buf = new char[sizeof(X)]; X* p = new(buf) X(222); // use buf[] and initialize f(p); p->X::~X(); // cleanup } --end note] 14Once a destructor is invoked for an object, the object no longer exists; the behavior is undefined if the destructor is invoked for an object whose lifetime has ended (_basic.life_). [Example: if the destructor for an automatic object is explicitly invoked, and the block is subsequently left in a manner that would ordinarily invoke implicit destruction of the object, the behavior is undefined. ] 15[Note: the notation for explicit call of a destructor can be used for any scalar type name (_expr.pseudo_). Allowing this makes it possible to write code without having to know if a destructor exists for a given type. For example, typedef int I; I* p; // ... p->I::~I(); --end note] 12.5 Free store [class.free] 1 Any allocation function for a class T is a static member (even if not explicitly declared static). 2 [Example: class Arena; struct B { void* operator new(size_t, Arena*); }; struct D1 : B { }; Arena* ap; void foo(int i) { new (ap) D1; // calls B::operator new(size_t, Arena*) new D1[i]; // calls ::operator new[](size_t) new D1; // ill-formed: ::operator new(size_t) hidden } --end example] 3 When an object is deleted with a delete-expression (_expr.delete_), a deallocation function operator delete() for non-array objects or operator delete[]() for arrays) is (implicitly) called to reclaim the storage occupied by the object (_basic.stc.dynamic.deallocation_). 4 If a delete-expression begins with a unary :: operator, the dealloca- tion function's name is looked up in global scope. Otherwise, if the delete-expression is used to deallocate a class object whose static type has a virtual destructor, the deallocation function is the one found by the lookup in the definition of the dynamic type's virtual destructor (_class.dtor_).104) Otherwise, if the delete-expression is used to deallocate an object of class T or array thereof, the static and dynamic types of the object shall be identical and the dealloca- tion function's name is looked up in the scope of T. If this lookup fails to find the name, the name is looked up in the global scope. If the result of the lookup is ambiguous or inaccessible, or if the lookup selects a placement deallocation function, the program is ill- formed. 5 When a delete-expression is executed, the selected deallocation func- tion shall be called with the address of the block of storage to be reclaimed as its first argument and (if the two-parameter style is used) the size of the block as its second argument.105) _________________________ 104) A similar lookup is not needed for the array version of operator delete because _expr.delete_ requires that in this situation, the static type of the delete-expression's operand be the same as its dy- namic type. 105) If the static type in the delete-expression is different from the dynamic type and the destructor is not virtual the size might be in- correct, but that case is already undefined; see _expr.delete_. 6 Any deallocation function for a class X is a static member (even if not explicitly declared static). [Example: class X { // ... void operator delete(void*); void operator delete[](void*, size_t); }; class Y { // ... void operator delete(void*, size_t); void operator delete[](void*); }; --end example] 7 Since member allocation and deallocation functions are static they cannot be virtual. [Note: however, when the cast-expression of a delete-expression refers to an object of class type, because the deal- location function actually called is looked up in the scope of the class that is the dynamic type of the object, if the destructor is virtual, the effect is the same. For example, struct B { virtual ~B(); void operator delete(void*, size_t); }; struct D : B { void operator delete(void*); }; void f() { B* bp = new D; delete bp; //1: uses D::operator delete(void*) } Here, storage for the non-array object of class D is deallocated by D::operator delete(), due to the virtual destructor. ] [Note: virtual destructors have no effect on the deallocation function actually called when the cast-expression of a delete-expression refers to an array of objects of class type. For example, struct B { virtual ~B(); void operator delete[](void*, size_t); }; struct D : B { void operator delete[](void*, size_t); }; void f(int i) { D* dp = new D[i]; delete [] dp; // uses D::operator delete[](void*, size_t) B* bp = new D[i]; delete[] bp; // undefined behavior } --end note] 8 Access to the deallocation function is checked statically. Hence, even though a different one might actually be executed, the statically visible deallocation function is required to be accessible. [Example: for the call on line //1 above, if B::operator delete() had been pri- vate, the delete expression would have been ill-formed. ] 12.6 Initialization [class.init] 1 When no initializer is specified for an object of (possibly cv-quali- fied) class type (or array thereof), or the initializer has the form (), the object is initialized as specified in _dcl.init_. [Note: if the class is a non-POD, it is default-initialized. ] 2 An object of class type (or array thereof) can be explicitly initial- ized; see _class.expl.init_ and _class.base.init_. 3 When an array of class objects is initialized (either explicitly or implicitly), the constructor shall be called for each element of the array, following the subscript order; see _dcl.array_. [Note: destructors for the array elements are called in reverse order of their construction. ] 12.6.1 Explicit initialization [class.expl.init] 1 An object of class type can be initialized with a parenthesized expression-list, where the expression-list is construed as an argument list for a constructor that is called to initialize the object. Alternatively, a single assignment-expression can be specified as an initializer using the = form of initialization. Either direct-ini- tialization semantics or copy-initialization semantics apply; see _dcl.init_. [Example: class complex { // ... public: complex(); complex(double); complex(double,double); // ... }; complex sqrt(complex,complex); complex a(1); // initialize by a call of // complex(double) complex b = a; // initialize by a copy of a complex c = complex(1,2); // construct complex(1,2) // using complex(double,double) // copy it into c complex d = sqrt(b,c); // call sqrt(complex,complex) // and copy the result into d complex e; // initialize by a call of // complex() complex f = 3; // construct complex(3) using // complex(double) // copy it into f complex g = { 1, 2 }; // error; constructor is required --end example] [Note: overloading of the assignment operator (_over.ass_) has no effect on initialization. ] 2 When an aggregate (whether class or array) contains members of class type and is initialized by a brace-enclosed initializer-list (_dcl.init.aggr_), each such member is copy-initialized (see _dcl.init_) by the corresponding assignment-expression. If there are fewer initializers in the initializer-list than members of the aggre- gate, each member not explicitly initialized shall be default-initial- ized (_dcl.init_). [Note: _dcl.init.aggr_ describes how assignment- expressions in an initializer-list are paired with the aggregate mem- bers they initialize. ] [Example: complex v[6] = { 1,complex(1,2),complex(),2 }; Here, complex::complex(double) is called for the initialization of v[0] and v[3], complex::complex(double,double) is called for the ini- tialization of v[1], complex::complex() is called for the initializa- tion v[2], v[4], and v[5]. For another example, class X { public: int i; float f; complex c; } x = { 99, 88.8, 77.7 }; Here, x.i is initialized with 99, x.f is initialized with 88.8, and complex::complex(double) is called for the initialization of x.c. ] [Note: braces can be elided in the initializer-list for any aggregate, even if the aggregate has members of a class type with user-defined type conversions; see _dcl.init.aggr_. ] 3 [Note: if T is a class type with no default constructor, any declara- tion of an object of type T (or array thereof) is ill-formed if no initializer is explicitly specified (see _class.init_ and _dcl.init_). ] 4 [Note: the order in which objects with static storage duration are initialized is described in _basic.start.init_ and _stmt.dcl_. ] 12.6.2 Initializing bases and members [class.base.init] 1 In the definition of a constructor for a class, initializers for direct and virtual base subobjects and nonstatic data members can be specified by a ctor-initializer, which has the form ctor-initializer: : mem-initializer-list mem-initializer-list: mem-initializer mem-initializer , mem-initializer-list mem-initializer: mem-initializer-id ( expression-listopt ) mem-initializer-id: ::opt nested-name-specifieropt class-name identifier 2 Names in a mem-initializer-id are looked up in the scope of the con- structor's class and, if not found in that scope, are looked up in the scope containing the constructor's definition. [Note: if the con- structor's class contains a member with the same name as a direct or virtual base class of the class, a mem-initializer-id naming the mem- ber or base class and composed of a single identifier refers to the class member. A mem-initializer-id for the hidden base class may be specified using a qualified name. ] Unless the mem-initializer-id names a nonstatic data member of the constructor's class or a direct or virtual base of that class, the mem-initializer is ill-formed. A mem-initializer-list can initialize a base class using any name that denotes that base class type. [Example: struct A { A(); }; typedef A global_A; struct B { }; struct C: public A, public B { C(); }; C::C(): global_A() { } // mem-initializer for base A --end example] If a mem-initializer-id is ambiguous because it desig- nates both a direct non-virtual base class and an inherited virtual base class, the mem-initializer is ill-formed. [Example: struct A { A(); }; struct B: public virtual A { }; struct C: public A, public B { C(); }; C::C(): A() { } // ill-formed: which A? --end example] A ctor-initializer may initialize the member of an anonymous union that is a member of the constructor's class. If a ctor-initializer specifies more than one mem-initializer for the same member, for the same base class or for multiple members of the same union (including members of anonymous unions), the ctor-initializer is ill-formed. 3 The expression-list in a mem-initializer is used to initialize the base class or nonstatic data member subobject denoted by the mem-ini- tializer-id. The semantics of a mem-initializer are as follows: --if the expression-list of the mem-initializer is omitted, the base class or member subobject is default-initialized (see _dcl.init_); --otherwise, the subobject indicated by mem-initializer-id is direct- initialized using expression-list as the initializer (see _dcl.init_). [Example: struct B1 { B1(int); /* ... */ }; struct B2 { B2(int); /* ... */ }; struct D : B1, B2 { D(int); B1 b; const int c; }; D::D(int a) : B2(a+1), B1(a+2), c(a+3), b(a+4) { /* ... */ } D d(10); --end example] There is a sequence point (_intro.execution_) after the initialization of each base and member. The expression-list of a mem-initializer is evaluated as part of the initialization of the cor- responding base or member. 4 If a given nonstatic data member or base class is not named by a mem- initializer-id (including the case where there is no mem-initializer- list because the constructor has no ctor-initializer), then --If the entity is a nonstatic data member of (possibly cv-qualified) class type (or array thereof) or a base class, and the entity class is a non-POD class, the entity is default-initialized (_dcl.init_). If the entity is a nonstatic data member of a const-qualified type, the entity class shall have a user-declared default constructor. --Otherwise, the entity is not initialized. If the entity is of const-qualified type or reference type, or of a (possibly cv-quali- fied) POD class type (or array thereof) containing (directly or indirectly) a member of a const-qualified type, the program is ill- formed. After the call to a constructor for class X has completed, if a member of X is neither specified in the constructor's mem-initializers, nor default-initialized, nor initialized during execution of the body of the constructor, the member has indeterminate value. 5 Initialization shall proceed in the following order: --First, and only for the constructor of the most derived class as described below, virtual base classes shall be initialized in the order they appear on a depth-first left-to-right traversal of the directed acyclic graph of base classes, where "left-to-right" is the order of appearance of the base class names in the derived class base-specifier-list. --Then, direct base classes shall be initialized in declaration order as they appear in the base-specifier-list (regardless of the order of the mem-initializers). --Then, nonstatic data members shall be initialized in the order they were declared in the class definition (again regardless of the order of the mem-initializers). --Finally, the body of the constructor is executed. [Note: the declaration order is mandated to ensure that base and mem- ber subobjects are destroyed in the reverse order of initialization. ] 6 All sub-objects representing virtual base classes are initialized by the constructor of the most derived class (_intro.object_). If the constructor of the most derived class does not specify a mem-initial- izer for a virtual base class V, then V's default constructor is called to initialize the virtual base class subobject. If V does not have an accessible default constructor, the initialization is ill- formed. A mem-initializer naming a virtual base class shall be ignored during execution of the constructor of any class that is not the most derived class. [Example: class V { public: V(); V(int); // ... }; class A : public virtual V { public: A(); A(int); // ... }; class B : public virtual V { public: B(); B(int); // ... }; class C : public A, public B, private virtual V { public: C(); C(int); // ... }; A::A(int i) : V(i) { /* ... */ } B::B(int i) { /* ... */ } C::C(int i) { /* ... */ } V v(1); // use V(int) A a(2); // use V(int) B b(3); // use V() C c(4); // use V() --end example] 7 Names in the expression-list of a mem-initializer are evaluated in the scope of the constructor for which the mem-initializer is specified. [Example: class X { int a; int b; int i; int j; public: const int& r; X(int i): r(a), b(i), i(i), j(this->i) {} }; initializes X::r to refer to X::a, initializes X::b with the value of the constructor parameter i, initializes X::i with the value of the constructor parameter i, and initializes X::j with the value of X::i; this takes place each time an object of class X is created. ] [Note: because the mem-initializer are evaluated in the scope of the con- structor, the this pointer can be used in the expression-list of a mem-initializer to refer to the object being initialized. ] 8 Member functions (including virtual member functions, _class.virtual_) can be called for an object under construction. Similarly, an object under construction can be the operand of the typeid operator (_expr.typeid_) or of a dynamic_cast (_expr.dynamic.cast_). However, if these operations are performed in a ctor-initializer (or in a func- tion called directly or indirectly from a ctor-initializer) before all the mem-initializers for base classes have completed, the result of the operation is undefined. [Example: class A { public: A(int); }; class B : public A { int j; public: int f(); B() : A(f()), // undefined: calls member function // but base A not yet initialized j(f()) { } // well-defined: bases are all initialized }; class C { public: C(int); }; class D : public B, C { int i; public: D() : C(f()), // undefined: calls member function // but base C not yet initialized i(f()) {} // well-defined: bases are all initialized }; --end example] 9 [Note: _class.cdtor_ describes the result of virtual function calls, typeid and dynamic_casts during construction for the well-defined cases; that is, describes the polymorphic behavior of an object under construction. ] 12.7 Construction and destruction [class.cdtor] 1 For an object of non-POD class type (clause _class_), before the con- structor begins execution and after the destructor finishes execution, referring to any nonstatic member or base class of the object results in undefined behavior. [Example: struct X { int i; }; struct Y : X { }; struct A { int a; }; struct B : public A { int j; Y y; }; extern B bobj; B* pb = &bobj; // OK int* p1 = &bobj.a; // undefined, refers to base class member int* p2 = &bobj.y.i; // undefined, refers to member's member A* pa = &bobj; // undefined, upcast to a base class type B bobj; // definition of bobj extern X xobj; int* p3 = &xobj.i; // OK, X is a POD class X xobj; For another example, struct W { int j; }; struct X : public virtual W { }; struct Y { int *p; X x; Y() : p(&x.j) // undefined, x is not yet constructed { } }; --end example] 2 To explicitly or implicitly convert a pointer (an lvalue) referring to an object of class X to a pointer (reference) to a direct or indirect base class B of X, the construction of X and the construction of all of its direct or indirect bases that directly or indirectly derive from B shall have started and the destruction of these classes shall not have completed, otherwise the conversion results in undefined behavior. To form a pointer to (or access the value of) a direct non- static member of an object obj, the construction of obj shall have started and its destruction shall not have completed, otherwise the computation of the pointer value (or accessing the member value) results in undefined behavior. [Example: struct A { }; struct B : virtual A { }; struct C : B { }; struct D : virtual A { D(A*); }; struct X { X(A*); }; struct E : C, D, X { E() : D(this), // undefined: upcast from E* to A* // might use path E* -> D* -> A* // but D is not constructed // D((C*)this), // defined: // E* -> C* defined because E() has started // and C* -> A* defined because // C fully constructed X(this) // defined: upon construction of X, // C/B/D/A sublattice is fully constructed { } }; --end example] 3 Member functions, including virtual functions (_class.virtual_), can be called during construction or destruction (_class.base.init_). When a virtual function is called directly or indirectly from a con- structor (including from the mem-initializer for a data member) or from a destructor, and the object to which the call applies is the object under construction or destruction, the function called is the one defined in the constructor or destructor's own class or in one of its bases, but not a function overriding it in a class derived from the constructor or destructor's class, or overriding it in one of the other base classes of the most derived object (_intro.object_). If the virtual function call uses an explicit class member access (_expr.ref_) and the object-expression refers to the object under con- struction or destruction but its type is neither the constructor or destructor's own class or one of its bases, the result of the call is undefined. [Example: class V { public: virtual void f(); virtual void g(); }; class A : public virtual V { public: virtual void f(); }; class B : public virtual V { public: virtual void g(); B(V*, A*); }; class D : public A, B { public: virtual void f(); virtual void g(); D() : B((A*)this, this) { } }; B::B(V* v, A* a) { f(); // calls V::f, not A::f g(); // calls B::g, not D::g v->g(); // v is base of B, the call is well-defined, calls B::g a->f(); // undefined behavior, a's type not a base of B } --end example] 4 The typeid operator (_expr.typeid_) can be used during construction or destruction (_class.base.init_). When typeid is used in a constructor (including from the mem-initializer for a data member) or in a destructor, or used in a function called (directly or indirectly) from a constructor or destructor, if the operand of typeid refers to the object under construction or destruction, typeid yields the type_info representing the constructor or destructor's class. If the operand of typeid refers to the object under construction or destruction and the static type of the operand is neither the constructor or destructor's class nor one of its bases, the result of typeid is undefined. 5 Dynamic_casts (_expr.dynamic.cast_) can be used during construction or destruction (_class.base.init_). When a dynamic_cast is used in a constructor (including from the mem-initializer for a data member) or in a destructor, or used in a function called (directly or indirectly) from a constructor or destructor, if the operand of the dynamic_cast refers to the object under construction or destruction, this object is considered to be a most derived object that has the type of the con- structor or destructor's class. If the operand of the dynamic_cast refers to the object under construction or destruction and the static type of the operand is not a pointer to or object of the constructor or destructor's own class or one of its bases, the dynamic_cast results in undefined behavior. 6 [Example: class V { public: virtual void f(); }; class A : public virtual V { }; class B : public virtual V { public: B(V*, A*); }; class D : public A, B { public: D() : B((A*)this, this) { } }; B::B(V* v, A* a) { typeid(*this); // type_info for B typeid(*v); // well-defined: *v has type V, a base of B // yields type_info for B typeid(*a); // undefined behavior: type A not a base of B dynamic_cast(v); // well-defined: v of type V*, V base of B // results in B* dynamic_cast(a); // undefined behavior, // a has type A*, A not a base of B } --end example] 12.8 Copying class objects [class.copy] 1 A class object can be copied in two ways, by initialization (_class.ctor_, _dcl.init_), including for function argument passing (_expr.call_) and for function value return (_stmt.return_), and by assignment (_expr.ass_). Conceptually, these two operations are implemented by a copy constructor (_class.ctor_) and copy assignment operator (_over.ass_). 2 A non-template constructor for class X is a copy constructor if its first parameter is of type X&, const X&, volatile X& or const volatile X&, and either there are no other parameters or else all other parame- ters have default arguments (_dcl.fct.default_).106) [Example: X::X(const X&) and X::X(X&, int=1) are copy constructors. class X { // ... public: X(int); X(const X&, int = 1); }; X a(1); // calls X(int); X b(a, 0); // calls X(const X&, int); X c = b; // calls X(const X&, int); --end example] [Note: all forms of copy constructor may be declared for a class. [Example: class X { // ... public: X(const X&); X(X&); // OK }; --end example] --end note] [Note: if a class X only has a copy con- structor with a parameter of type X&, an initializer of type const X or volatile X cannot initialize an object of type (possibily cv- _________________________ 106) Because a template constructor is never a copy constructor, the presence of such a template does not suppress the implicit declaration of a copy constructor. Template constructors participate in overload resolution with other constructors, including copy constructors, and a template constructor may be used to copy an object if it provides a better match than other constructors. qualified) X. [Example: struct X { X(); // default constructor X(X&); // copy constructor with a nonconst parameter }; const X cx; X x = cx; // error - X::X(X&) cannot copy cx into x --end example] --end note] 3 A declaration of a constructor for a class X is ill-formed if its first parameter is of type (optionally cv-qualified) X and either there are no other parameters or else all other parameters have default arguments. A member function template is never instantiated to perform the copy of a class object to an object of its class type. [Example: struct S { template S(T); }; S f(); void g() { S a( f() ); // does not instantiate member template } --end example] 4 If the class definition does not explicitly declare a copy construc- tor, one is declared implicitly. Thus, for the class definition struct X { X(const X&, int); }; a copy constructor is implicitly-declared. If the user-declared con- structor is later defined as X::X(const X& x, int i =0) { /* ... */ } then any use of X's copy constructor is ill-formed because of the ambiguity; no diagnostic is required. 5 The implicitly-declared copy constructor for a class X will have the form X::X(const X&) if --each direct or virtual base class B of X has a copy constructor whose first parameter is of type const B& or const volatile B&, and --for all the nonstatic data members of X that are of a class type M (or array thereof), each such class type has a copy constructor whose first parameter is of type const M& or const volatile M&.107) _________________________ 107) This implies that the reference parameter of the implicitly-de- clared copy constructor cannot bind to a volatile lvalue; see _diff.special_. Otherwise, the implicitly declared copy constructor will have the form X::X(X&) An implicitly-declared copy constructor is an inline public member of its class. 6 A copy constructor for class X is trivial if it is implicitly declared and if --class X has no virtual functions (_class.virtual_) and no virtual base classes (_class.mi_), and --each direct base class of X has a trivial copy constructor, and --for all the nonstatic data members of X that are of class type (or array thereof), each such class type has a trivial copy constructor; otherwise the copy constructor is non-trivial. 7 An implicitly-declared copy constructor is implicitly defined if it is used to initialize an object of its class type from a copy of an object of its class type or of a class type derived from its class type108). [Note: the copy constructor is implicitly defined even if the implementation elided its use (_class.temporary_). ] A program is ill-formed if the class for which a copy constructor is implicitly defined has: --a nonstatic data member of class type (or array thereof) with an inaccessible or ambiguous copy constructor, or --a base class with an inaccessible or ambiguous copy constructor. Before the implicitly-declared copy constructor for a class is implic- itly defined, all implicitly-declared copy constructors for its direct and virtual base classes and its nonstatic data members shall have been implicitly defined. [Note: an implicitly-declared copy construc- tor has an exception-specification (_except.spec_). ] 8 The implicitly-defined copy constructor for class X performs a member- wise copy of its subobjects. The order of copying is the same as the order of initialization of bases and members in a user-defined con- structor (see _class.base.init_). Each subobject is copied in the manner appropriate to its type: --if the subobject is of class type, the copy constructor for the class is used; --if the subobject is an array, each element is copied, in the manner appropriate to the element type; --if the subobject is of scalar type, the built-in assignment operator _________________________ 108) See _dcl.init_ for more details on direct and copy initializa- tion. is used. Virtual base class subobjects shall be copied only once by the implic- itly-defined copy constructor (see _class.base.init_). 9 A user-declared copy assignment operator X::operator= is a non-static non-template member function of class X with exactly one parameter of type X, X&, const X&, volatile X& or const volatile X&.109) [Note: an overloaded assignment operator must be declared to have only one parameter; see _over.ass_. ] [Note: more than one form of copy assignment operator may be declared for a class. ] [Note: if a class X only has a copy assignment operator with a parameter of type X&, an expression of type const X cannot be assigned to an object of type X. [Example: struct X { X(); X& operator=(X&); }; const X cx; X x; void f() { x = cx; // error: // X::operator=(X&) cannot assign cx into x } --end example] --end note] 10If the class definition does not explicitly declare a copy assignment operator, one is declared implicitly. The implicitly-declared copy assignment operator for a class X will have the form X& X::operator=(const X&) if --each direct base class B of X has a copy assignment operator whose parameter is of type const B&, const volatile B& or B, and --for all the nonstatic data members of X that are of a class type M (or array thereof), each such class type has a copy assignment oper- ator whose parameter is of type const M&, const volatile M& or M.110) Otherwise, the implicitly declared copy constructor will have the form X& X::operator=(X&) _________________________ 109) Because a template assignment operator is never a copy assignment operator, the presence of such a template does not suppress the im- plicit declaration of a copy assignment operator. Template assignment operators participate in overload resolution with other assignment op- erators, including copy assignment operators, and a template assign- ment operator may be used to assign an object if it provides a better match than other assignment operators. 110) This implies that the reference parameter of the implicitly-de- clared copy assignment operator cannot bind to a volatile lvalue; see _diff.special_. The implicitly-declared copy assignment operator for class X has the return type X&; it returns the object for which the assignment opera- tor is invoked, that is, the object assigned to. An implicitly- declared copy assignment operator is an inline public member of its class. Because a copy assignment operator is implicitly declared for a class if not declared by the user, a base class copy assignment operator is always hidden by the copy assignment operator of a derived class (_over.ass_). A using-declaration (_namespace.udecl_) that brings in from a base class an assignment operator with a parameter type that could be that of a copy-assignment operator for the derived class is not considered an explicit declaration of a copy-assignment operator and does not suppress the implicit declaration of the derived class copy-assignment operator; the operator introduced by the using- declaration is hidden by the implicitly-declared copy-assignment oper- ator in the derived class. 11A copy assignment operator for class X is trivial if it is implicitly declared and if --class X has no virtual functions (_class.virtual_) and no virtual base classes (_class.mi_), and --each direct base class of X has a trivial copy assignment operator, and --for all the nonstatic data members of X that are of class type (or array thereof), each such class type has a trivial copy assignment operator; otherwise the copy assignment operator is non-trivial. 12An implicitly-declared copy assignment operator is implicitly defined when an object of its class type is assigned a value of its class type or a value of a class type derived from its class type. A program is ill-formed if the class for which a copy assignment operator is implicitly defined has: --a nonstatic data member of const type, or --a nonstatic data member of reference type, or --a nonstatic data member of class type (or array thereof) with an inaccessible copy assignment operator, or --a base class with an inaccessible copy assignment operator. Before the implicitly-declared copy assignment operator for a class is implicitly defined, all implicitly-declared copy assignment operators for its direct base classes and its nonstatic data members shall have been implicitly defined. [Note: an implicitly-declared copy assign- ment operator has an exception-specification (_except.spec_). ] 13The implicitly-defined copy assignment operator for class X performs memberwise assignment of its subobjects. The direct base classes of X are assigned first, in the order of their declaration in the base- specifier-list, and then the immediate nonstatic data members of X are assigned, in the order in which they were declared in the class defi- nition. Each subobject is assigned in the manner appropriate to its type: --if the subobject is of class type, the copy assignment operator for the class is used (as if by explicit qualification; that is, ignor- ing any possible virtual overriding functions in more derived classes); --if the subobject is an array, each element is assigned, in the man- ner appropriate to the element type; --if the subobject is of scalar type, the built-in assignment operator is used. It is unspecified whether subobjects representing virtual base classes are assigned more than once by the implicitly-defined copy assignment operator. [Example: struct V { }; struct A : virtual V { }; struct B : virtual V { }; struct C : B, A { }; it is unspecified whether the virtual base class subobject V is assigned twice by the implicitly-defined copy assignment operator for C. --end example] 14A program is ill-formed if the copy constructor or the copy assignment operator for an object is implicitly used and the special member func- tion is not accessible (clause _class.access_). [Note: Copying one object into another using the copy constructor or the copy assignment operator does not change the layout or size of either object. ] 15Whenever a temporary class object is copied using a copy constructor, and this object and the copy have the same cv-unqualified type, an implementation is permitted to treat the original and the copy as two different ways of referring to the same object and not perform a copy at all, even if the class copy constructor or destructor have side effects. For a function with a class return type, if the expression in the return statement is the name of a local object, and the cv- unqualified type of the local object is the same as the function return type, an implementation is permitted to omit creating the tem- porary object to hold the function return value, even if the class copy constructor or destructor has side effects. In these cases, the object is destroyed at the later of times when the original and the copy would have been destroyed without the optimization.111) [Example: _________________________ 111) Because only one object is destroyed instead of two, and one copy constructor is not executed, there is still one object destroyed for each one constructed. class Thing { public: Thing(); ~Thing(); Thing(const Thing&); Thing operator=(const Thing&); void fun(); }; Thing f() { Thing t; return t; } Thing t2 = f(); Here t does not need to be copied when returning from f. The return value of f may be constructed directly into the object t2. ] ______________________________________________________________________ 13 Overloading [over] ______________________________________________________________________ 1 When two or more different declarations are specified for a single name in the same scope, that name is said to be overloaded. By exten- sion, two declarations in the same scope that declare the same name but with different types are called overloaded declarations. Only function declarations can be overloaded; object and type declarations cannot be overloaded. 2 When an overloaded function name is used in a call, which overloaded function declaration is being referenced is determined by comparing the types of the arguments at the point of use with the types of the parameters in the overloaded declarations that are visible at the point of use. This function selection process is called overload res- olution and is defined in _over.match_. [Example: double abs(double); int abs(int); abs(1); // call abs(int); abs(1.0); // call abs(double); --end example] 13.1 Overloadable declarations [over.load] 1 Not all function declarations can be overloaded. Those that cannot be overloaded are specified here. A program is ill-formed if it contains two such non-overloadable declarations in the same scope. [Note: this restriction applies to explicit declarations in a scope, and between such declarations and declarations made through a using-declaration (_namespace.udecl_). It does not apply to sets of functions fabri- cated as a result of name lookup (e.g., because of using-directives) or overload resolution (e.g., for operator functions). ] 2 Certain function declarations cannot be overloaded: --Function declarations that differ only in the return type cannot be overloaded. --Member function declarations with the same name and the same parame- ter types cannot be overloaded if any of them is a static member function declaration (_class.static_). Likewise, member function template declarations with the same name, the same parameter types, and the same template parameter lists cannot be overloaded if any of them is a static member function template declaration. The types of the implicit object parameters constructed for the member functions for the purpose of overload resolution (_over.match.funcs_) are not considered when comparing parameter types for enforcement of this rule. In contrast, if there is no static member function declara- tion among a set of member function declarations with the same name and the same parameter types, then these member function declara- tions can be overloaded if they differ in the type of their implicit object parameter. [Example: the following illustrates this distinc- tion: class X { static void f(); void f(); // ill-formed void f() const; // ill-formed void f() const volatile; // ill-formed void g(); void g() const; // OK: no static g void g() const volatile; // OK: no static g }; --end example] 3 [Note: as specified in _dcl.fct_, function declarations that have equivalent parameter declarations declare the same function and there- fore cannot be overloaded: --Parameter declarations that differ only in the use of equivalent typedef "types" are equivalent. A typedef is not a separate type, but only a synonym for another type (_dcl.typedef_). [Example: typedef int Int; void f(int i); void f(Int i); // OK: redeclaration of f(int) void f(int i) { /* ... */ } void f(Int i) { /* ... */ } // error: redefinition of f(int) --end example] Enumerations, on the other hand, are distinct types and can be used to distinguish overloaded function declarations. [Example: enum E { a }; void f(int i) { /* ... */ } void f(E i) { /* ... */ } --end example] --Parameter declarations that differ only in a pointer * versus an array [] are equivalent. That is, the array declaration is adjusted to become a pointer declaration (_dcl.fct_). Only the second and subsequent array dimensions are significant in parameter types (_dcl.array_). [Example: int f(char*); int f(char[]); // same as f(char*); int f(char[7]); // same as f(char*); int f(char[9]); // same as f(char*); int g(char(*)[10]); int g(char[5][10]); // same as g(char(*)[10]); int g(char[7][10]); // same as g(char(*)[10]); int g(char(*)[20]); // different from g(char(*)[10]); --end example] --Parameter declarations that differ only in that one is a function type and the other is a pointer to the same function type are equiv- alent. That is, the function type is adjusted to become a pointer to function type (_dcl.fct_). [Example: void h(int()); void h(int (*)()); // redeclaration of h(int()) void h(int x()) { } // definition of h(int()) void h(int (*x)()) { } // ill-formed: redefinition of h(int()) ] --Parameter declarations that differ only in the presence or absence of const and/or volatile are equivalent. That is, the const and volatile type-specifiers for each parameter type are ignored when determining which function is being declared, defined, or called. [Example: typedef const int cInt; int f (int); int f (const int); // redeclaration of f(int) int f (int) { ... } // definition of f(int) int f (cInt) { ... } // error: redefinition of f(int) --end example] Only the const and volatile type-specifiers at the outermost level of the parameter type specification are ignored in this fashion; const and volatile type-specifiers buried within a parameter type specification are significant and can be used to distinguish over- loaded function declarations.112) In particular, for any type T, "pointer to T," "pointer to const T," and "pointer to volatile T" are considered distinct parameter types, as are "reference to T," "reference to const T," and "reference to volatile T." --Two parameter declarations that differ only in their default argu- ments are equivalent. [Example: consider the following: void f (int i, int j); void f (int i, int j = 99); // OK: redeclaration of f(int, int) void f (int i = 88, int j); // OK: redeclaration of f(int, int) void f (); // OK: overloaded declaration of f void prog () { f (1, 2); // OK: call f(int, int) f (1); // OK: call f(int, int) f (); // Error: f(int, int) or f()? } --end example] --end note] _________________________ 112) When a parameter type includes a function type, such as in the case of a parameter type that is a pointer to function, the const and volatile type-specifiers at the outermost level of the parameter type specifications for the inner function type are also ignored. 13.2 Declaration matching [over.dcl] 1 Two function declarations of the same name refer to the same function if they are in the same scope and have equivalent parameter declara- tions (_over.load_). A function member of a derived class is not in the same scope as a function member of the same name in a base class. [Example: class B { public: int f(int); }; class D : public B { public: int f(char*); }; Here D::f(char*) hides B::f(int) rather than overloading it. void h(D* pd) { pd->f(1); // error: // D::f(char*) hides B::f(int) pd->B::f(1); // OK pd->f("Ben"); // OK, calls D::f } --end example] 2 A locally declared function is not in the same scope as a function in a containing scope. [Example: int f(char*); void g() { extern f(int); f("asdf"); // error: f(int) hides f(char*) // so there is no f(char*) in this scope } void caller () { extern void callee(int, int); { extern void callee(int); // hides callee(int, int) callee(88, 99); // error: only callee(int) in scope } } --end example] 3 Different versions of an overloaded member function can be given dif- ferent access rules. [Example: class buffer { private: char* p; int size; protected: buffer(int s, char* store) { size = s; p = store; } // ... public: buffer(int s) { p = new char[size = s]; } // ... }; --end example] 13.3 Overload resolution [over.match] 1 Overload resolution is a mechanism for selecting the best function to call given a list of expressions that are to be the arguments of the call and a set of candidate functions that can be called based on the context of the call. The selection criteria for the best function are the number of arguments, how well the arguments match the types of the parameters of the candidate function, how well (for nonstatic member functions) the object matches the implied object parameter, and cer- tain other properties of the candidate function. [Note: the function selected by overload resolution is not guaranteed to be appropriate for the context. Other restrictions, such as the accessibility of the function, can make its use in the calling context ill-formed. ] 2 Overload resolution selects the function to call in seven distinct contexts within the language: --invocation of a function named in the function call syntax (_over.call.func_); --invocation of a function call operator, a pointer-to-function con- version function, a reference-to-pointer-to-function conversion function, or a reference-to-function conversion function on a class object named in the function call syntax (_over.call.object_); --invocation of the operator referenced in an expression (_over.match.oper_); --invocation of a constructor for direct-initialization (_dcl.init_) of a class object (_over.match.ctor_); --invocation of a user-defined conversion for copy-initialization (_dcl.init_) of a class object (_over.match.copy_); --invocation of a conversion function for initialization of an object of a nonclass type from an expression of class type (_over.match.conv_); and --invocation of a conversion function for conversion to an lvalue to which a reference (_dcl.init.ref_) will be directly bound (_over.match.ref_). 3 Each of these contexts defines the set of candidate functions and the list of arguments in its own unique way. But, once the candidate functions and argument lists have been identified, the selection of the best function is the same in all cases: --First, a subset of the candidate functions--those that have the proper number of arguments and meet certain other conditions--is selected to form a set of viable functions (_over.match.viable_). --Then the best viable function is selected based on the implicit con- version sequences (_over.best.ics_) needed to match each argument to the corresponding parameter of each viable function. 4 If a best viable function exists and is unique, overload resolution succeeds and produces it as the result. Otherwise overload resolution fails and the invocation is ill-formed. When overload resolution suc- ceeds, and the best viable function is not accessible (clause _class.access_) in the context in which it is used, the program is ill-formed. 13.3.1 Candidate functions and argument lists [over.match.funcs] 1 The subclauses of _over.match.funcs_ describe the set of candidate functions and the argument list submitted to overload resolution in each of the seven contexts in which overload resolution is used. The source transformations and constructions defined in these subclauses are only for the purpose of describing the overload resolution pro- cess. An implementation is not required to use such transformations and constructions. 2 The set of candidate functions can contain both member and non-member functions to be resolved against the same argument list. So that argument and parameter lists are comparable within this heterogeneous set, a member function is considered to have an extra parameter, called the implicit object parameter, which represents the object for which the member function has been called. For the purposes of over- load resolution, both static and non-static member functions have an implicit object parameter, but constructors do not. 3 Similarly, when appropriate, the context can construct an argument list that contains an implied object argument to denote the object to be operated on. Since arguments and parameters are associated by position within their respective lists, the convention is that the implicit object parameter, if present, is always the first parameter and the implied object argument, if present, is always the first argu- ment. 4 For non-static member functions, the type of the implicit object parameter is "reference to cv X" where X is the class of which the function is a member and cv is the cv-qualification on the member function declaration. [Example: for a const member function of class X, the extra parameter is assumed to have type "reference to const X". ] For conversion functions, the function is considered to be a member of the class of the implicit object argument for the purpose of defin- ing the type of the implicit object parameter. For non-conversion functions introduced by a using-declaration into a derived class, the function is considered to be a member of the derived class for the purpose of defining the type of the implicit object parameter. For static member functions, the implicit object parameter is considered to match any object (since if the function is selected, the object is discarded). [Note: no actual type is established for the implicit object parameter of a static member function, and no attempt will be made to determine a conversion sequence for that parameter (_over.match.best_). ] 5 During overload resolution, the implied object argument is indistin- guishable from other arguments. The implicit object parameter, how- ever, retains its identity since conversions on the corresponding argument shall obey these additional rules: --no temporary object can be introduced to hold the argument for the implicit object parameter; --no user-defined conversions can be applied to achieve a type match with it; and --even if the implicit object parameter is not const-qualified, an rvalue temporary can be bound to the parameter as long as in all other respects the temporary can be converted to the type of the implicit object parameter. 6 Because only one user-defined conversion is allowed in an implicit conversion sequence, special rules apply when selecting the best user- defined conversion (_over.match.best_, _over.best.ics_). [Example: class T { public: T(); // ... }; class C : T { public: C(int); // ... }; T a = 1; // ill-formed: T(C(1)) not tried --end example] 7 In each case where a candidate is a function template, candidate tem- plate functions are generated using template argument deduction (_temp.over_, _temp.deduct_). Those candidates are then handled as candidate functions in the usual way.113) A given name can refer to one or more function templates and also to a set of overloaded non- template functions. In such a case, the candidate functions generated from each function template are combined with the set of non-template candidate functions. _________________________ 113) The process of argument deduction fully determines the parameter types of the template functions, i.e., the parameters of template functions contain no template parameter types. Therefore the template functions can be treated as normal (non-template) functions for the remainder of overload resolution. 13.3.1.1 Function call syntax [over.match.call] 1 Recall from _expr.call_, that a function call is a postfix-expression, possibly nested arbitrarily deep in parentheses, followed by an optional expression-list enclosed in parentheses: (...(opt postfix-expression )...)opt (expression-listopt) Overload resolution is required if the postfix-expression is the name of a function, a function template (_temp.fct_), an object of class type, or a set of pointers-to-function. 2 _over.call.func_ describes how overload resolution is used in the first two of the above cases to determine the function to call. _over.call.object_ describes how overload resolution is used in the third of the above cases to determine the function to call. 3 The fourth case arises from a postfix-expression of the form &F, where F names a set of overloaded functions. In the context of a function call, the set of functions named by F shall contain only non-member functions and static member functions114). And in this context using &F behaves the same as using the name F by itself. Thus, (&F)(expression-listopt) is simply (F)(expression-listopt), which is discussed in _over.call.func_. (The resolution of &F in other con- texts is described in _over.over_.) 13.3.1.1.1 Call to named function [over.call.func] 1 Of interest in _over.call.func_ are only those function calls in which the postfix-expression ultimately contains a name that denotes one or more functions that might be called. Such a postfix-expression, per- haps nested arbitrarily deep in parentheses, has one of the following forms: postfix-expression: postfix-expression . id-expression postfix-expression -> id-expression primary-expression These represent two syntactic subcategories of function calls: quali- fied function calls and unqualified function calls. 2 In qualified function calls, the name to be resolved is an id-expres- sion and is preceded by an -> or . operator. Since the construct A->B is generally equivalent to (*A).B, the rest of clause _over_ assumes, without loss of generality, that all member function calls have been normalized to the form that uses an object and the . opera- tor. Furthermore, clause _over_ assumes that the postfix-expression that is the left operand of the . operator has type "cv T" where T denotes a class115). Under this assumption, the id-expression in the call is looked up as a member function of T following the rules for looking up names in classes (_class.member.lookup_). If a member _________________________ 114) If F names a non-static member function, &F is a pointer-to-mem- ber, which cannot be used with the function call syntax. 115) Note that cv-qualifiers on the type of objects are significant in overload resolution for both lvalue and class rvalue objects. function is found, that function and its overloaded declarations con- stitute the set of candidate functions. The argument list is the expression-list in the call augmented by the addition of the left operand of the . operator in the normalized member function call as the implied object argument (_over.match.funcs_). 3 In unqualified function calls, the name is not qualified by an -> or . operator and has the more general form of a primary-expression. The name is looked up in the context of the function call following the normal rules for name lookup in function calls (_basic.lookup.koenig_). If the name resolves to a non-member func- tion declaration, that function and its overloaded declarations con- stitute the set of candidate functions116). The argument list is the same as the expression-list in the call. If the name resolves to a nonstatic member function, then the function call is actually a member function call. If the keyword this (_class.this_) is in scope and refers to the class of that member function, or a derived class thereof, then the function call is transformed into a normalized qual- ified function call using (*this) as the postfix-expression to the left of the . operator. The candidate functions and argument list are as described for qualified function calls above. If the keyword this is not in scope or refers to another class, then name resolution found a static member of some class T. In this case, all overloaded declarations of the function name in T become candidate functions and a contrived object of type T becomes the implied object argument117). The call is ill-formed, however, if overload resolution selects one of the non-static member functions of T in this case. 13.3.1.1.2 Call to object of class type [over.call.object] 1 If the primary-expression E in the function call syntax evaluates to a class object of type "cv T", then the set of candidate functions includes at least the function call operators of T. The function call operators of T are obtained by ordinary lookup of the name operator() in the context of (E).operator(). 2 In addition, for each conversion function declared in T of the form operator conversion-type-id () cv-qualifier; where cv-qualifier is the same cv-qualification as, or a greater cv- qualification than, cv, and where conversion-type-id denotes the type "pointer to function of (P1,...,Pn) returning R", or the type "refer- ence to pointer to function of (P1,...,Pn) returning R", or the type "reference to function of (P1,...,Pn) returning R", a surrogate call _________________________ 116) Because of the usual name hiding rules, these will be introduced by declarations or by using-directives all found in the same block or all found at namespace scope. 117) An implied object argument must be contrived to correspond to the implicit object parameter attributed to member functions during over- load resolution. It is not used in the call to the selected function. Since the member functions all have the same implicit object parame- ter, the contrived object will not be the cause to select or reject a function. function with the unique name call-function and having the form R call-function (conversion-type-id F, P1 a1,...,Pn an) { return F (a1,...,an); } is also considered as a candidate function. Similarly, surrogate call functions are added to the set of candidate functions for each conver- sion function declared in an accessible base class provided the func- tion is not hidden within T by another intervening declaration118). 3 If such a surrogate call function is selected by overload resolution, its body, as defined above, will be executed to convert E to the appropriate function and then to invoke that function with the argu- ments of the call. 4 The argument list submitted to overload resolution consists of the argument expressions present in the function call syntax preceded by the implied object argument (E). [Note: when comparing the call against the function call operators, the implied object argument is compared against the implicit object parameter of the function call operator. When comparing the call against a surrogate call function, the implied object argument is compared against the first parameter of the surrogate call function. The conversion function from which the surrogate call function was derived will be used in the conversion sequence for that parameter since it converts the implied object argu- ment to the appropriate function pointer or reference required by that first parameter. ] [Example: int f1(int); int f2(float); typedef int (*fp1)(int); typedef int (*fp2)(float); struct A { operator fp1() { return f1; } operator fp2() { return f2; } } a; int i = a(1); // Calls f1 via pointer returned from // conversion function --end example] 13.3.1.2 Operators in expressions [over.match.oper] 1 If no operand of an operator in an expression has a type that is a class or an enumeration, the operator is assumed to be a built-in operator and interpreted according to clause _expr_. [Note: because ., .*, and :: cannot be overloaded, these operators are always built- in operators interpreted according to clause _expr_. ?: cannot be overloaded, but the rules in this section are used to determine the conversions to be applied to the second and third operands when they have class or enumeration type (_expr.cond_). ] [Example: _________________________ 118) Note that this construction can yield candidate call functions that cannot be differentiated one from the other by overload resolu- tion because they have identical declarations or differ only in their return type. The call will be ambiguous if overload resolution cannot select a match to the call that is uniquely better than such undiffer- entiable functions. class String { public: String (const String&); String (char*); operator char* (); }; String operator + (const String&, const String&); void f(void) { char* p= "one" + "two"; // ill-formed because neither // operand has user defined type int I = 1 + 1; // Always evaluates to 2 even if // user defined types exist which // would perform the operation. } --end example] 2 If either operand has a type that is a class or an enumeration, a user-defined operator function might be declared that implements this operator or a user-defined conversion can be necessary to convert the operand to a type that is appropriate for a built-in operator. In this case, overload resolution is used to determine which operator function or built-in operator is to be invoked to implement the opera- tor. Therefore, the operator notation is first transformed to the equivalent function-call notation as summarized in Table 8 (where @ denotes one of the operators covered in the specified subclause). Table 8--relationship between operator and function call notation +--------------+------------+--------------------+------------------------+ |Subclause | Expression | As member function | As non-member function | +--------------+------------+--------------------+------------------------+ |_over.unary_ | @a | (a).operator@ () | operator@ (a) | |_over.binary_ | a@b | (a).operator@ (b) | operator@ (a, b) | |_over.ass_ | a=b | (a).operator= (b) | | |_over.sub_ | a[b] | (a).operator[](b) | | |_over.ref_ | a-> | (a).operator-> () | | |_over.inc_ | a@ | (a).operator@ (0) | operator@ (a, 0) | +--------------+------------+--------------------+------------------------+ 3 For a unary operator @ with an operand of a type whose cv-unqualified version is T1, and for a binary operator @ with a left operand of a type whose cv-unqualified version is T1 and a right operand of a type whose cv-unqualified version is T2, three sets of candidate functions, designated member candidates, non-member candidates and built-in can- didates, are constructed as follows: --If T1 is a class type, the set of member candidates is the result of the qualified lookup of T1::operator@ (_over.call.func_); otherwise, the set of member candidates is empty. --The set of non-member candidates is the result of the unqualified lookup of operator@ in the context of the expression according to the usual rules for name lookup in unqualified function calls (_basic.lookup.koenig_) except that all member functions are ignored. However, if no operand has a class type, only those non- member functions in the lookup set that have a first parameter of type T1 or "reference to (possibly cv-qualified) T1", when T1 is an enumeration type, or (if there is a right operand) a second parame- ter of type T2 or "reference to (possibly cv-qualified) T2", when T2 is an enumeration type, are candidate functions. --For the operator ,, the unary operator &, or the operator ->, the built-in candidates set is empty. For all other operators, the built-in candidates include all of the candidate operator functions defined in _over.built_ that, compared to the given operator, --have the same operator name, and --accept the same number of operands, and --accept operand types to which the given operand or operands can be converted according to _over.best.ics_, and --do not have the same parameter type list as any non-template non- member candidate. 4 For the built-in assignment operators, conversions of the left operand are restricted as follows: --no temporaries are introduced to hold the left operand, and --no user-defined conversions are applied to the left operand to achieve a type match with the left-most parameter of a built-in can- didate. 5 For all other operators, no such restrictions apply. 6 The set of candidate functions for overload resolution is the union of the member candidates, the non-member candidates, and the built-in candidates. The argument list contains all of the operands of the operator. The best function from the set of candidate functions is selected according to _over.match.viable_ and _over.match.best_.119) [Example: _________________________ 119) If the set of candidate functions is empty, overload resolution is unsuccessful. struct A { operator int(); }; A operator+(const A&, const A&); void m() { A a, b; a + b; // operator+(a,b) chosen over int(a) + int(b) } --end example] 7 If a built-in candidate is selected by overload resolution, the operands are converted to the types of the corresponding parameters of the selected operation function. Then the operator is treated as the corresponding built-in operator and interpreted according to clause _expr_. 8 The second operand of operator -> is ignored in selecting an opera- tor-> function, and is not an argument when the operator-> function is called. When operator-> returns, the operator -> is applied to the value returned, with the original second operand.120) 9 If the operator is the operator ,, the unary operator &, or the opera- tor ->, and there are no viable functions, then the operator is assumed to be the built-in operator and interpreted according to clause _expr_. 10[Note: the lookup rules for operators in expressions are different than the lookup rules for operator function names in a function call, as shown in the following example: struct A { }; void operator + (A, A); struct B { void operator + (B); void f (); }; A a; void B::f() { operator+ (a,a); // ERROR - global operator hidden by member a + a; // OK - calls global operator+ } --end note] _________________________ 120) If the value returned by the operator-> function has class type, this may result in selecting and calling another operator-> function. The process repeats until an operator-> function returns a value of non-class type. 13.3.1.3 Initialization by constructor [over.match.ctor] 1 When objects of class type are direct-initialized (_dcl.init_), over- load resolution selects the constructor. The candidate functions are all the constructors of the class of the object being initialized. The argument list is the expression-list within the parentheses of the initializer. 13.3.1.4 Copy-initialization of class by user- [over.match.copy] defined conversion 1 Under the conditions specified in _dcl.init_, as part of a copy-ini- tialization of an object of class type, a user-defined conversion can be invoked to convert an initializer expression to the type of the object being initialized. Overload resolution is used to select the user-defined conversion to be invoked. Assuming that "cv1 T" is the type of the object being initialized, with T a class type, the candi- date functions are selected as follows: --The converting constructors (_class.conv.ctor_) of T are candidate functions. --When the type of the initializer expression is a class type "cv S", the conversion functions of S and its base classes are considered. Those that are not hidden within S and yield a type whose cv-unqual- ified version is the same type as T or is a derived class thereof are candidate functions. Conversion functions that return "refer- ence to T" return lvalues of type T and are therefore considered to yield T for this process of selecting candidate functions. 2 In both cases, the argument list has one argument, which is the ini- tializer expression. [Note: this argument will be compared against the first parameter of the constructors and against the implicit object parameter of the conversion functions. ] 13.3.1.5 Initialization by conversion function [over.match.conv] 1 Under the conditions specified in _dcl.init_, as part of an initial- ization of an object of nonclass type, a conversion function can be invoked to convert an initializer expression of class type to the type of the object being initialized. Overload resolution is used to select the conversion function to be invoked. Assuming that "cv1 T" is the type of the object being initialized, and "cv S" is the type of the initializer expression, with S a class type, the candidate func- tions are selected as follows: --The conversion functions of S and its base classes are considered. Those that are not hidden within S and yield type T or a type that can be converted to type T via a standard conversion sequence (_over.ics.scs_) are candidate functions. Conversion functions that return a cv-qualified type are considered to yield the cv-unquali- fied version of that type for this process of selecting candidate functions. Conversion functions that return "reference to T" return lvalues of type T and are therefore considered to yield T for this process of selecting candidate functions. 2 The argument list has one argument, which is the initializer expres- sion. [Note: this argument will be compared against the implicit object parameter of the conversion functions. ] 13.3.1.6 Initialization by conversion function [over.match.ref] for direct reference binding 1 Under the conditions specified in _dcl.init.ref_, a reference can be bound directly to an lvalue that is the result of applying a conver- sion function to an initializer expression. Overload resolution is used to select the conversion function to be invoked. Assuming that "cv1 T" is the underlying type of the reference being initialized, and "cv S" is the type of the initializer expression, with S a class type, the candidate functions are selected as follows: --The conversion functions of S and its base classes are considered. Those that are not hidden within S and yield type "reference to cv2 T2", where "cv1 T" is reference-compatible (_dcl.init.ref_) with "cv2 T2", are candidate functions. 2 The argument list has one argument, which is the initializer expres- sion. [Note: this argument will be compared against the implicit object parameter of the conversion functions. ] 13.3.2 Viable functions [over.match.viable] 1 From the set of candidate functions constructed for a given context (_over.match.funcs_), a set of viable functions is chosen, from which the best function will be selected by comparing argument conversion sequences for the best fit (_over.match.best_). The selection of viable functions considers relationships between arguments and func- tion parameters other than the ranking of conversion sequences. 2 First, to be a viable function, a candidate function shall have enough parameters to agree in number with the arguments in the list. --If there are m arguments in the list, all candidate functions having exactly m parameters are viable. --A candidate function having fewer than m parameters is viable only if it has an ellipsis in its parameter list (_dcl.fct_). For the purposes of overload resolution, any argument for which there is no corresponding parameter is considered to ``match the ellipsis'' (_over.ics.ellipsis_) . --A candidate function having more than m parameters is viable only if the (m+1)-st parameter has a default argument (_dcl.fct.default_).121) For the purposes of overload resolution, _________________________ 121) According to _dcl.fct.default_, parameters following the (m+1)-st parameter must also have default arguments. the parameter list is truncated on the right, so that there are exactly m parameters. 3 Second, for F to be a viable function, there shall exist for each argument an implicit conversion sequence (_over.best.ics_) that con- verts that argument to the corresponding parameter of F. If the parameter has reference type, the implicit conversion sequence includes the operation of binding the reference, and the fact that a reference to non-const cannot be bound to an rvalue can affect the viability of the function (see _over.ics.ref_). 13.3.3 Best Viable Function [over.match.best] 1 Define ICSi(F) as follows: --if F is a static member function, ICS1(F) is defined such that ICS1(F) is neither better nor worse than ICS1(G) for any function G, and, symmetrically, ICS1(G) is neither better nor worse than ICS1(F)122); otherwise, --let ICSi(F) denote the implicit conversion sequence that converts the i-th argument in the list to the type of the i-th parameter of viable function F. _over.best.ics_ defines the implicit conversion sequences and _over.ics.rank_ defines what it means for one implicit conversion sequence to be a better conversion sequence or worse con- version sequence than another. Given these definitions, a viable function F1 is defined to be a bet- ter function than another viable function F2 if for all arguments i, ICSi(F1) is not a worse conversion sequence than ICSi(F2), and then --for some argument j, ICSj(F1) is a better conversion sequence than ICSj(F2), or, if not that, --F1 is a non-template function and F2 is a template function special- ization, or, if not that, --F1 and F2 are template functions, and the function template for F1 is more specialized than the template for F2 according to the par- tial ordering rules described in _temp.func.order_, or, if not that, --the context is an initialization by user-defined conversion (see _dcl.init_, _over.match.conv_) and the standard conversion sequence from the return type of F1 to the destination type (i.e., the type of the entity being initialized) is a better conversion sequence than the standard conversion sequence from the return type of F2 to the destination type. [Example: _________________________ 122) If a function is a static member function, this definition means that the first argument, the implied object parameter, has no effect in the determination of whether the function is better or worse than any other function. struct A { A(); operator int(); operator double(); } a; int i = a; // a.operator int() followed by no conversion is better // than a.operator double() followed by a conversion // to int float x = a; // ambiguous: both possibilities require conversions, // and neither is better than the other --end example] 2 If there is exactly one viable function that is a better function than all other viable functions, then it is the one selected by overload resolution; otherwise the call is ill-formed123). 3 [Example: void Fcn(const int*, short); void Fcn(int*, int); int i; short s = 0; void f() { Fcn(&i, s); // is ambiguous because // &i -> int* is better than &i -> const int* // but s -> short is also better than s -> int Fcn(&i, 1L); // calls Fcn(int*, int), because // &i -> int* is better than &i -> const int* // and 1L -> short and 1L -> int are indistinguishable Fcn(&i,'c'); // calls Fcn(int*, int), because // &i -> int* is better than &i -> const int* // and c -> int is better than c -> short } --end example] 13.3.3.1 Implicit conversion sequences [over.best.ics] 1 An implicit conversion sequence is a sequence of conversions used to convert an argument in a function call to the type of the correspond- ing parameter of the function being called. The sequence of conver- sions is an implicit conversion as defined in clause _conv_, which _________________________ 123) The algorithm for selecting the best viable function is linear in the number of viable functions. Run a simple tournament to find a function W that is not worse than any opponent it faced. Although an- other function F that W did not face might be at least as good as W, F cannot be the best function because at some point in the tournament F encountered another function G such that F was not better than G. Hence, W is either the best function or there is no best function. So, make a second pass over the viable functions to verify that W is better than all other functions. means it is governed by the rules for initialization of an object or reference by a single expression (_dcl.init_, _dcl.init.ref_). 2 Implicit conversion sequences are concerned only with the type, cv- qualification, and lvalue-ness of the argument and how these are con- verted to match the corresponding properties of the parameter. Other properties, such as the lifetime, storage class, alignment, or acces- sibility of the argument and whether or not the argument is a bit- field are ignored. So, although an implicit conversion sequence can be defined for a given argument-parameter pair, the conversion from the argument to the parameter might still be ill-formed in the final analysis. 3 Except in the context of an initialization by user-defined conversion (_over.match.copy_, _over.match.conv_), a well-formed implicit conver- sion sequence is one of the following forms: --a standard conversion sequence (_over.ics.scs_), --a user-defined conversion sequence (_over.ics.user_), or --an ellipsis conversion sequence (_over.ics.ellipsis_). 4 In the context of an initialization by user-defined conversion (i.e., when considering the argument of a user-defined conversion function; see _over.match.copy_, _over.match.conv_), only standard conversion sequences and ellipsis conversion sequences are allowed. 5 For the case where the parameter type is a reference, see _over.ics.ref_. 6 When the parameter type is not a reference, the implicit conversion sequence models a copy-initialization of the parameter from the argu- ment expression. The implicit conversion sequence is the one required to convert the argument expression to an rvalue of the type of the parameter. [Note: when the parameter has a class type, this is a con- ceptual conversion defined for the purposes of clause _over_; the actual initialization is defined in terms of constructors and is not a conversion. ] Any difference in top-level cv-qualification is sub- sumed by the initialization itself and does not constitute a conver- sion. [Example: a parameter of type A can be initialized from an argument of type const A. The implicit conversion sequence for that case is the identity sequence; it contains no "conversion" from const A to A. ] When the parameter has a class type and the argument expression has the same type, the implicit conversion sequence is an identity conversion. When the parameter has a class type and the argument expression has a derived class type, the implicit conversion sequence is a derived-to-base Conversion from the derived class to the base class. [Note: there is no such standard conversion; this derived-to-base Conversion exists only in the description of implicit conversion sequences. ] A derived-to-base Conversion has Conversion rank (_over.ics.scs_). 7 In all contexts, when converting to the implicit object parameter or when converting to the left operand of an assignment operation only standard conversion sequences that create no temporary object for the result are allowed. 8 If no conversions are required to match an argument to a parameter type, the implicit conversion sequence is the standard conversion sequence consisting of the identity conversion (_over.ics.scs_). 9 If no sequence of conversions can be found to convert an argument to a parameter type or the conversion is otherwise ill-formed, an implicit conversion sequence cannot be formed. 10If several different sequences of conversions exist that each convert the argument to the parameter type, the implicit conversion sequence associated with the parameter is defined to be the unique conversion sequence designated the ambiguous conversion sequence. For the pur- pose of ranking implicit conversion sequences as described in _over.ics.rank_, the ambiguous conversion sequence is treated as a user-defined sequence that is indistinguishable from any other user- defined conversion sequence124). If a function that uses the ambigu- ous conversion sequence is selected as the best viable function, the call will be ill-formed because the conversion of one of the arguments in the call is ambiguous. _________________________ 124) The ambiguous conversion sequence is ranked with user-defined conversion sequences because multiple conversion sequences for an ar- gument can exist only if they involve different user-defined conver- sions. The ambiguous conversion sequence is indistinguishable from any other user-defined conversion sequence because it represents at least two user-defined conversion sequences, each with a different us- er-defined conversion, and any other user-defined conversion sequence must be indistinguishable from at least one of them. This rule prevents a function from becoming non-viable because of an ambiguous conversion sequence for one of its parameters. Consider this example, class B; class A { A (B&); }; class B { operator A (); }; class C { C (B&); }; void f(A) { } void f(C) { } B b; f(b); // ambiguous because b -> C via constructor and // b -> A via constructor or conversion function. If it were not for this rule, f(A) would be eliminated as a viable function for the call f(b) causing overload resolution to select f(C) as the function to call even though it is not clearly the best choice. On the other hand, if an f(B) were to be declared then f(b) would re- solve to that f(B) because the exact match with f(B) is better than any of the sequences required to match f(A). 11The three forms of implicit conversion sequences mentioned above are defined in the following subclauses. 13.3.3.1.1 Standard conversion sequences [over.ics.scs] 1 Table 9 summarizes the conversions defined in clause _conv_ and parti- tions them into four disjoint categories: Lvalue Transformation, Qual- ification Adjustment, Promotion, and Conversion. [Note: these cate- gories are orthogonal with respect to lvalue-ness, cv-qualification, and data representation: the Lvalue Transformations do not change the cv-qualification or data representation of the type; the Qualification Adjustments do not change the lvalue-ness or data representation of the type; and the Promotions and Conversions do not change the lvalue- ness or cv-qualification of the type. ] 2 [Note: As described in clause _conv_, a standard conversion sequence is either the Identity conversion by itself (that is, no conversion) or consists of one to three conversions from the other four cate- gories. At most one conversion from each category is allowed in a single standard conversion sequence. If there are two or more conver- sions in the sequence, the conversions are applied in the canonical order: Lvalue Transformation, Promotion or Conversion, Qualification Adjustment. --end note] 3 Each conversion in Table 9 also has an associated rank (Exact Match, Promotion, or Conversion). These are used to rank standard conversion sequences (_over.ics.rank_). The rank of a conversion sequence is determined by considering the rank of each conversion in the sequence and the rank of any reference binding (_over.ics.ref_). If any of those has Conversion rank, the sequence has Conversion rank; other- wise, if any of those has Promotion rank, the sequence has Promotion rank; otherwise, the sequence has Exact Match rank. Table 9--conversions +-------------------------------+--------------------------+-------------+-----------------+ |Conversion | Category | Rank | Subclause | +-------------------------------+--------------------------+-------------+-----------------+ +-------------------------------+--------------------------+-------------+-----------------+ |No conversions required | Identity | | | +-------------------------------+--------------------------+ +-----------------+ |Lvalue-to-rvalue conversion | | | _conv.lval_ | +-------------------------------+ | +-----------------+ |Array-to-pointer conversion | Lvalue Transformation | Exact Match | _conv.array_ | +-------------------------------+ | +-----------------+ |Function-to-pointer conversion | | | _conv.func_ | +-------------------------------+--------------------------+ +-----------------+ |Qualification conversions | Qualification Adjustment | | _conv.qual_ | +-------------------------------+--------------------------+-------------+-----------------+ |Integral promotions | | | _conv.prom_ | +-------------------------------+ Promotion | Promotion +-----------------+ |Floating point promotion | | | _conv.fpprom_ | +-------------------------------+--------------------------+-------------+-----------------+ |Integral conversions | | | _conv.integral_ | +-------------------------------+ | +-----------------+ |Floating point conversions | | | _conv.double_ | +-------------------------------+ | +-----------------+ |Floating-integral conversions | | | _conv.fpint_ | +-------------------------------+ Conversion | Conversion +-----------------+ |Pointer conversions | | | _conv.ptr_ | +-------------------------------+ | +-----------------+ |Pointer to member conversions | | | _conv.mem_ | +-------------------------------+ | +-----------------+ |Boolean conversions | | | _conv.bool_ | +-------------------------------+--------------------------+-------------+-----------------+ 13.3.3.1.2 User-defined conversion sequences [over.ics.user] 1 A user-defined conversion sequence consists of an initial standard conversion sequence followed by a user-defined conversion (_class.conv_) followed by a second standard conversion sequence. If the user-defined conversion is specified by a constructor (_class.conv.ctor_), the initial standard conversion sequence converts the source type to the type required by the argument of the construc- tor. If the user-defined conversion is specified by a conversion function (_class.conv.fct_), the initial standard conversion sequence converts the source type to the implicit object parameter of the con- version function. 2 The second standard conversion sequence converts the result of the user-defined conversion to the target type for the sequence. Since an implicit conversion sequence is an initialization, the special rules for initialization by user-defined conversion apply when selecting the best user-defined conversion for a user-defined conversion sequence (see _over.match.best_ and _over.best.ics_). 3 If the user-defined conversion is specified by a template conversion function, the second standard conversion sequence must have exact match rank. 4 A conversion of an expression of class type to the same class type is given Exact Match rank, and a conversion of an expression of class type to a base class of that type is given Conversion rank, in spite of the fact that a copy constructor (i.e., a user-defined conversion function) is called for those cases. 13.3.3.1.3 Ellipsis conversion sequences [over.ics.ellipsis] 1 An ellipsis conversion sequence occurs when an argument in a function call is matched with the ellipsis parameter specification of the func- tion called. 13.3.3.1.4 Reference binding [over.ics.ref] 1 When a parameter of reference type binds directly (_dcl.init.ref_) to an argument expression, the implicit conversion sequence is the iden- tity conversion, unless the argument expression has a type that is a derived class of the parameter type, in which case the implicit con- version sequence is a derived-to-base Conversion (_over.best.ics_). [Example: struct A {}; struct B : public A {} b; int f(A&); int f(B&); int i = f(b); // Calls f(B&), an exact match, rather than // f(A&), a conversion --end example] If the parameter binds directly to the result of applying a conversion function to the argument expression, the implicit conversion sequence is a user-defined conversion sequence (_over.ics.user_), with the second standard conversion sequence either an identity conversion or, if the conversion function returns an entity of a type that is a derived class of the parameter type, a derived-to-base Conversion. 2 When a parameter of reference type is not bound directly to an argu- ment expression, the conversion sequence is the one required to con- vert the argument expression to the underlying type of the reference according to _over.best.ics_. Conceptually, this conversion sequence corresponds to copy-initializing a temporary of the underlying type with the argument expression. Any difference in top-level cv-qualifi- cation is subsumed by the initialization itself and does not consti- tute a conversion. 3 A standard conversion sequence cannot be formed if it requires binding a reference to non-const to an rvalue (except when binding an implicit object parameter; see the special rules for that case in _over.match.funcs_). [Note: this means, for example, that a candidate function cannot be a viable function if it has a non-const reference parameter (other than the implicit object parameter) and the corre- sponding argument is a temporary or would require one to be created to initialize the reference (see _dcl.init.ref_). ] 4 Other restrictions on binding a reference to a particular argument do not affect the formation of a standard conversion sequence, however. [Example: a function with a "reference to int" parameter can be a viable candidate even if the corresponding argument is an int bit- field. The formation of implicit conversion sequences treats the int bit-field as an int lvalue and finds an exact match with the parame- ter. If the function is selected by overload resolution, the call will nonetheless be ill-formed because of the prohibition on binding a non-const reference to a bit-field (_dcl.init.ref_). ] 5 The binding of a reference to an expression that is reference-compati- ble with added qualification influences the rank of a standard conver- sion; see _over.ics.rank_ and _dcl.init.ref_. 13.3.3.2 Ranking implicit conversion sequences [over.ics.rank] 1 _over.ics.rank_ defines a partial ordering of implicit conversion sequences based on the relationships better conversion sequence and better conversion. If an implicit conversion sequence S1 is defined by these rules to be a better conversion sequence than S2, then it is also the case that S2 is a worse conversion sequence than S1. If con- version sequence S1 is neither better than nor worse than conversion sequence S2, S1 and S2 are said to be indistinguishable conversion sequences. 2 When comparing the basic forms of implicit conversion sequences (as defined in _over.best.ics_) --a standard conversion sequence (_over.ics.scs_) is a better conver- sion sequence than a user-defined conversion sequence or an ellipsis conversion sequence, and --a user-defined conversion sequence (_over.ics.user_) is a better conversion sequence than an ellipsis conversion sequence (_over.ics.ellipsis_). 3 Two implicit conversion sequences of the same form are indistinguish- able conversion sequences unless one of the following rules apply: --Standard conversion sequence S1 is a better conversion sequence than standard conversion sequence S2 if --S1 is a proper subsequence of S2 (comparing the conversion sequences in the canonical form defined by _over.ics.scs_, exclud- ing any Lvalue Transformation; the identity conversion sequence is considered to be a subsequence of any non-identity conversion sequence) or, if not that, --the rank of S1 is better than the rank of S2 (by the rules defined below), or, if not that, --S1 and S2 differ only in their qualification conversion and yield similar types T1 and T2 (_conv.qual_), respectively, and the cv- qualification signature of type T1 is a proper subset of the cv- qualification signature of type T2, [Example: int f(const int *); int f(int *); int i; int j = f(&i); // Calls f(int *) --end example] or, if not that, --S1 and S2 are reference bindings (_dcl.init.ref_), and the types to which the references refer are the same type except for top- level cv-qualifiers, and the type to which the reference initial- ized by S2 refers is more cv-qualified than the type to which the reference initialized by S1 refers. [Example: int f(const int &); int f(int &); int g(const int &); int g(int); int i; int j = f(i); // Calls f(int &) int k = g(i); // ambiguous class X { public: void f() const; void f(); }; void g(const X& a, X b) { a.f(); // Calls X::f() const b.f(); // Calls X::f() } --end example] --User-defined conversion sequence U1 is a better conversion sequence than another user-defined conversion sequence U2 if they contain the same user-defined conversion function or constructor and if the sec- ond standard conversion sequence of U1 is better than the second standard conversion sequence of U2. [Example: struct A { operator short(); } a; int f(int); int f(float); int i = f(a); // Calls f(int), because short -> int is // better than short -> float. --end example] 4 Standard conversion sequences are ordered by their ranks: an Exact Match is a better conversion than a Promotion, which is a better con- version than a Conversion. Two conversion sequences with the same rank are indistinguishable unless one of the following rules applies: --A conversion that is not a conversion of a pointer, or pointer to member, to bool is better than another conversion that is such a conversion. --If class B is derived directly or indirectly from class A, conver- sion of B* to A* is better than conversion of B* to void*, and con- version of A* to void* is better than conversion of B* to void*. --If class B is derived directly or indirectly from class A and class C is derived directly or indirectly from B, --conversion of C* to B* is better than conversion of C* to A*, [Example: struct A {}; struct B : public A {}; struct C : public B {}; C *pc; int f(A *); int f(B *); int i = f(pc); // Calls f(B *) --end example] --binding of an expression of type C to a reference of type B& is better than binding an expression of type C to a reference of type A&, --conversion of A::* to B::* is better than conversion of A::* to C::*, --conversion of C to B is better than conversion of C to A, --conversion of B* to A* is better than conversion of C* to A*, --binding of an expression of type B to a reference of type A& is better than binding an expression of type C to a reference of type A&, --conversion of B::* to C::* is better than conversion of A::* to C::*, and --conversion of B to A is better than conversion of C to A. [Note: compared conversion sequences will have different source types only in the context of comparing the second standard conver- sion sequence of an initialization by user-defined conversion (see _over.match.best_); in all other contexts, the source types will be the same and the target types will be different. ] 13.4 Address of overloaded function [over.over] 1 A use of an overloaded function name without arguments is resolved in certain contexts to a function, a pointer to function or a pointer to member function for a specific function from the overload set. A function template name is considered to name a set of overloaded func- tions in such contexts. The function selected is the one whose type matches the target type required in the context. The target can be --an object or reference being initialized (_dcl.init_, _dcl.init.ref_), --the left side of an assignment (_expr.ass_), --a parameter of a function (_expr.call_), --a parameter of a user-defined operator (_over.oper_), --the return value of a function, operator function, or conversion (_stmt.return_), or --an explicit type conversion (_expr.type.conv_, _expr.static.cast_, _expr.cast_). The overloaded function name can be preceded by the & operator. An overloaded function name shall not be used without arguments in con- texts other than those listed. [Note: any redundant set of parenthe- ses surrounding the overloaded function name is ignored (_expr.prim_). ] 2 If the name is a function template, template argument deduction is done (_temp.deduct.funcaddr_), and if the argument deduction succeeds, the deduced template arguments are used to generate a single template function, which is added to the set of overloaded functions consid- ered. 3 Non-member functions and static member functions match targets of type "pointer-to-function" or "reference-to-function." Nonstatic member functions match targets of type "pointer-to-member-function;" the function type of the pointer to member is used to select the member function from the set of overloaded member functions. If a nonstatic member function is selected, the reference to the overloaded function name is required to have the form of a pointer to member as described in _expr.unary.op_. 4 If more than one function is selected, any template functions in the set are eliminated if the set also contains a non-template function, and any given template function is eliminated if the set contains a second template function that is more specialized than the first according to the partial ordering rules of _temp.func.order_. After such eliminations, if any, there shall remain exactly one selected function. 5 [Example: int f(double); int f(int); int (*pfd)(double) = &f; // selects f(double) int (*pfi)(int) = &f; // selects f(int) int (*pfe)(...) = &f; // error: type mismatch int (&rfi)(int) = f; // selects f(int) int (&rfd)(double) = f; // selects f(double) void g() { (int (*)(int))&f; // cast expression as selector } The initialization of pfe is ill-formed because no f() with type int(...) has been defined, and not because of any ambiguity. For another example, struct X { int f(int); static int f(long); }; int (X::*p1)(int) = &X::f; // OK int (*p2)(int) = &X::f; // error: mismatch int (*p3)(long) = &X::f; // OK int (X::*p4)(long) = &X::f; // error: mismatch int (X::*p5)(int) = &(X::f); // error: wrong syntax for // pointer to member int (*p6)(long) = &(X::f); // OK --end example] 6 [Note: if f() and g() are both overloaded functions, the cross product of possibilities must be considered to resolve f(&g), or the equiva- lent expression f(g). ] 7 [Note: there are no standard conversions (clause _conv_) of one pointer-to-function type into another. In particular, even if B is a public base of D, we have D* f(); B* (*p1)() = &f; // error void g(D*); void (*p2)(B*) = &g; // error --end note] 13.5 Overloaded operators [over.oper] 1 A function declaration having one of the following operator-function- ids as its name declares an operator function. An operator function is said to implement the operator named in its operator-function-id. operator-function-id: operator operator operator: one of new delete new[] delete[] + - * / % ^ & | ~ ! = < > += -= *= /= %= ^= &= |= << >> >>= <<= == != <= >= && || ++ -- , ->* -> () [] [Note: the last two operators are function call (_expr.call_) and subscripting (_expr.sub_). The operators new[], delete[], (), and [] are formed from more than one token. ] 2 Both the unary and binary forms of + - * & can be overloaded. 3 The following operators cannot be overloaded: . .* :: ?: nor can the preprocessing symbols # and ## (clause _cpp_). 4 Operator functions are usually not called directly; instead they are invoked to evaluate the operators they implement (_over.unary_ - _over.inc_). They can be explicitly called, however, using the opera- tor-function-id as the name of the function in the function call syn- tax (_expr.call_). [Example: complex z = a.operator+(b); // complex z = a+b; void* p = operator new(sizeof(int)*n); --end example] 5 The allocation and deallocation functions, operator new, operator new[], operator delete and operator delete[], are described completely in _basic.stc.dynamic_. The attributes and restrictions found in the rest of this section do not apply to them unless explicitly stated in _basic.stc.dynamic_. 6 An operator function shall either be a non-static member function or be a non-member function and have at least one parameter whose type is a class, a reference to a class, an enumeration, or a reference to an enumeration. It is not possible to change the precedence, grouping, or number of operands of operators. The meaning of the operators =, (unary) &, and , (comma), predefined for each type, can be changed for specific class and enumeration types by defining operator functions that implement these operators. Operator functions are inherited in the same manner as other base class functions. 7 The identities among certain predefined operators applied to basic types (for example, ++a == a+=1) need not hold for operator functions. Some predefined operators, such as +=, require an operand to be an lvalue when applied to basic types; this is not required by operator functions. 8 An operator function cannot have default arguments (_dcl.fct.default_), except where explicitly stated below. Operator functions cannot have more or fewer parameters than the number required for the corresponding operator, as described in the rest of this subclause. 9 Operators not mentioned explicitly below in _over.ass_ to _over.inc_ act as ordinary unary and binary operators obeying the rules of sec- tion _over.unary_ or _over.binary_. 13.5.1 Unary operators [over.unary] 1 A prefix unary operator shall be implemented by a non-static member function (_class.mfct_) with no parameters or a non-member function with one parameter. Thus, for any prefix unary operator @, @x can be interpreted as either x.operator@() or operator@(x). If both forms of the operator function have been declared, the rules in _over.match.oper_ determine which, if any, interpretation is used. See _over.inc_ for an explanation of the postfix unary operators ++ and --. 2 The unary and binary forms of the same operator are considered to have the same name. [Note: consequently, a unary operator can hide a binary operator from an enclosing scope, and vice versa. ] 13.5.2 Binary operators [over.binary] 1 A binary operator shall be implemented either by a non-static member function (_class.mfct_) with one parameter or by a non-member function with two parameters. Thus, for any binary operator @, x@y can be interpreted as either x.operator@(y) or operator@(x,y). If both forms of the operator function have been declared, the rules in _over.match.oper_ determines which, if any, interpretation is used. 13.5.3 Assignment [over.ass] 1 An assignment operator shall be implemented by a non-static member function with exactly one parameter. Because a copy assignment opera- tor operator= is implicitly declared for a class if not declared by the user (_class.copy_), a base class assignment operator is always hidden by the copy assignment operator of the derived class. 2 Any assignment operator, even the copy assignment operator, can be virtual. [Note: for a derived class D with a base class B for which a virtual copy assignment has been declared, the copy assignment opera- tor in D does not override B's virtual copy assignment operator. [Example: struct B { virtual int operator= (int); virtual B& operator= (const B&); }; struct D : B { virtual int operator= (int); virtual D& operator= (const B&); }; D dobj1; D dobj2; B* bptr = &dobj1; void f() { bptr->operator=(99); // calls D::operator=(int) *bptr = 99; // ditto bptr->operator=(dobj2); // calls D::operator=(const B&) *bptr = dobj2; // ditto dobj1 = dobj2; // calls implicitly-declared // D::operator=(const D&) } --end example] --end note] 13.5.4 Function call [over.call] 1 operator() shall be a non-static member function with an arbitrary number of parameters. It can have default arguments. It implements the function call syntax postfix-expression ( expression-listopt ) where the postfix-expression evaluates to a class object and the pos- sibly empty expression-list matches the parameter list of an opera- tor() member function of the class. Thus, a call x(arg1,...) is interpreted as x.operator()(arg1,...) for a class object x of type T if T::operator()(T1, T2, T3) exists and if the operator is selected as the best match function by the overload resolution mechanism (_over.match.best_). 13.5.5 Subscripting [over.sub] 1 operator[] shall be a non-static member function with exactly one parameter. It implements the subscripting syntax postfix-expression [ expression ] Thus, a subscripting expression x[y] is interpreted as x.operator[](y) for a class object x of type T if T::operator[](T1) exists and if the operator is selected as the best match function by the overload reso- lution mechanism (_over.match.best_). 13.5.6 Class member access [over.ref] 1 operator-> shall be a non-static member function taking no parameters. It implements class member access using -> postfix-expression -> id-expression An expression x->m is interpreted as (x.operator->())->m for a class object x of type T if T::operator->() exists and if the operator is selected as the best match function by the overload resolution mecha- nism (_over.match_). 13.5.7 Increment and decrement [over.inc] 1 The user-defined function called operator++ implements the prefix and postfix ++ operator. If this function is a member function with no parameters, or a non-member function with one parameter of class or enumeration type, it defines the prefix increment operator ++ for objects of that type. If the function is a member function with one parameter (which shall be of type int) or a non-member function with two parameters (the second of which shall be of type int), it defines the postfix increment operator ++ for objects of that type. When the postfix increment is called as a result of using the ++ operator, the int argument will have value zero.125) [Example: class X { public: X& operator++(); // prefix ++a X operator++(int); // postfix a++ }; class Y { }; Y& operator++(Y&); // prefix ++b Y operator++(Y&, int); // postfix b++ void f(X a, Y b) { ++a; // a.operator++(); a++; // a.operator++(0); ++b; // operator++(b); b++; // operator++(b, 0); a.operator++(); // explicit call: like ++a; a.operator++(0); // explicit call: like a++; operator++(b); // explicit call: like ++b; operator++(b, 0); // explicit call: like b++; } --end example] 2 The prefix and postfix decrement operators -- are handled analogously. 13.6 Built-in operators [over.built] 1 The candidate operator functions that represent the built-in operators defined in clause _expr_ are specified in this subclause. These can- didate functions participate in the operator overload resolution pro- cess as described in _over.match.oper_ and are used for no other pur- pose. 2 [Note: since built-in operators take only operands with non-class type, and operator overload resolution occurs only when an operand expression originally has class or enumeration type, operator overload resolution can resolve to a built-in operator only when an operand has a class type that has a user-defined conversion to a non-class type appropriate for the operator, or when an operand has an enumeration type that can be converted to a type appropriate for the operator. Also note that the candidate operator functions given in this section are in some cases more permissive than the built-in operators them- selves. As described in _over.match.oper_, after a built-in operator is selected by overload resolution the expression is subject to the requirements for the built-in operator given in clause _expr_, and therefore to any additional semantic constraints given there. If there is a user-written candidate with the same name and parameter _________________________ 125) Calling operator++ explicitly, as in expressions like a.opera- tor++(2), has no special properties: The argument to operator++ is 2. types as a built-in candidate operator function, the built-in operator function is hidden and is not included in the set of candidate func- tions. ] 3 In this section, the term promoted integral type is used to refer to those integral types which are preserved by integral promotion (including e.g. int and long but excluding e.g. char). Similarly, the term promoted arithmetic type refers to promoted integral types plus floating types. [Note: in all cases where a promoted integral type or promoted arithmetic type is required, an operand of enumera- tion type will be acceptable by way of the integral promotions. ] 4 For every pair T, VQ), where T is an arithmetic type, and VQ is either volatile or empty, there exist candidate operator functions of the form VQ T& operator++(VQ T&); T operator++(VQ T&, int); 5 For every pair T, VQ), where T is an arithmetic type other than bool, and VQ is either volatile or empty, there exist candidate operator functions of the form VQ T& operator--(VQ T&); T operator--(VQ T&, int); 6 For every pair T, VQ), where T is a cv-qualified or cv-unqualified object type, and VQ is either volatile or empty, there exist candidate operator functions of the form T*VQ& operator++(T*VQ&); T*VQ& operator--(T*VQ&); T* operator++(T*VQ&, int); T* operator--(T*VQ&, int); 7 For every cv-qualified or cv-unqualified object type T, there exist candidate operator functions of the form T& operator*(T*); 8 For every function type T, there exist candidate operator functions of the form T& operator*(T*); 9 For every type T, there exist candidate operator functions of the form T* operator+(T*); 10For every promoted arithmetic type T, there exist candidate operator functions of the form T operator+(T); T operator-(T); 11For every promoted integral type T, there exist candidate operator functions of the form T operator~(T); 12For every quintuple C1, C2, T, CV1, CV2), where C2 is a class type, C1 is the same type as C2 or is a derived class of C2, T is an object type or a function type, and CV1 and CV2 are cv-qualifier-seqs, there exist candidate operator functions of the form CV12 T& operator->*(CV1 C1*, CV2 T C2::*); where CV12 is the union of CV1 and CV2. 13For every pair of promoted arithmetic types L and R, there exist can- didate operator functions of the form LR operator*(L, R); LR operator/(L, R); LR operator+(L, R); LR operator-(L, R); bool operator<(L, R); bool operator>(L, R); bool operator<=(L, R); bool operator>=(L, R); bool operator==(L, R); bool operator!=(L, R); where LR is the result of the usual arithmetic conversions between types L and R. 14For every cv-qualified or cv-unqualified object type T there exist candidate operator functions of the form T* operator+(T*, ptrdiff_t); T& operator[](T*, ptrdiff_t); T* operator-(T*, ptrdiff_t); T* operator+(ptrdiff_t, T*); T& operator[](ptrdiff_t, T*); 15For every T, where T is a pointer to object type, there exist candi- date operator functions of the form ptrdiff_t operator-(T, T); 16For every pointer or enumeration type T, there exist candidate opera- tor functions of the form bool operator<(T, T); bool operator>(T, T); bool operator<=(T, T); bool operator>=(T, T); bool operator==(T, T); bool operator!=(T, T); 17For every pointer to member type T, there exist candidate operator functions of the form bool operator==(T, T); bool operator!=(T, T); 18For every pair of promoted integral types L and R, there exist candi- date operator functions of the form LR operator%(L, R); LR operator&(L, R); LR operator^(L, R); LR operator|(L, R); L operator<<(L, R); L operator>>(L, R); where LR is the result of the usual arithmetic conversions between types L and R. 19For every triple L, VQ, R), where L is an arithmetic type, VQ is either volatile or empty, and R is a promoted arithmetic type, there exist candidate operator functions of the form VQ L& operator=(VQ L&, R); VQ L& operator*=(VQ L&, R); VQ L& operator/=(VQ L&, R); VQ L& operator+=(VQ L&, R); VQ L& operator-=(VQ L&, R); 20For every pair T, VQ), where T is any type and VQ is either volatile or empty, there exist candidate operator functions of the form T*VQ& operator=(T*VQ&, T*); 21For every pair T, VQ), where T is an enumeration or pointer to member type and VQ is either volatile or empty, there exist candidate opera- tor functions of the form VQ T& operator=(VQ T&, T); 22For every pair T, VQ), where T is a cv-qualified or cv-unqualified object type and VQ is either volatile or empty, there exist candidate operator functions of the form T*VQ& operator+=(T*VQ&, ptrdiff_t); T*VQ& operator-=(T*VQ&, ptrdiff_t); 23For every triple L, VQ, R), where L is an integral type, VQ is either volatile or empty, and R is a promoted integral type, there exist can- didate operator functions of the form VQ L& operator%=(VQ L&, R); VQ L& operator<<=(VQ L&, R); VQ L& operator>>=(VQ L&, R); VQ L& operator&=(VQ L&, R); VQ L& operator^=(VQ L&, R); VQ L& operator|=(VQ L&, R); 24There also exist candidate operator functions of the form bool operator!(bool); bool operator&&(bool, bool); bool operator||(bool, bool); 25For every pair of promoted arithmetic types L and R, there exist can- didate operator functions of the form LR operator?(bool, L, R); where LR is the result of the usual arithmetic conversions between types L and R. [Note: as with all these descriptions of candidate functions, this declaration serves only to describe the built-in oper- ator for purposes of overload resolution. The operator ?" cannot be overloaded. ] 26For every type T, where T is a pointer or pointer-to-member type, there exist candidate operator functions of the form T operator?(bool, T, T); ______________________________________________________________________ 14 Templates [temp] ______________________________________________________________________ 1 A template defines a family of classes or functions. template-declaration: exportopt template < template-parameter-list > declaration template-parameter-list: template-parameter template-parameter-list , template-parameter The declaration in a template-declaration shall --declare or define a function or a class, or --define a member function, a member class or a static data member of a class template or of a class nested within a class template, or --define a member template of a class or class template. A template-declaration is a declaration. A template-declaration is also a definition if its declaration defines a function, a class, or a static data member. 2 A template-declaration can appear only as a namespace scope or class scope declaration. In a function template declaration, the declara- tor-id shall be a template-name (i.e., not a template-id). [Note: in a class template declaration, if the declarator-id is a template-id, the declaration declares a class template partial specialization (_temp.class.spec_). ] 3 In a template-declaration, explicit specialization, or explicit instantiation the init-declarator-list in the declaration shall con- tain at most one declarator. When such a declaration is used to declare a class template, no declarator is permitted. 4 A template name may have linkage (_basic.link_). A template, a tem- plate explicit specialization (_temp.expl.spec_), or a class template partial specialization shall not have C linkage. If the linkage of one of these is something other than C or C++, the behavior is imple- mentation-defined. Template definitions shall obey the one definition rule (_basic.def.odr_). [Note: default arguments for function tem- plates and for member functions of class templates are considered def- initions for the purpose of template instantiation (_temp.decls_) and must also obey the one definition rule. ] 5 A class template shall not have the same name as any other template, class, function, object, enumeration, enumerator, namespace, or type in the same scope (_basic.scope_), except as specified in (_temp.class.spec_). Except that a function template can be over- loaded either by (non-template) functions with the same name or by other function templates with the same name (_temp.over_), a template name declared in namespace scope or in class scope shall be unique in that scope. 6 A namespace-scope declaration or definition of a non-inline function template, a non-inline member function template, a non-inline member function of a class template or a static data member of a class tem- plate may be preceded by the export keyword. If such a template is defined in the same translation unit in which it is declared as exported, the definition is considered to be exported. The first dec- laration of the template containing the export keyword must not follow the definition. 7 Declaring a class template exported is equivalent to declaring all of its non-inline function members, static data members, member classes, member class templates and non-inline function member templates which are defined in that translation unit exported. 8 Templates defined in an unnamed namespace shall not be exported. A template shall be exported only once in a program. An implementation is not required to diagnose a violation of this rule. A non-exported template that is neither explicitly specialized nor explicitly instan- tiated must be defined in every translation unit in which it is implicitly instantiated (_temp.inst_) or explicitly instantiated (_temp.explicit_); no diagnostic is required. An exported template need only be declared (and not necessarily defined) in a translation unit in which it is instantiated. A template function declared both exported and inline is just inline and not exported. 9 [Note: an implementation may require that a translation unit contain- ing the definition of an exported template be compiled before any translation unit containing an instantiation of that template. ] 14.1 Template parameters [temp.param] 1 The syntax for template-parameters is: template-parameter: type-parameter parameter-declaration type-parameter: class identifieropt class identifieropt = type-id typename identifieropt typename identifieropt = type-id template < template-parameter-list > class identifieropt template < template-parameter-list > class identifieropt = id-expression 2 There is no semantic difference between class and typename in a tem- plate-parameter. typename followed by an unqualified-id names a tem- plate type parameter. typename followed by a qualified-name denotes the type in a non-type 126) parameter-declaration. A storage class _________________________ 126) Since template template-parameters and template template-argu- shall not be specified in a template-parameter declaration. [Note: a template parameter may be a class template. For example, template class myarray { /* ... */ }; template class C = myarray> class Map { C key; C value; // ... }; --end note] 3 A type-parameter defines its identifier to be a type-name (if declared with class or typename) or template-name (if declared with template) in the scope of the template declaration. [Note: because of the name lookup rules, a template-parameter that could be interpreted as either a non-type template-parameter or a type-parameter (because its identi- fier is the name of an already existing class) is taken as a type- parameter. For example, class T { /* ... */ }; int i; template void f(T t) { T t1 = i; // template-parameters T and i ::T t2 = ::i; // global namespace members T and i } Here, the template f has a type-parameter called T, rather than an unnamed non-type template-parameter of class T. ] 4 A non-type template-parameter shall have one of the following (option- ally cv-qualified) types: --integral or enumeration type, --pointer to object or pointer to function, --reference to object or reference to function, --pointer to member. 5 [Note: other types are disallowed either explicitly below or implic- itly by the rules governing the form of template-arguments (_temp.arg_). ] The top-level cv-qualifiers on the template-parameter are ignored when determining its type. 6 A non-type non-reference template-parameter is not an lvalue. It shall not be assigned to or in any other way have its value changed. A non-type non-reference template-parameter cannot have its address _________________________ ments are treated as types for descriptive purposes, the terms non- type parameter and non-type argument are used to refer to non-type, non-template parameters and arguments. taken. When a non-type non-reference template-parameter is used as an initializer for a reference, a temporary is always used. [Example: template void f() { i++; // error: change of template-parameter value &x; // OK &i; // error: address of non-reference template-parameter int& ri = i; // error: non-const reference bound to temporary const int& cri = i; // OK: const reference bound to temporary } --end example] 7 A non-type template-parameter shall not be declared to have floating point, class, or void type. [Example: template class X; // error template class Y; // OK template class Z; // OK --end example] 8 A non-type template-parameter of type "array of T" or "function returning T" is adjusted to be of type "pointer to T" or "pointer to function returning T", respectively. [Example: template struct R { /* ... */ }; template struct S { /* ... */ }; int *p; R

w; // OK S

x; // OK due to parameter adjustment int v[5]; R y; // OK due to implicit argument conversion S z; // OK due to both adjustment and conversion --end example] 9 A default template-argument is a template-argument (_temp.arg_) speci- fied after = in a template-parameter. A default template-argument may be specified for any kind of template-parameter (type, non-type, tem- plate). A default template-argument may be specified in a class tem- plate declaration or a class template definition. A default template- argument shall not be specified in a function template declaration or a function template definition, nor in the template-parameter-list of the definition of a member of a class template. 10The set of default template-arguments available for use with a tem- plate declaration or definition is obtained by merging the default arguments from the definition (if in scope) and all declarations in scope in the same way default function arguments are (_dcl.fct.default_). [Example: template class A; template class A; is equivalent to template class A; --end example] 11If a template-parameter has a default template-argument, all subse- quent template-parameters shall have a default template-argument sup- plied. [Example: template class B; // error --end example] 12A template-parameter may not be given default arguments by two differ- ent declarations in the same scope. [Example: template class X; template class X { /*... */ }; // error --end example] 13The scope of a template-parameter extends from its point of declara- tion until the end of its template. In particular, a template-parame- ter can be used in the declaration of subsequent template-parameters and their default arguments. [Example: template class X { /* ... */ }; template void f(T* p = new T); --end example] 14A template-parameter cannot be used in preceding template-parameters or their default arguments. 15When parsing a default template-argument for a non-type template- parameter, the first non-nested > is taken as the end of the template- parameter-list rather than a greater-than operator. [Example: template 4 > // syntax error class X { /* ... */ }; template 4) > // OK class Y { /* ... */ }; --end example] 14.2 Names of template specializations [temp.names] 1 A template specialization (_temp.spec_) can be referred to by a tem- plate-id: template-id: template-name < template-argument-listopt > template-name: identifier template-argument-list: template-argument template-argument-list , template-argument template-argument: assignment-expression type-id id-expression [Note: the name lookup rules (_basic.lookup_) are used to associate the use of a name with a template declaration; that is, to identify a name as a template-name. ] 2 For a template-name to be explicitly qualified by the template argu- ments, the name must be known to refer to a template. 3 After name lookup (_basic.lookup_) finds that a name is a template- name, if this name is followed by a <, the < is always taken as the beginning of a template-argument-list and never as a name followed by the less-than operator. When parsing a template-id, the first non- nested >127) is taken as the end of the template-argument-list rather than a greater-than operator. [Example: template class X { /* ... */ }; X< 1>2 > x1; // syntax error X<(1>2)> x2; // OK template class Y { /* ... */ }; Y< X<1> > x3; // OK Y> 1> > x4; // OK: Y< X< (6>>1) > > --end example] 4 When the name of a member template specialization appears after . or -> in a postfix-expression, or after nested-name-specifier in a quali- fied-id, and the postfix-expression or qualified-id explicitly depends on a template-parameter (_temp.dep_), the member template name must be prefixed by the keyword template. Otherwise the name is assumed to name a non-template. [Example: class X { public: template X* alloc(); template static X* adjust(); }; template void f(T* p) { T* p1 = p->alloc<200>(); // ill-formed: < means less than T* p2 = p->template alloc<200>(); // OK: < starts template argument list T::adjust<100>(); // ill-formed: < means less than T::template adjust<100>(); // OK: < starts explicit qualification } --end example] 5 If a name prefixed by the keyword template is not the name of a member template, the program is ill-formed. [Note: the keyword template may not be applied to non-template members of class templates. ] _________________________ 127) A > that encloses the type-id of a dynamic_cast, static_cast, reinterpret_cast or const_cast, or which encloses the template-argu- ments of a subsequent template-id, is considered nested for the pur- pose of this description. 6 A template-id that names a class template specialization is a class- name (clause _class_). 14.3 Template arguments [temp.arg] 1 There are three forms of template-argument, corresponding to the three forms of template-parameter: type, non-type and template. The type and form of each template-argument specified in a template-id shall match the type and form specified for the corresponding parameter declared by the template in its template-parameter-list. [Example: template class Array { T* v; int sz; public: explicit Array(int); T& operator[](int); T& elem(int i) { return v[i]; } // ... }; Array v1(20); typedef complex dcomplex; // complex is a standard // library template Array v2(30); Array v3(40); void bar() { v1[3] = 7; v2[3] = v3.elem(4) = dcomplex(7,8); } --end example] 2 In a template-argument, an ambiguity between a type-id and an expres- sion is resolved to a type-id, regardless of the form of the corre- sponding template-parameter.128) [Example: template void f(); template void f(); void g() { f(); // int() is a type-id: call the first f() } --end example] 3 The name of a template-argument shall be accessible at the point where it is used as a template-argument. [Note: if the name of the tem- plate-argument is accessible at the point where it is used as a tem- plate-argument, there is no further access restriction in the result- ing instantiation where the corresponding template-parameter name is used. ] [Example: _________________________ 128) There is no such ambiguity in a default template-argument because the form of the template-parameter determines the allowable forms of the template-argument. template class X { static T t; }; class Y { private: struct S { /* ... */ }; X x; // OK: S is accessible // X has a static member of type Y::S // OK: even though Y::S is private }; X y; // error: S not accessible --end example] For a template-argument of class type, the template definition has no special access rights to the inaccessible members of the template argument type. 4 When default template-arguments are used, a template-argument list can be empty. In that case the empty <> brackets shall still be used as the template-argument-list. [Example: template class String; String<>* p; // OK: String String* q; // syntax error --end example] 5 An explicit destructor call (_class.dtor_) for an object that has a type that is a class template specialization may explicitly specify the template-arguments. [Example: template struct A { ~A(); }; void f(A* p, A* q) { p->A::~A(); // OK: destructor call q->A::~A(); // OK: destructor call } --end example] 6 If the use of a template-argument gives rise to an ill-formed con- struct in the instantiation of a template specialization, the program is ill-formed. 7 When the template in a template-id is an overloaded function template, both non-template functions in the overload set and function templates in the overload set for which the template-arguments do not match the template-parameters are ignored. If none of the function templates have matching template-parameters, the program is ill-formed. 14.3.1 Template type arguments [temp.arg.type] 1 A template-argument for a template-parameter which is a type shall be a type-id. 2 A local type, a type with no linkage, an unnamed type or a type com- pounded from any of these types shall not be used as a template- argument for a template type-parameter. [Example: template class X { /* ... */ }; void f() { struct S { /* ... */ }; X x3; // error: local type used as template-argument X x4; // error: pointer to local type used as template-argument } --end example] [Note: a template type argument may be an incomplete type (_basic.types_). ] 3 If a declaration acquires a function type through a type dependent on a template-parameter and this causes a declaration that does not use the syntactic form of a function declarator to have function type, the program is ill-formed. [Example: template struct A { static T t; }; typedef int function(); A a; // ill-formed: would declare A::t // as a static member function --end example] 14.3.2 Template non-type arguments [temp.arg.nontype] 1 A template-argument for a non-type, non-template template-parameter shall be one of: --an integral constant-expression of integral or enumeration type; or --the name of a non-type template-parameter; or --the name of an object or function with external linkage, including function templates and function template-ids but excluding non- static class members, expressed as id-expression; or --the address of an object or function with external linkage, includ- ing function templates and function template-ids but excluding non- static class members, expressed as & id-expression where the & is optional if the name refers to a function or array; or --a pointer to member expressed as described in _expr.unary.op_ . 2 [Note: A string literal (_lex.string_) is not an acceptable template- argument because a string literal is an object with internal linkage. [Example: template class X { // ... X(); X(const char* q) { /* ... */ } }; X x1; // error: string literal as template-argument char p[] = "Vivisectionist"; X x2; // OK --end example] --end note] 3 [Note: Addresses of array elements and names or addresses of non- static class members are not acceptable template-arguments. [Example: template class X { }; int a[10]; struct S { int m; static int s; } s; X<&a[2]> x3; // error: address of array element X<&s.m> x4; // error: address of non-static member X<&s.s> x5; // error: &S::s must be used X<&S::s> x6; // OK: address of static member --end example] --end note] 4 [Note: Temporaries, unnamed lvalues, and named lvalues that do not have external linkage are not acceptable template-arguments when the corresponding template-parameter has reference type. [Example: template struct B { /* ... */ }; B<1> b2; // error: temporary would be required for template argument int c = 1; B b1; // OK --end example] --end note] 5 The following conversions are performed on each expression used as a non-type template-argument. If a non-type template-argument cannot be converted to the type of the corresponding template-parameter then the program is ill-formed. --for a non-type template-parameter of integral or enumeration type, integral promotions (_conv.prom_) and integral conversions (_conv.integral_) are applied. --for a non-type template-parameter of type pointer to object, quali- fication conversions (_conv.qual_) and the array-to-pointer conver- sion (_conv.array_) are applied. [Note: In particular, neither the null pointer conversion (_conv.ptr_) nor the derived-to-base conver- sion (_conv.ptr_) are applied. Although 0 is a valid template-argu- ment for a non-type template-parameter of integral type, it is not a valid template-argument for a non-type template-parameter of pointer type. ] --For a non-type template-parameter of type reference to object, no conversions apply. The type referred to by the reference may be more cv-qualified than the (otherwise identical) type of the tem- plate-argument. The template-parameter is bound directly to the template-argument, which must be an lvalue. --For a non-type template-parameter of type pointer to function, only the function-to-pointer conversion (_conv.func_) is applied. If the template-argument represents a set of overloaded functions (or a pointer to such), the matching function is selected from the set (_over.over_). --For a non-type template-parameter of type reference to function, no conversions apply. If the template-argument represents a set of overloaded functions, the matching function is selected from the set (_over.over_). --For a non-type template-parameter of type pointer to member func- tion, no conversions apply. If the template-argument represents a set of overloaded member functions, the matching member function is selected from the set (_over.over_). --For a non-type template-parameter of type pointer to data member, qualification conversions (_conv.qual_) are applied. [Example: template struct X { /* ... */ }; int ai[10]; X xi; // array to pointer and qualification conversions struct Y { /* ... */ }; template struct Z { /* ... */ }; Y y; Z z; // no conversion, but note extra cv-qualification template struct W { /* ... */ }; int b[5]; W w; // no conversion void f(char); void f(int); template struct A { /* ... */ }; A<&f> a; // selects f(int) --end example] 14.3.3 Template template arguments [temp.arg.template] 1 A template-argument for a template template-parameter shall be the name of a class template, expressed as id-expression. Only primary class templates are considered when matching the template template argument with the corresponding parameter; partial specializations are not considered even if their parameter lists match that of the tem- plate template parameter. 2 Any partial specializations (_temp.class.spec_) associated with the primary class template are considered when a specialization based on the template template-parameter is instantiated. If a specialization is not visible at the point of instantiation, and it would have been selected had it been visible, the program is ill-formed; no diagnostic is required. [Example: template class A { // primary template int x; }; template class A { // partial specialization long x; }; template class V> class C { V y; V z; }; C c; // V within C uses the primary template, // so c.y.x has type int // V within C uses the partial specialization, // so c.z.x has type long --end example] 14.4 Type equivalence [temp.type] 1 Two template-ids refer to the same class or function if their template names are identical, they refer to the same template, their type tem- plate-arguments are the same type, their non-type template-arguments of integral or enumeration type have identical values, their non-type template-arguments of pointer or reference type refer to the same external object or function, and their template template-arguments refer to the same template. [Example: template class buffer { /* ... */ }; buffer x; buffer y; declares x and y to be of the same type, and template class list { /* ... */ }; list x1; list x2; list x3; list x4; declares x2 and x3 to be of the same type. Their type differs from the types of x1 and x4. ] 14.5 Template declarations [temp.decls] 1 A template-id, that is, the template-name followed by a template-argu- ment-list shall not be specified in the declaration of a primary tem- plate declaration. [Example: template class A { }; // error template void sort(T1 data[I]); // error --end example] [Note: however, this syntax is allowed in class tem- plate partial specializations (_temp.class.spec_). ] 2 For purposes of name lookup and instantiation, default arguments of function templates and default arguments of member functions of class templates are considered definitions; each default argument is a sepa- rate definition which is unrelated to the function template definition or to any other default arguments. 14.5.1 Class templates [temp.class] 1 A class template defines the layout and operations for an unbounded set of related types. [Example: a single class template List might provide a common definition for list of int, list of float, and list of pointers to Shapes. ] 2 [Example: An array class template might be declared like this: template class Array { T* v; int sz; public: explicit Array(int); T& operator[](int); T& elem(int i) { return v[i]; } // ... }; The prefix template specifies that a template is being declared and that a type-name T will be used in the declaration. In other words, Array is a parameterized type with T as its parameter. ] 3 When a member function, a member class, a static data member or a mem- ber template of a class template is defined outside of the class tem- plate definition, the member definition is defined as a template defi- nition in which the template-parameters are those of the class tem- plate. The names of the template parameters used in the definition of the member may be different from the template parameter names used in the class template definition. The template argument list following the class template name in the member definition shall name the param- eters in the same order as the one used in the template parameter list of the member. [Example: template struct A { void f1(); void f2(); }; template void A::f1() { } //OK template void A::f2() { } //error --end example] 4 In a redeclaration, partial specialiation, explicit specialization or explicit instantiation of a class template, the class-key shall agree in kind with the original class template declaration (_dcl.type.elab_). 14.5.1.1 Member functions of class templates [temp.mem.func] 1 A member function template may be defined outside of the class tem- plate definition in which it is declared. [Example: template class Array { T* v; int sz; public: explicit Array(int); T& operator[](int); T& elem(int i) { return v[i]; } // ... }; declares three function templates. The subscript function might be defined like this: template T& Array::operator[](int i) { if (i<0 || sz<=i) error("Array: range error"); return v[i]; } --end example] 2 The template-arguments for a member function of a class template are determined by the template-arguments of the type of the object for which the member function is called. [Example: the template-argument for Array::operator[]() will be determined by the Array to which the subscripting operation is applied. Array v1(20); Array v2(30); v1[3] = 7; // Array::operator[]() v2[3] = dcomplex(7,8); // Array::operator[]() --end example] 14.5.1.2 Member classes of class templates [temp.mem.class] 1 A class member of a class template may be defined outside the class template definition in which it is declared. [Note: the class member must be defined before its first use that requires an instantiation (_temp.inst_). For example, template struct A { class B; }; A::B* b1; // OK: requires A to be defined but not A::B template class A::B { }; A::B b2; // OK: requires A::B to be defined --end note] 14.5.1.3 Static data members of class templates [temp.static] 1 A definition for a static data member may be provided in a namespace scope enclosing the definition of the static member's class template. [Example: template class X { static T s; }; template T X::s = 0; --end example] 14.5.2 Member templates [temp.mem] 1 A template can be declared within a class or class template; such a template is called a member template. A member template can be defined within or outside its class definition or class template defi- nition. A member template of a class template that is defined outside of its class template definition shall be specified with the template- parameters of the class template followed by the template-parameters of the member template. [Example: template class string { public: template int compare(const T2&); template string(const string& s) { /* ... */ } // ... }; template template int string::compare(const T2& s) { // ... } --end example] 2 A local class shall not have member templates. Access control rules (clause _class.access_) apply to member template names. A destructor shall not be a member template. A normal (non-template) member func- tion with a given name and type and a member function template of the same name, which could be used to generate a specialization of the same type, can both be declared in a class. When both exist, a use of that name and type refers to the non-template member unless an explicit template argument list is supplied. [Example: template struct A { void f(int); template void f(T2); }; template <> void A::f(int) { } // non-template member template <> template <> void A::f<>(int) { } // template member int main() { A ac; ac.f(1); // non-template ac.f('c'); // template ac.f<>(1); // template } --end example] 3 A member function template shall not be virtual. [Example: template struct AA { template virtual void g(C); // error virtual void f(); // OK }; --end example] 4 A specialization of a member function template does not override a virtual function from a base class. [Example: class B { virtual void f(int); }; class D : public B { template void f(T); // does not override B::f(int) void f(int i) { f<>(i); } // overriding function that calls // the template instantiation }; --end example] 5 A specialization of a template conversion function is referenced in the same way as a non-template conversion function that converts to the same type. [Example: struct A { template operator T*(); }; template A::operator T*(){ return 0; } template <> A::operator char*(){ return 0; } // specialization template A::operator void*(); // explicit instantiation int main() { A a; int* ip; ip = a.operator int*(); // explicit call to template operator // A::operator int*() } --end example] [Note: because the explicit template argument list follows the function template name, and because conversion member function templates and constructor member function templates are called without using a function name, there is no way to provide an explicit template argument list for these function templates. ] 6 A specialization of a template conversion function is not found by name lookup. Instead, any template conversion functions visible in the context of the use are considered. For each such operator, if argument deduction succeeds (_temp.deduct.conv_), the resulting spe- cialization is used as if found by name lookup. 7 A using-declaration in a derived class cannot refer to a specializa- tion of a template conversion function in a base class. 8 Overload resolution (_over.ics.rank_) and partial ordering (_temp.func.order_) are used to select the best conversion function among multiple template conversion functions and/or non-template con- version functions. 14.5.3 Friends [temp.friend] 1 A friend of a class or class template can be a function template or class template, a specialization of a function template or class tem- plate, or an ordinary (nontemplate) function or class. For a friend function declaration that is not a template declaration: --if the name of the friend is a qualified or unqualified template-id, the friend declaration refers to a specialization of a function tem- plate, otherwise --if the name of the friend is a qualified-id and a matching nontem- plate function is found in the specified class or namespace, the friend declaration refers to that function, otherwise, --if the name of the friend is a qualified-id and a matching special- ization of a template function is found in the specified class or namespace, the friend declaration refers to that function special- ization, otherwise, --the name shall be an unqualified-id that declares (or redeclares) an ordinary (nontemplate) function. [Example: template class task; template task* preempt(task*); template class task { // ... friend void next_time(); friend void process(task*); friend task* preempt(task*); template friend int func(C); friend class task; template friend class frd; // ... }; Here, each specialization of the task class template has the function next_time as a friend; because process does not have explicit tem- plate-arguments, each specialization of the task class template has an appropriately typed function process as a friend, and this friend is not a function template specialization; because the friend preempt has an explicit template-argument , each specialization of the task class template has the appropriate specialization of the function tem- plate preempt as a friend; and each specialization of the task class template has all specializations of the function template func as friends. Similarly, each specialization of the task class template has the class template specialization task as a friend, and has all specializations of the class template frd as friends. --end example] 2 A friend function declaration that is not a template declaration and in which the name of the friend is an unqualified template-id shall refer to a specialization of a function template declared in the nearest enclosing namespace scope. [Example: namespace N { template void f(T); void g(int); namespace M { template void h(T); template void i(T); struct A { friend void f<>(int); // ill-formed - N::f friend void h<>(int); // OK - M::h friend void g(int); // OK - new decl of M::g template void i(T); friend void i<>(int); // ill-formed - A::i }; } } --end example] 3 A friend template may be declared within a class or class template. A friend function template may be defined within a class or class tem- plate, but a friend class template may not be defined in a class or class template. In these cases, all specializations of the friend class or friend function template are friends of the class or class template granting friendship. [Example: class A { template friend class B; // OK template friend void f(T){ /* ... */ } // OK }; --end example] 4 A template friend declaration specifies that all specializations of that template, whether they are implicitly instantiated (_temp.inst_), partially specialized (_temp.class.spec_) or explicitly specialized (_temp.expl.spec_), are friends of the class containing the template friend declaration. [Example: class X { template friend struct A; class Y { }; }; template struct A { X::Y ab; }; //OK template struct A { X::Y ab; }; //OK --end example] 5 When a function is defined in a friend function declaration in a class template, the function is defined at each instantiation of the class template. The function is defined even if it is never used. The same restrictions on multiple declarations and definitions which apply to non-template function declarations and definitions also apply to these implicit definitions. [Note: if the function definition is ill-formed for a given specialization of the enclosing class template, the pro- gram is ill-formed even if the function is never used. ] 6 A member of a class template may be declared to be a friend of a non- template class. In this case, the corresponding member of every spe- cialization of the class template is a friend of the class granting friendship. [Example: template struct A { struct B { }; void f(); }; class C { template friend struct A::B; template friend void A::f(); }; --end example] 7 [Note: a friend declaration may first declare a member of an enclosing namespace scope (_temp.inject_). ] 8 A friend template shall not be declared in a local class. 9 Friend declarations shall not declare partial specializations. [Exam- ple: template class A { }; class X { template friend class A; // error }; --end example] 10When a friend declaration refers to a specialization of a function template, the function parameter declarations shall not include default arguments, nor shall the inline specifier be used in such a declaration. 14.5.4 Class template partial specializations [temp.class.spec] 1 A primary class template declaration is one in which the class tem- plate name is an identifier. A template declaration in which the class template name is a template-id, is a partial specialization of the class template named in the template-id. A partial specialization of a class template provides an alternative definition of the template that is used instead of the primary definition when the arguments in a specialization match those given in the partial specialization (_temp.class.spec.match_). The primary template shall be declared before any specializations of that template. If a template is par- tially specialized then that partial specialization shall be declared before the first use of that partial specialization that would cause an implicit instantiation to take place, in every translation unit in which such a use occurs; no diagnostic is required. 2 When a partial specialization is used within the instantiation of an exported template, and the unspecialized template name is non-depen- dent in the exported template, a declaration of the partial special- ization must be declared before the definition of the exported tem- plate, in the translation unit containing that definition. A similar restriction applies to explicit specialization; see _temp.spec_. 3 Each class template partial specialization is a distinct template and definitions shall be provided for the members of a template partial specialization (_temp.class.spec.mfunc_). 4 [Example: template class A { }; // #1 template class A { }; // #2 template class A { }; // #3 template class A { }; // #4 template class A { }; // #5 The first declaration declares the primary (unspecialized) class tem- plate. The second and subsequent declarations declare partial spe- cializations of the primary template. ] 5 The template parameters are specified in the angle bracket enclosed list that immediately follows the keyword template. For partial spe- cializations, the template argument list is explicitly written immedi- ately following the class template name. For primary templates, this list is implicitly described by the template parameter list. Specifi- cally, the order of the template arguments is the sequence in which they appear in the template parameter list. [Example: the template argument list for the primary template in the example above is . ] [Note: the template argument list shall not be specified in the primary template declaration. For example, template class A { }; // error --end note] 6 A class template partial specialization may be declared or redeclared in any namespace scope in which its definition may be defined (_temp.class_ and _temp.mem_). [Example: template struct A { class C { template struct B { }; }; }; // partial specialization of A::C::B template template struct A::C::B { }; A::C::B absip; // uses partial specialization --end example] 7 Partial specialization declarations themselves are not found by name lookup. Rather, when the primary template name is used, any previousy declared partial specializations of the primary template are also con- sidered. One consequence is that a using-declaration which refers to a class template does not restrict the set of partial specializations which may be found through the using-declaration. [Example: namespace N { template class A { }; // primary template } using N::A; // refers to the primary template namespace N { template class A { }; // partial specialization } A a; // uses the partial specialization, which is found through // the using declaration which refers to the primary template --end example] 8 A non-type argument is non-specialized if it is the name of a non-type parameter. All other non-type arguments are specialized. 9 Within the argument list of a class template partial specialization, the following restrictions apply: --A partially specialized non-type argument expression shall not involve a template parameter of the partial specialization except when the argument expression is a simple identifier. [Example: template struct A {}; template struct A {}; // error template struct B {}; template struct B {}; // OK --end example] --The type of a template parameter corresponding to a specialized non- type argument shall not be dependent on a parameter of the special- ization. [Example: template struct C {}; template struct C; // error template< int X, int (*array_ptr)[X] > class A {}; int array[5]; template< int X > class A { }; // error --end example] --The argument list of the specialization shall not be identical to the implicit argument list of the primary template. 10The template parameter list of a specialization shall not contain default template argument values.129) _________________________ 129) There is no way in which they could be used. 14.5.4.1 Matching of class template [temp.class.spec.match] partial specializations 1 When a class template is used in a context that requires an instantia- tion of the class, it is necessary to determine whether the instantia- tion is to be generated using the primary template or one of the par- tial specializations. This is done by matching the template arguments of the class template specialization with the template argument lists of the partial specializations. --If exactly one matching specialization is found, the instantiation is generated from that specialization. --If more than one matching specialization is found, the partial order rules (_temp.class.order_) are used to determine whether one of the specializations is more specialized than the others. If none of the specializations is more specialized than all of the other matching specializations, then the use of the class template is ambiguous and the program is ill-formed. --If no matches are found, the instantiation is generated from the primary template. 2 A partial specialization matches a given actual template argument list if the template arguments of the partial specialization can be deduced from the actual template argument list (_temp.deduct_). [Example: A a1; // uses #1 A a2; // uses #2, T is int, I is 1 A a3; // uses #4, T is char A a4; // uses #5, T1 is int, T2 is char, I is 1 A a5; // ambiguous: matches #3 and #5 --end example] 3 A non-type template argument can also be deduced from the value of an actual template argument of a non-type parameter of the primary tem- plate. [Example: the declaration of a2 above. ] 4 In a type name that refers to a class template specialization, (e.g., A) the argument list must match the template parameter list of the primary template. The template arguments of a specializa- tion are deduced from the arguments of the primary template. 14.5.4.2 Partial ordering of class template [temp.class.order] specializations 1 For two class template partial specializations, the first is at least as specialized as the second if, given the following rewrite to two function templates, the first function template is at least as spe- cialized as the second according to the ordering rules for function templates (_temp.func.order_): --the first function template has the same template parameters as the first partial specialization and has a single function parameter whose type is a class template specialization with the template arguments of the first partial specialization, and --the second function template has the same template parameters as the second partial specialization and has a single function parameter whose type is a class template specialization with the template arguments of the second partial specialization. 2 [Example: template class X { }; template class X { }; // #1 template class X { }; // #2 template void f(X); // #A template void f(X); // #B The partial specialization #2 is more specialized than the partial specialization #1 because the function template #B is more specialized than the function template #A according to the ordering rules for function templates. ] 14.5.4.3 Members of class template [temp.class.spec.mfunc] specializations 1 The template parameter list of a member of a class template partial specialization shall match the template parameter list of the class template partial specialization. The template argument list of a mem- ber of a class template partial specialization shall match the tem- plate argument list of the class template partial specialization. A class template specialization is a distinct template. The members of the class template partial specialization are unrelated to the members of the primary template. Class template partial specialization mem- bers that are used in a way that requires a definition shall be defined; the definitions of members of the primary template are never used as definitions for members of a class template partial special- ization. An explicit specialization of a member of a class template partial specialization is declared in the same way as an explicit spe- cialization of the primary template. [Example: // primary template template struct A { void f(); }; template void A::f() { } // class template partial specialization template struct A { void f(); void g(); void h(); }; // member of class template partial specialization template void A::g() { } // explicit specialization template<> void A::h() { } int main() { A a0; A a2; a0.f(); // OK, uses definition of primary template's member a2.g(); // OK, uses definition of // partial specialization's member a2.h(); // OK, uses definition of // explicit specialization's member a2.f(); // ill-formed, no definition of f for A // the primary template is not used here } --end example] 2 If a member template of a class template is partially specialized, the member template partial specializations are member templates of the enclosing class template; if the enclosing class template is instanti- ated (_temp.inst_, _temp.explicit_), a declaration for every member template partial specialization is also instantiated as part of creat- ing the members of the class template specialization. If the primary member template is explicitly specialized for a given (implicit) spe- cialization of the enclosing class template, the partial specializa- tions of the member template are ignored for this specialization of the enclosing class template. If a partial specialization of the mem- ber template is explicitly specialized for a given (implicit) special- ization of the enclosing class template, the primary member template and its other partial specializations are still considered for this specialization of the enclosing class template. [Example: template struct A { template struct B {}; // #1 template struct B {}; // #2 }; template<> template struct A::B {}; // #3 A::B abcip; // uses #2 A::B absip; // uses #3 A::B abci; // uses #1 --end example] 14.5.5 Function templates [temp.fct] 1 A function template defines an unbounded set of related functions. [Example: a family of sort functions might be declared like this: template class Array { }; template void sort(Array&); --end example] 2 A function template can be overloaded with other function templates and with normal (non-template) functions. A normal function is not related to a function template (i.e., it is never considered to be a specialization), even if it has the same name and type as a poten- tially generated function template specialization.130) 14.5.5.1 Function template overloading [temp.over.link] 1 It is possible to overload function templates so that two different function template specializations have the same type. [Example: // file1.c // file2.c template template void f(T*); void f(T); void g(int* p) { void h(int* p) { f(p); // call f(p); // call // f(int*) // f(int*) } } --end example] 2 Such specializations are distinct functions and do not violate the one definition rule (_basic.def.odr_). 3 The signature of a function template specialization consists of the signature of the function template and of the actual template argu- ments (whether explicitly specified or deduced). 4 The signature of a function template consists of its function signa- ture, its return type and its template parameter list. The names of the template parameters are significant only for establishing the relationship between the template parameters and the rest of the sig- nature. [Note: two distinct function templates may have identical function return types and function parameter lists, even if overload resolution alone cannot distinguish them. template void f(); template void f(); //OK: overloads the first template // distinguishable with an explicit template argument list --end note] 5 When an expression that references a template parameter is used in the function parameter list or the return type in the declaration of a function template, the expression that references the template parame- ter is part of the signature of the function template. This is neces- sary to permit a declaration of a function template in one translation unit to be linked with another declaration of the function template in another translation unit and, conversely, to ensure that function tem- plates that are intended to be distinct are not linked with one another. [Example: template A f(A, A); // #1 template A f(A, A); // same as #1 template A f(A, A); // different from #1 _________________________ 130) That is, declarations of non-template functions do not merely guide overload resolution of template functions with the same name. If such a non-template function is used in a program, it must be de- fined; it will not be implicitly instantiated using the function tem- plate definition. --end example] [Note: Most expressions that use template parameters use non-type template parameters, but it is possible for an expression to reference a type parameter. For example, a template type parameter can be used in the sizeof operator. ] 6 Two expressions involving template parameters are considered equiva- lent if two function definitions containing the expressions would sat- isfy the one definition rule (_basic.def.odr_), except that the tokens used to name the template parameters may differ as long as a token used to name a template parameter in one expression is replaced by another token that names the same template parameter in the other expression. [Example: template void f(A); // #1 template void f(A); // same as #1 --end example] Two expressions involving template parameters that are not equivalent are functionally equivalent if, for any given set of template arguments, the evaluation of the expression results in the same value. 7 Two function templates are equivalent if they are declared in the same scope, have the same name, have identical template parameter lists, and have return types and parameter lists that are equivalent using the rules described above to compare expressions involving non-type template parameters. Two function templates are functionally equiva- lent if they are equivalent except that one or more non-type expres- sions that involve template parameters in the return types and parame- ter lists are functionally equivalent using the rules described above to compare expressions involving non-type template parameters. If a program contains declarations of function templates that are function- ally equivalent but not equivalent, the program is ill-formed; no diagnostic is required. 8 [Note: This rule guarantees that equivalent declarations will be linked with one another, while not requiring implementations to use heroic efforts to guarantee that functionally equivalent declarations will be treated as distinct. For example, the last two declarations are functionally equivalent and would cause a program to be ill- formed: // Guaranteed to be the same template void f(A, A); template void f(A, A); // Guaranteed to be different template void f(A, A); template void f(A, A); // Ill-formed, no diagnostic required template void f(A, A); template void f(A, A); --end note] 14.5.5.2 Partial ordering of function [temp.func.order] templates 1 If a function template is overloaded, the use of a function template specialization might be ambiguous because template argument deduction (_temp.deduct_) may associate the function template specialization with more than one function template declaration. Partial ordering of overloaded function template declarations is used in the following contexts to select the function template to which a function template specialization refers: --during overload resolution for a call to a function template spe- cialization (_over.match.best_); --when the address of a function template specialization is taken; --when a placement operator delete that is a template function spe- cialization is selected to match a placement operator new (_basic.stc.dynamic.deallocation_, _expr.new_); --when a friend function declaration (_temp.friend_), an explicit instantiation (_temp.explicit_) or an explicit specialization (_temp.expl.spec_) refers to a function template specialization. 2 Given two overloaded function templates, whether one is more special- ized than another can be determined by transforming each template in turn and using argument deduction (_temp.deduct_) to compare it to the other. 3 The transformation used is: --For each type template parameter, synthesize a unique type and sub- stitute that for each occurrence of that parameter in the function parameter list, or for a template conversion function, in the return type. --For each non-type template parameter, synthesize a unique value of the appropriate type and substitute that for each occurrence of that parameter in the function parameter list, or for a template conver- sion function, in the return type. --For each template template parameter, synthesize a unique class tem- plate and substitute that for each occurrence of that parameter in the function parameter list, or for a template conversion function, in the return type. 4 Using the transformed function parameter list, perform argument deduc- tion against the other function template. The transformed template is at least as specialized as the other if, and only if, the deduction succeeds and the deduced parameter types are an exact match (so the deduction does not rely on implicit conversions). 5 A template is more specialized than another if, and only if, it is at least as specialized as the other template and that template is not at least as specialized as the first. [Example: template struct A { A(); }; template void f(T); template void f(T*); template void f(const T*); template void g(T); template void g(T&); template void h(const T&); template void h(A&); void m() { const int *p; f(p); // f(const T*) is more specialized than f(T) or f(T*) float x; g(x); // Ambiguous: g(T) or g(T&) A z; h(z); // overload resolution selects h(A&) const A z2; h(z2); // h(const T&) is called because h(A&) is not callable } --end example] 6 The presence of unused ellipsis and default arguments has no effect on the partial ordering of function templates. [Example: template void f(T); // #1 template void f(T*, int=1); // #2 template void g(T); // #3 template void g(T*, ...); // #4 int main() { int* ip; f(ip); // calls #2 g(ip); // calls #4 } --end example] 14.6 Name resolution [temp.res] 1 Three kinds of names can be used within a template definition: --The name of the template itself, and names declared within the tem- plate itself. --Names dependent on a template-parameter (_temp.dep_). --Names from scopes which are visible within the template definition. 2 A name used in a template declaration or definition and that is depen- dent on a template-parameter is assumed not to name a type unless the applicable name lookup finds a type name or the name is qualified by the keyword typename. [Example: // no B declared here class X; template class Y { class Z; // forward declaration of member class void f() { X* a1; // declare pointer to X T* a2; // declare pointer to T Y* a3; // declare pointer to Y Z* a4; // declare pointer to Z typedef typename T::A TA; TA* a5; // declare pointer to T's A typename T::A* a6; // declare pointer to T's A T::A* a7; // T::A is not a type name: // multiply T::A by a7; ill-formed, // no visible declaration of a7 B* a8; // B is not a type name: // multiply B by a8; ill-formed, // no visible declarations of B and a8 } }; --end example] 3 A qualified-name that refers to a type and that depends on a template- parameter (_temp.dep_) shall be prefixed by the keyword typename to indicate that the qualified-name denotes a type, forming an elabo- rated-type-specifier (_dcl.type.elab_). elaborated-type-specifier: . . . typename ::opt nested-name-specifier identifier typename ::opt nested-name-specifier identifier < template-argument-list > . . . 4 If a specialization of a template is instantiated for a set of tem- plate-arguments such that the qualified-name prefixed by typename does not denote a type, the specialization is ill-formed. The usual quali- fied name lookup (_basic.lookup.qual_) is used to find the qualified- name even in the presence of typename. [Example: struct A { struct X { }; int X; }; template void f(T t) { typename T::X x; // ill-formed: finds the data member X // not the member type X } --end example] 5 The keyword typename shall only be used in template declarations and definitions, including in the return type of a function template or member function template, in the return type for the definition of a member function of a class template or of a class nested within a class template, and in the type-specifier for the definition of a static member of a class template or of a class nested within a class template. The keyword typename shall only be applied to qualified names, but those names need not be dependent. The keyword typename is not permitted in a base-specifier or in a mem-initializer; in these contexts a qualified-name that depends on a template-parameter (_temp.dep_) is implicitly assumed to be a type name. 6 Within the definition of a class template or within the definition of a member of a class template, the keyword typename is not required when referring to the unqualified name of a previously declared member of the class template that declares a type. The keyword typename shall always be specified when the member is referred to using a qual- ified name, even if the qualifier is simply the class template name. [Example: template struct A { typedef int B; A::B b; // ill-formed: typename required before A::B void f(A::B); // ill-formed: typename required before A::B typename A::B g(); // OK }; The keyword typename is required whether the qualified name is A or A because A or A are synonyms within a class template with the parameter list . ] 7 Knowing which names are type names allows the syntax of every template definition to be checked. No diagnostic shall be issued for a tem- plate definition for which a valid specialization can be generated. If no valid specialization can be generated for a template definition, and that template is not instantiated, the template definition is ill- formed, no diagnostic required. [Note: if a template is instantiated, errors will be diagnosed according to the other rules in this Stan- dard. Exactly when these errors are diagnosed is a quality of imple- mentation issue. ] [Example: int j; template class X { // ... void f(T t, int i, char* p) { t = i; // diagnosed if X::f is instantiated // and the assignment to t is an error p = i; // may be diagnosed even if X::f is // not instantiated p = j; // may be diagnosed even if X::f is // not instantiated } void g(T t) { +; // may be diagnosed even if X::g is // not instantiated } }; --end example] 8 When looking for the declaration of a name used in a template defini- tion, the usual lookup rules (_basic.lookup.unqual_, _basic.lookup.koenig_) are used for nondependent names. The lookup of names dependent on the template parameters is postponed until the actual template argument is known (_temp.dep_). [Example: #include using namespace std; template class Set { T* p; int cnt; public: Set(); Set(const Set&); void printall() { for (int i = 0; i, the actual declaration of operator<< needed to print p[i] cannot be known until it is known what type T is (_temp.dep_). ] 9 If a name does not depend on a template-parameter (as defined in _temp.dep_), a declaration (or set of declarations) for that name shall be in scope at the point where the name appears in the template definition; the name is bound to the declaration (or declarations) found at that point and this binding is not affected by declarations that are visible at the point of instantiation. [Example: void f(char); template void g(T t) { f(1); // f(char) f(T(1)); // dependent f(t); // dependent dd++; // not dependent // error: declaration for dd not found } void f(int); double dd; void h() { g(2); // will cause one call of f(char) followed // by two calls of f(int) g('a'); // will cause three calls of f(char) } --end example] 10[Note: for purposes of name lookup, default arguments of function tem- plates and default arguments of member functions of class templates are considered definitions (_temp.decls_). --end note] 14.6.1 Locally declared names [temp.local] 1 Within the scope of a class template, when the name of the template is neither qualified nor followed by <, it is equivalent to the name of the template followed by the template-parameters enclosed in <>. [Example: the constructor for Set can be referred to as Set() or Set(). ] Other specializations (_temp.expl.spec_) of the class can be referred to by explicitly qualifying the template name with the appropriate template-arguments. [Example: template class X { X* p; // meaning X X* p2; X* p3; }; --end example] 2 Within the scope of a class template specialization or partial spe- cialization, when the name of the template is neither qualified nor followed by <, it is equivalent to the name of the template followed by the template-arguments enclosed in <>. [Example: template class Y; template<> class Y { Y* p; // meaning Y Y* q; // meaning Y }; --end example] 3 The scope of a template-parameter extends from its point of declara- tion until the end of its template. A template-parameter hides any entity with the same name in the enclosing scope. [Note: this implies that a template-parameter can be used in the declaration of subsequent template-parameters and their default arguments but cannot be used in preceding template-parameters or their default arguments. For exam- ple, template class X { /* ... */ }; template void f(T* p = new T); This also implies that a template-parameter can be used in the speci- fication of base classes. For example, template class X : public Array { /* ... */ }; template class Y : public T { /* ... */ }; The use of a template-parameter as a base class implies that a class used as a template-argument must be defined and not just declared when the class template is instantiated. ] 4 A template-parameter shall not be redeclared within its scope (includ- ing nested scopes). A template-parameter shall not have the same name as the template name. [Example: template class Y { int T; // error: template-parameter redeclared void f() { char T; // error: template-parameter redeclared } }; template class X; // error: template-parameter redeclared --end example] 5 In the definition of a member of a class template that appears outside of the class template definition, the name of a member of this tem- plate hides the name of a template-parameter. [Example: template struct A { struct B { /* ... */ }; void f(); }; template void A::f() { B b; // A's B, not the template parameter } --end example] 6 In the definition of a member of a class template that appears outside of the namespace containing the class template definition, the name of a template-parameter hides the name of a member of this namespace. [Example: namespace N { class C { }; template class B { void f(T); }; } template void N::B::f(C) { C b; // C is the template parameter, not N::C } --end example] 7 In the definition of a class template or in the definition of a member of such a template that appears outside of the template definition, for each base class which does not depend on a template-parameter (_temp.dep_), if the name of the base class or the name of a member of the base class is the same as the name of a template-parameter, the base class name or member name hides the template-parameter name (_basic.scope.hiding_). [Example: struct A { struct B { /* ... */ }; int a; int Y; }; template struct X : A { B b; // A's B a b; // error: A's a isn't a type name }; --end example] 14.6.2 Dependent names [temp.dep] 1 Inside a template, some constructs have semantics which may differ from one instantiation to another. Such a construct depends on the template parameters. In particular, types and expressions may depend on the type and or value of template parameters (as determined by the template arguments) and this determines the context for name lookup for certain names. Expressions may be type-dependent (on the type of a template parameter) or value-dependent (on the value of a non-type template parameter). In an expression of the form: postfix-expression ( expression-listopt ) where the postfix-expression is an identifier, the identifier denotes a dependent name if and only if any of the expressions in the expres- sion-list is a type-dependent expression (_temp.dep.expr_). If an operand of an operator is a type-dependent expression, the operator also denotes a dependent name. Such names are unbound and are looked up at the point of the template instantiation (_temp.point_) in both the context of the template definition and the context of the point of instantiation. 2 [Example: template struct X : B { typename T::A* pa; void f(B* pb) { static int i = B::i; pb->j++; } }; the base class name B, the type name T::A, the names B::i and pb->j explicitly depend on the template-parameter. --end example] 3 In the definition of a class template or in the definition of a member of such a template that appears outside of the template definition, if a base class of this template depends on a template-parameter, the base class scope is not examined during name lookup until the class template is instantiated. [Example: typedef double A; template B { typedef int A; }; template struct X : B { A a; // a has type double }; The type name A in the definition of X binds to the typedef name defined in the global namespace scope, not to the typedef name defined in the base class B. ] 4 If a base class is a dependent type, a member of that class cannot hide a name declared within a template, or a name from the template's enclosing scopes. [Example: struct A { struct B { /* ... */ }; int a; int Y; }; int a; template struct Y : T { struct B { /* ... */ }; B b; // The B defined in Y void f(int i) { a = i; } // ::a Y* p; // Y }; Y ya; The members A::B, A::a, and A::Y of the template argument A do not affect the binding of names in Y. ] 14.6.2.1 Dependent types [temp.dep.type] 1 A type is dependent if it is --a template parameter, --a qualified-id with a nested-name-specifier which contains a class- name that names a dependent type or whose unqualified-id names a dependent type, --a cv-qualified type where the cv-unqualified type is dependent, --a compound type constructed from any dependent type, --an array type constructed from any dependent type or whose size is specified by a constant expression that is value-dependent, --a template-id in which either the template name is a template param- eter or any of the template arguments is a dependent type or an expression that is type-dependent or value-dependent. 14.6.2.2 Type-dependent expressions [temp.dep.expr] 1 Except as described below, an expression is type-dependent if any subexpression is type-dependent. 2 this is type-dependent if the class type of the enclosing member func- tion is dependent (_temp.dep.type_). 3 An id-expression is type-dependent if it contains: --an identifier that was declared with a dependent type, --a template-id that is dependent, --a conversion-function-id that specifies a dependent type, --a nested-name-specifier that contains a class-name that names a dependent type. Expressions of the following forms are type-dependent only if the type specified by the type-id, simple-type-specifier or new-type-id is dependent, even if any subexpression is type-dependent: simple-type-specifier ( expression-listopt ) ::opt new new-placementopt new-type-id new-initializeropt ::opt new new-placementopt ( type-id ) new-initializeropt dynamic_cast < type-id > ( expression ) static_cast < type-id > ( expression ) const_cast < type-id > ( expression ) reinterpret_cast < type-id > ( expression ) ( type-id ) cast-expression 4 Expressions of the following forms are never type-dependent (because the type of the expression cannot be dependent): literal postfix-expression . pseudo-destructor-name postfix-expression -> pseudo-destructor-name sizeof unary-expression sizeof ( type-id ) typeid ( expression ) typeid ( type-id ) ::opt delete cast-expression ::opt delete [ ] cast-expression throw assignment-expressionopt 14.6.2.3 Value-dependent expressions [temp.dep.constexpr] 1 Except as described below, a constant expression is value-dependent if any subexpression is value-dependent. 2 An identifier is value-dependent if it is: --a name declared with a dependent type, --the name of a non-type template parameter, --a constant with integral or enumeration type and is initialized with an expression that is value-dependent. Expressions of the following form are value-dependent if the unary- expression is type-dependent or the type-id is dependent (even if sizeof unary-expression and sizeof ( type-id ) are not type-depen- dent): sizeof unary-expression sizeof ( type-id ) 3 Expressions of the following form are value-dependent if either the type-id or simple-type-specifier is dependent or the expression or cast-expression is value-dependent: simple-type-specifier ( expression-listopt ) static_cast < type-id > ( expression ) const_cast < type-id > ( expression ) reinterpret_cast < type-id > ( expression ) ( type-id ) cast-expression 14.6.2.4 Dependent template arguments [temp.dep.temp] 1 A type template-argument is dependent if the type it specifies is dependent. 2 An integral non-type template-argument is dependent if the constant expression it specifies is value-dependent. 3 A non-integral non-type template-argument is dependent if its type is dependent or it has either of the following forms qualified-id & qualified-id and contains a nested-name-specifier which specifies a class-name that names a dependent type. 4 A template template-argument is dependent if it names a template- parameter or is a qualified-id with a nested-name-specifier which con- tains a class-name that names a dependent type. 14.6.3 Non-dependent names [temp.nondep] 1 Non-dependent names used in a template definition are found using the usual name lookup and bound at the point they are used. [Example: void g(double); void h(); template class Z { public: void f() { g(1); // calls g(double) h++; // ill-formed: cannot increment function; // this could be diagnosed either here or // at the point of instantiation } }; void g(int); // not in scope at the point of the template // definition, not considered for the call g(1) --end example] 14.6.4 Dependent name resolution [temp.dep.res] 1 In resolving dependent names, names from the following sources are considered: --Declarations that are visible at the point of definition of the tem- plate. --Declarations from namespaces associated with the types of the func- tion arguments both from the instantiation context (_temp.point_) and from the definition context. 14.6.4.1 Point of instantiation [temp.point] 1 For a function template specialization, a member function template specialization, or a specialization for a member function or static data member of a class template, if the specialization is implicitly instantiated because it is referenced from within another template specialization and the context from which it is referenced depends on a template parameter, the point of instantiation of the specialization is the point of instantiation of the enclosing specialization. Other- wise, the point of instantiation for such a specialization immediately follows the namespace scope declaration or definition that refers to the specialization. 2 If a function template or member function of a class template is called in a way which uses the definition of a default argument of that function template or member function, the point of instantiation of the default argument is the point of instantiation of the function template or member function specialization. 3 For a class template specialization, a class member template special- ization, or a specialization for a class member of a class template, if the specialization is implicitly instantiated because it is refer- enced from within another template specialization, if the context from which the specialization is referenced depends on a template parame- ter, and if the specialization is not instantiated previous to the instantiation of the enclosing template, the point of instantiation is immediately before the point of instantiation of the enclosing tem- plate. Otherwise, the point of instantiation for such a specializa- tion immediately precedes the namespace scope declaration or defini- tion that refers to the specialization. 4 If a virtual function is implicitly instantiated, its point of instan- tiation is immediately following the point of instantiation of its enclosing class template specialization. 5 An explicit instantiation directive is an instantiation point for the specialization or specializations specified by the explicit instantia- tion directive. 6 The instantiation context of an expression that depends on the tem- plate arguments is the set of declarations with external linkage declared prior to the point of instantiation of the template special- ization in the same translation unit. 7 A specialization for a function template, a member function template, or of a member function or static data member of a class template may have multiple points of instantiations within a translation unit. A specialization for a class template has at most one point of instanti- ation within a translation unit. A specialization for any template may have points of instantiation in multiple translation units. If two different points of instantiation give a template specialization different meanings according to the one definition rule (_basic.def.odr_), the program is ill-formed, no diagnostic required. 14.6.4.2 Candidate functions [temp.dep.candidate] 1 For a function call that depends on a template parameter, if the func- tion name is an unqualified-id but not a template-id, the candidate functions are found using the usual lookup rules (_basic.lookup.unqual_, _basic.lookup.koenig_) except that: --For the part of the lookup using unqualified name lookup (_basic.lookup.unqual_), only function declarations with external linkage from the template definition context are found. --For the part of the lookup using associated namespaces (_basic.lookup.koenig_), only function declarations with external linkage found in either the template definition context or the tem- plate instantiation context are found. If the call would be ill-formed or would find a better match had the lookup within the associated namespaces considered all the function declarations with external linkage introduced in those namespaces in all translation units, not just considering those declarations found in the template definition and template instantiation contexts, then the program has undefined behavior. 14.6.5 Friend names declared within a class [temp.inject] template 1 Friend classes or functions can be declared within a class template. When a template is instantiated, the names of its friends are treated as if the specialization had been explicitly declared at its point of instantiation. 2 As with non-template classes, the names of namespace-scope friend functions of a class template specialization are not visible during an ordinary lookup unless explicitly declared at namespace scope (_class.friend_). Such names may be found under the rules for associ- ated classes (_basic.lookup.koenig_).131) [Example: template class number { number(int); //... friend number gcd(number& x, number& y) { /* ... */ } //... }; void g() { number a(3), b(4); //... a = gcd(a,b); // finds gcd because number is an // associated class, making gcd visible // in its namespace (global scope) b = gcd(3,4); // ill-formed; gcd is not visible } --end example] 14.7 Template instantiation and specialization [temp.spec] 1 The act of instantiating a function, a class, a member of a class tem- plate or a member template is referred to as template instantiation. 2 A function instantiated from a function template is called an instan- tiated function. A class instantiated from a class template is called an instantiated class. A member function, a member class, or a static data member of a class template instantiated from the member defini- tion of the class template is called, respectively, an instantiated member function, member class or static data member. A member func- tion instantiated from a member function template is called an instan- tiated member function. A member class instantiated from a member class template is called an instantiated member class. 3 An explicit specialization may be declared for a function template, a class template, a member of a class template or a member template. An explicit specialization declaration is introduced by template<>. In an explicit specialization declaration for a class template, a member of a class template or a class member template, the name of the class _________________________ 131) Friend declarations do not introduce new names into any scope, either when the template is declared or when it is instantiated. that is explicitly specialized shall be a template-id. In the explicit specialization declaration for a function template or a mem- ber function template, the name of the function or member function explicitly specialized may be a template-id. [Example: template struct A { static int x; }; template void g(U) { } template<> struct A { }; // specialize for T == double template<> struct A<> { }; // specialize for T == int template<> void g(char) { } // specialize for U == char // U is deduced from the parameter type template<> void g(int) { } // specialize for U == int template<> int A::x = 0; // specialize for T == char template struct B { static int x; }; template<> int B<>::x = 1; // specialize for T == int --end example] 4 An instantiated template specialization can be either implicitly instantiated (_temp.inst_) for a given argument list or be explicitly instantiated (_temp.explicit_). A specialization is a class, func- tion, or class member that is either instantiated or explicitly spe- cialized (_temp.expl.spec_). 5 No program shall explicitly instantiate any template more than once, both explicitly instantiate and explicitly specialize a template, or specialize a template more than once for a given set of template-argu- ments. An implementation is not required to diagnose a violation of this rule. 6 Each class template specialization instantiated from a template has its own copy of any static members. [Example: template class X { static T s; // ... }; template T X::s = 0; X aa; X bb; X has a static member s of type int and X has a static member s of type char*. ] 14.7.1 Implicit instantiation [temp.inst] 1 Unless a class template specialization has been explicitly instanti- ated (_temp.explicit_) or explicitly specialized (_temp.expl.spec_), the class template specialization is implicitly instantiated when the specialization is referenced in a context that requires a completely- defined object type or when the completeness of the class type affects the semantics of the program. The implicit instantiation of a class template specialization causes the implicit instantiation of the dec- larations, but not of the definitions or default arguments, of the class member functions, member classes, static data members and member templates; and it causes the implicit instantiation of the definitions of member anonymous unions. Unless a member of a class template or a member template has been explicitly instantiated or explicitly spe- cialized, the specialization of the member is implicitly instantiated when the specialization is referenced in a context that requires the member definition to exist; in particular, the initialization (and any associated side-effects) of a static data member does not occur unless the static data member is itself used in a way that requires the defi- nition of the static data member to exist. 2 Unless a function template specialization has been explicitly instan- tiated or explicitly specialized, the function template specialization is implicitly instantiated when the specialization is referenced in a context that requires a function definition to exist. Unless a call is to a function template explicit specialization or to a member func- tion of an explicitly specialized class template, a default argument for a function template or a member function of a class template is implicitly instantiated when the function is called in a context that requires the value of the default argument. 3 [Example: template class Z { public: void f(); void g(); }; void h() { Z a; // instantiation of class Z required Z* p; // instantiation of class Z not // required Z* q; // instantiation of class Z // not required a.f(); // instantiation of Z::f() required p->g(); // instantiation of class Z required, and // instantiation of Z::g() required } Nothing in this example requires class Z, Z::g(), or Z::f() to be implicitly instantiated. ] 4 A class template specialization is implicitly instantiated if the class type is used in a context that requires a completely-defined object type or if the completeness of the class type affects the semantics of the program; in particular, if an expression whose type is a class template specialization is involved in overload resolution, pointer conversion, pointer to member conversion, the class template specialization is implicitly instantiated (_basic.def.odr_); in addi- tion, a class template specialization is implicitly instantiated if the operand of a delete expression is of class type or is of pointer to class type and the class type is a template specialization. [Example: template class B { /* ... */ }; template class D : public B { /* ... */ }; void f(void*); void f(B*); void g(D* p, D* pp, D ppp) { f(p); // instantiation of D required: call f(B*) B* q = pp; // instantiation of D required: // convert D* to B* delete ppp; // instantiation of D required } --end example] 5 If the overload resolution process can determine the correct function to call without instantiating a class template definition, it is unspecified whether that instantiation actually takes place. [Exam- ple: template struct S { operator int(); }; void f(int); void f(S&); void f(S); void g(S& sr) { f(sr); // instantiation of S allowed but not required // instantiation of S allowed but not required }; --end example] 6 If an implicit instantiation of a class template specialization is required and the template is declared but not defined, the program is ill-formed. [Example: template class X; X ch; // error: definition of X required --end example] 7 The implicit instantiation of a class template does not cause any static data members of that class to be implicitly instantiated. 8 If a function template or a member function template specialization is used in a way that involves overload resolution, a declaration of the specialization is implicitly instantiated (_temp.over_). 9 An implementation shall not implicitly instantiate a function tem- plate, a member template, a non-virtual member function, a member class or a static data member of a class template that does not require instantiation. It is unspecified whether or not an implemen- tation implicitly instantiates a virtual member function of a class template if the virtual member function would not otherwise be instan- tiated. The use of a template specialization in a default argument shall not cause the template to be implicitly instantiated except that a class template may be instantiated where its complete type is needed to determine the correctness of the default argument. The use of a default argument in a function call causes specializations in the default argument to be implicitly instantiated. 10Implicitly instantiated class and function template specializations are placed in the namespace where the template is defined. Implicitly instantiated specializations for members of a class template are placed in the namespace where the enclosing class template is defined. Implicitly instantiated member templates are placed in the namespace where the enclosing class or class template is defined. [Example: namespace N { template class List { public: T* get(); // ... }; } template class Map { N::List lt; V get(K); // ... }; void g(Map& m) { int i = m.get("Nicholas"); // ... } a call of lt.get() from Map::get() would place List::get() in the namespace N rather than in the global names- pace. ] 11If a function template f is called in a way that requires a default argument expression to be used, the dependent names are looked up, the semantics constraints are checked, and the instantiation of any tem- plate used in the default argument expression is done as if the default argument expression had been an expression used in a function template specialization with the same scope, the same template parame- ters and the same access as that of the function template f used at that point. This analysis is called default argument instantiation. The instantiated default argument is then used as the argument of f. 12Each default argument is instantiated independently. [Example: template void f(T x, T y = ydef(T()), T z = zdef(T())); class A { }; A zdef(A); void g(A a, A b, A c) { f(a, b, c); // no default argument instantiation f(a, b); // default argument z = zdef(T()) instantiated f(a); // ill-formed; ydef is not declared } --end example] 13[Note: _temp.point_ defines the point of instantiation of a template specialization. ] 14There is an implementation-defined quantity that specifies the limit on the total depth of recursive instantiations, which could involve more than one template. The result of an infinite recursion in instantiation is undefined. [Example: template class X { X* p; // OK X a; // implicit generation of X requires // the implicit instantiation of X which requires // the implicit instantiation of X which ... }; --end example] 14.7.2 Explicit instantiation [temp.explicit] 1 A class, a function or member template specialization can be explic- itly instantiated from its template. A member function, member class or static data member of a class template can be explicitly instanti- ated from the member definition associated with its class template. 2 The syntax for explicit instantiation is: explicit-instantiation: template declaration If the explicit instantiation is for a class, a function or a member template specialization, the unqualified-id in the declaration shall be either a template-id or, where all template arguments can be deduced, a template-name. [Note: the declaration may declare a quali- fied-id, in which case the unqualified-id of the qualified-id must be a template-id. ] If the explicit instantiation is for a member func- tion, a member class or a static data member of a class template spe- cialization, the name of the class template specialization in the qualified-id for the member declarator shall be a template-id. [Exam- ple: template class Array { void mf(); }; template class Array; template void Array::mf(); template void sort(Array& v) { /* ... */ } template void sort(Array&); // argument is deduced here namespace N { template void f(T&) { } } template void N::f(int&); --end example] 3 A declaration of a function template shall be in scope at the point of the explicit instantiation of the function template. A definition of the class or class template containing a member function template shall be in scope at the point of the explicit instantiation of the member function template. A definition of a class template or class member template shall be in scope at the point of the explicit instan- tiation of the class template or class member template. A definition of a class template shall be in scope at the point of an explicit instantiation of a member function or a static data member of the class template. A definition of a member class of a class template shall be in scope at the point of an explicit instantiation of the member class. If the declaration of the explicit instantiation names an implicitly-declared special member function (clause _special_), the program is ill-formed. 4 The definition of a non-exported function template, a non-exported member function template, or a non-exported member function or static data member of a class template shall be present in every translation unit in which it is explicitly instantiated. 5 An explicit instantiation of a class or function template specializa- tion is placed in the namespace in which the template is defined. An explicit instantiation for a member of a class template is placed in the namespace where the enclosing class template is defined. An explicit instantiation for a member template is placed in the names- pace where the enclosing class or class template is defined. [Exam- ple: namespace N { template class Y { void mf() { } }; } template class Y; // error: class template Y not visible // in the global namespace using N::Y; template class Y; // OK: explicit instantiation in namespace N template class N::Y; // OK: explicit instantiation in namespace N template void N::Y::mf(); // OK: explicit instantiation // in namespace N --end example] 6 A trailing template-argument can be left unspecified in an explicit instantiation of a function template specialization or of a member function template specialization provided it can be deduced from the type of a function parameter (_temp.deduct_). [Example: template class Array { /* ... */ }; template void sort(Array& v); // instantiate sort(Array&) - template-argument deduced template void sort<>(Array&); --end example] 7 The explicit instantiation of a class template specialization implies the instantiation of all of its members not previously explicitly spe- cialized in the translation unit containing the explicit instantia- tion. 8 The usual access checking rules do not apply to names used to specify explicit instantiations. [Note: In particular, the template arguments and names used in the function declarator (including parameter types, return types and exception specifications) may be private types or objects which would normally not be accessible and the template may be a member template or member function which would not normally be accessible. ] 9 An explicit instantiation does not constitute a use of a default argu- ment, so default argument instantiation is not done. [Example: char* p = 0; template T g(T = &p); template int g(int); // OK even though &p isn't an int. --end example] 14.7.3 Explicit specialization [temp.expl.spec] 1 An explicit specialization of any of the following: --function template --class template --member function of a class template --static data member of a class template --member class of a class template --member class template of a class template --member function template of a class template can be declared by a declaration introduced by template<>; that is: explicit-specialization: template < > declaration [Example: template class stream; template<> class stream { /* ... */ }; template class Array { /* ... */ }; template void sort(Array& v) { /* ... */ } template<> void sort(Array&) ; Given these declarations, stream will be used as the definition of streams of chars; other streams will be handled by class template specializations instantiated from the class template. Similarly, sort will be used as the sort function for arguments of type Array; other Array types will be sorted by functions generated from the template. ] 2 An explicit specialization shall be declared in the namespace of which the template is a member, or, for member templates, in the namespace of which the enclosing class or enclosing class template is a member. An explicit specialization of a member function, member class or static data member of a class template shall be declared in the names- pace of which the class template is a member. Such a declaration may also be a definition. If the declaration is not a definition, the specialization may be defined later in the namespace in which the explicit specialization was declared, or in a namespace that encloses the one in which the explicit specialization was declared. 3 A declaration of a function template or class template being explic- itly specialized shall be in scope at the point of declaration of an explicit specialization. [Note: a declaration, but not a definition of the template is required. ] The definition of a class or class template shall be in scope at the point of declaration of an explicit specialization for a member template of the class or class template. [Example: template<> class X { /* ... */ }; // error: X not a template template class X; template<> class X { /* ... */ }; // OK: X is a template --end example] 4 A member function, a member class or a static data member of a class template may be explicitly specialized for a class specialization that is implicitly instantiated; in this case, the definition of the class template shall be in scope at the point of declaration of the explicit specialization for the member of the class template. If such an explicit specialization for the member of a class template names an implicitly-declared special member function (clause _special_), the program is ill-formed. 5 A member of an explicitly specialized class is not implicitly instan- tiated from the member declaration of the class template; instead, the member of the class template specialization shall itself be explicitly defined. In this case, the definition of the class template explicit specialization shall be in scope at the point of declaration of the explicit specialization of the member. The definition of an explicitly specialized class is unrelated to the definition of a gen- erated specialization. That is, its members need not have the same names, types, etc. as the members of the a generated specialization. Definitions of members of an explicitly specialized class are defined in the same manner as members of normal classes, and not using the explicit specialization syntax. [Example: template struct A { void f(T) { /* ... */ } }; template<> struct A { void f(int); }; void h() { A a; a.f(16); // A::f must be defined somewhere } // explicit specialization syntax not used for a member of // explicitly specialized class template specialization void A::f() { /* ... */ } --end example] 6 If a template, a member template or the member of a class template is explicitly specialized then that specialization shall be declared before the first use of that specialization that would cause an implicit instantiation to take place, in every translation unit in which such a use occurs; no diagnostic is required. If the program does not provide a definition for an explicit specialization and either the specialization is used in a way that would cause an implicit instantiation to take place or the member is a virtual member function, the program is ill-formed, no diagnostic required. An implicit instantiation is never generated for an explicit specializa- tion that is declared but not defined. [Example: template class Array { /* ... */ }; template void sort(Array& v) { /* ... */ } void f(Array& v) { sort(v); // use primary template // sort(Array&), T is String } template<> void sort(Array& v); // error: specialization // after use of primary template template<> void sort<>(Array& v); // OK: sort not yet used --end example] 7 The placement of explicit specialization declarations for function templates, class templates, member functions of class templates, static data members of class templates, member classes of class tem- plates, member class templates of class templates, member function templates of class templates, member functions of member templates of class templates, member functions of member templates of non-template classes, member function templates of member classes of class tem- plates, etc., and the placement of partial specialization declarations of class templates, member class templates of non-template classes, member class templates of class templates, etc., can affect whether a program is well-formed according to the relative positioning of the explicit specialization declarations and their points of instantiation in the translation unit as specified above and below. When writing a specialization, be careful about its location; or to make it compile will be such a trial as to kindle its self-immolation. 8 When a specialization for which an explicit specialization exists is used within the instantiation of an exported template, and the unspe- cialized template name is non-dependent in the exported template, a declaration of the explicit specialization shall be declared before the definition of the exported template, in the translation unit con- taining that definition. [Example: // file #1 #include // Primary class template vector export template void f(t) { vector vec; // should match the specialization /* ... */ } // file #2 #include class B { }; // Explicit specialization of vector for vector template class vector { /* ... */ } template void f(T); void g(B b) { f(b); // ill-formed: // f should refer to vector, but the // specialization was not declared with the // definition of f in file #1 } --end example] 9 A template explicit specialization is in the scope of the namespace in which the template was defined. [Example: namespace N { template class X { /* ... */ }; template class Y { /* ... */ }; template<> class X { /* ... */ }; // OK: specialization // in same namespace template<> class Y; // forward declare intent to // specialize for double } template<> class N::Y { /* ... */ }; // OK: specialization // in same namespace --end example] 10A template-id that names a class template explicit specialization that has been declared but not defined can be used exactly like the names of other incompletely-defined classes (_basic.types_). [Example: template class X; // X is a class template template<> class X; X* p; // OK: pointer to declared class X X x; // error: object of incomplete class X --end example] 11A trailing template-argument can be left unspecified in the template- id naming an explicit function template specialization provided it can be deduced from the function argument type. [Example: template class Array { /* ... */ }; template void sort(Array& v); // explicit specialization for sort(Array&) // with deduces template-argument of type int template<> void sort(Array&); --end example] 12It is possible for a specialization with a given function signature to be instantiated from more than one function template. In such cases, explicit specification of the template arguments must be used to uniquely identify the function template specialization being special- ized. [Example: template void f(T); template void f(T*); template <> void f(int*); // Ambiguous template <> void f(int*); // OK template <> void f(int); // OK --end example] 13A function with the same name as a template and a type that exactly matches that of a template specialization is not an explicit special- ization (_temp.fct_). 14An explicit specialization of a function template is inline only if it is explicitly declared to be, and independently of whether its func- tion template is. [Example: template void f(T) { /* ... */ } template inline T g(T) { /* ... */ } template<> inline void f<>(int) { /* ... */ } // OK: inline template<> int g<>(int) { /* ... */ } // OK: not inline --end example] 15An explicit specialization of a static data member of a template is a definition if the declaration includes an initializer; otherwise, it is a declaration. [Note: there is no syntax for the definition of a static data member of a template that requires default initialization. template<> X Q::x; This is a declaration regardless of whether X can be default initial- ized (_dcl.init_). ] 16A member or a member template of a class template may be explicitly specialized for a given implicit instantiation of the class template, even if the member or member template is defined in the class template definition. An explicit specialization of a member or member template is specified using the template specialization syntax. [Example: template struct A { void f(T); template void g(T,X); void h(T) { } }; // specialization template<> void A::f(int); // out of class member template definition template template void A::g(T,X) { } // member template partial specialization template<> template void A::g(int,X); // member template specialization template<> template<> void A::g(int,char); // X deduced as char template<> template<> void A::g(int,char); // X specified as char // member specialization even if defined in class definition template<> void A::h(int) { } --end example] 17A member or a member template may be nested within many enclosing class templates. If the declaration of an explicit specialization for such a member appears in namespace scope, the member declaration shall be preceded by a template<> for each enclosing class template that is explicitly specialized. [Example: template class A { template class B { void mf(); }; }; template<> template<> A::B { }; template<> template<> void A::B::mf() { }; --end example] 18In an explicit specialization declaration for a member of a class tem- plate or a member template that appears in namespace scope, the member template and some of its enclosing class templates may remain unspe- cialized, except that the declaration shall not explicitly specialize a class member template if its enclosing class templates are not explicitly specialized as well. In such explicit specialization dec- laration, the keyword template followed by a template-parameter-list shall be provided instead of the template<> preceding the explicit specialization declaration of the member. The types of the template- parameters in the template-parameter-list shall be the same as those specified in the primary template definition. [Example: template class A { template class B { template void mf1(T3); void mf2(); }; }; template<> template class A::B { }; template<> template<> template void A::B::mf1(T t) { }; template template<> void A::B::mf2() { }; // ill-formed; B is specialized but // its enclosing class template A is not --end example] 19A specialization of a member function template or member class tem- plate of a non-specialized class template is itself a template. 20An explicit specialization declaration shall not be a friend declara- tion. 21Default function arguments shall not be specified in a declaration or a definition for one of the following explicit specializations: --the explicit specialization of a function template; --the explicit specialization of a member function template; --the explicit specialization of a member function of a class template where the class template specialization to which the member function specialization belongs is implicitly instantiated. [Note: default function arguments may be specified in the declaration or definition of a member function of a class template specialization that is explicitly specialized. ] 14.8 Function template specializations [temp.fct.spec] 1 A function instantiated from a function template is called a function template specialization; so is an explicit specialization of a func- tion template. Template arguments can either be explicitly specified when naming the function template specialization or be deduced (_temp.deduct_) from the context, e.g. from the function arguments in a call to the function template specialization. 2 Each function template specialization instantiated from a template has its own copy of any static variable. [Example: template void f(T* p) { static T s; // ... }; void g(int a, char* b) { f(&a); // call f(int*) f(&b); // call f(char**) } Here f(int*) has a static variable s of type int and f(char**) has a static variable s of type char*. ] 14.8.1 Explicit template argument [temp.arg.explicit] specification 1 Template arguments can be specified when referring to a function tem- plate specialization by qualifying the function template name with the list of template-arguments in the same way as template-arguments are specified in uses of a class template specialization. [Example: template void sort(Array& v); void f(Array& cv, Array& ci) { sort(cv); // sort(Array&) sort(ci); // sort(Array&) } and template U convert(V v); void g(double d) { int i = convert(d); // int convert(double) char c = convert(d); // char convert(double) } --end example] 2 A template argument list may be specified when referring to a special- ization of a function template --when a function is called, --when the address of a function is taken, when a function initializes a reference to function, or when a pointer to member function is formed, --in an explicit specialization, --in an explicit instantiation, or --in a friend declaration. Trailing template arguments that can be deduced (_temp.deduct_) may be omitted from the list of explicit template-arguments. If all of the template arguments can be deduced, they may all be omitted; in this case, the empty template argument list <> itself may also be omitted. [Example: template X f(Y); void g() { int i = f(5.6); // Y is deduced to be double int j = f(5.6); // ill-formed: X cannot be deduced } --end example] [Note: An empty template argument list can be used to indicate that a given use refers to a specialization of a function template even when a normal (i.e., nontemplate) function is visible that would otherwise be used. For example: template int f(T); // #1 int f(int); // #2 int k = f(1); // uses #2 int l = f<>(1); // uses #1 --end note] 3 Template arguments that are present shall be specified in the declara- tion order of their corresponding template-parameters. The template argument list shall not specify more template-arguments than there are corresponding template-parameters. [Example: template X f(Y,Z); void g() { f("aa",3.0); f("aa",3.0); // Z is deduced to be double f("aa",3.0); // Y is deduced to be char*, and // Z is deduced to be double f("aa",3.0); // error: X cannot be deduced } --end example] 4 Implicit conversions (clause _conv_) will be performed on a function argument to convert it to the type of the corresponding function parameter if the parameter type contains no template-parameters that participate in template argument deduction. [Note: template parame- ters do not participate in template argument deduction if they are explicitly specified. For example, template void f(T); class Complex { // ... Complex(double); }; void g() { f(1); // OK, means f(Complex(1)) } --end note] 5 [Note: because the explicit template argument list follows the func- tion template name, and because conversion member function templates and constructor member function templates are called without using a function name, there is no way to provide an explicit template argu- ment list for these function templates. ] 6 [Note: For simple function names, argument dependent lookup (_basic.lookup.koenig_) applies even when the function name is not visible within the scope of the call. This is because the call still has the syntactic form of a function call (_basic.lookup.unqual_). But when a function template with explicit template arguments is used, the call does not have the correct syntactic form unless there is a function template with that name visible at the point of the call. If no such name is visible, the call is not syntactically well-formed and argument-dependent lookup does not apply. If some such name is visi- ble, argument dependent lookup applies and additional function tem- plates may be found in other namespaces. [Example: namespace A { struct B { }; template void f(); } namespace C { template void f(T t); } void g(A::B b) { f<3>(b); // ill-formed: not a function call A::f<3>(b); // well-formed C::f<3>(b); // ill-formed; argument dependent lookup // only applies to unqualified names using C::f; f<3>(b); // well-formed because C::f is visible; then // A::f is found by argument dependent lookup } --end example] --end note] 14.8.2 Template argument deduction [temp.deduct] 1 When a template function specialization is referenced, all of the tem- plate arguments must have values. The values can be either explicitly specified or, in some cases, deduced from the use. [Example: void f(Array& cv, Array& ci) { sort(cv); // call sort(Array&) sort(ci); // call sort(Array&) } and void g(double d) { int i = convert(d); // call convert(double) int c = convert(d); // call convert(double) } --end example] 2 When an explicit template argument list is specified, the template arguments must be compatible with the template parameter list and must result in a valid function type as described below; otherwise type deduction fails. Specifically, the following steps are performed when evaluating an explicitly specified template argument list with respect to a given function template: --The specified template arguments must match the template parameters in kind (i.e., type, nontype, template), and there must not be more arguments than there are parameters; otherwise type deduction fails. --Nontype arguments must match the types of the corresponding nontype template parameters, or must be convertible to the types of the cor- responding nontype parameters as specified in _temp.arg.nontype_, otherwise type deduction fails. --All references in the function type of the function template to the corresponding template parameters are replaced by the specified tem- plate argument values. If a substitution in a template parameter or in the function type of the function template results in an invalid type, type deduction fails. [Note: The equivalent substitution in exception specifications is done only when the function is instanti- ated, at which point a program is ill-formed if the substitution results in an invalid type.] Type deduction may fail for the follow- ing reasons: --Attempting to create an array with an element type that is void, a function type, or a reference type, or attempting to create an array with a size that is zero or negative. [Example: template int f(T[5]); int I = f(0); int j = f(0); // invalid array ] --Attempting to use a type that is not a class type in a qualified name. [Example: template int f(typename T::B*); int i = f(0); ] --Attempting to use a type in the qualifier portion of a qualified name that names a type when that type does not contain the speci- fied member, or if the specified member is not a type where a type is required. [Example: template int f(typename T::B*); struct A {}; struct C { int B; }; int i = f(0); int j = f(0); ] --Attempting to create a pointer to reference type. --Attempting to create a reference to a reference type or a reference to void. --Attempting to create "pointer to member of T" when T is not a class type. [Example: template int f(int T::*); int i = f(0); ] --Attempting to perform an invalid conversion in either a template argument expression, or an expression used in the function decla- ration. [Example: template int f(int); int i2 = f(0); // can't conv 1 to int* ] --Attempting to create a function type in which a parameter has a type of void. --Attempting to create a cv-qualified function type. 3 After this substitution is performed, the function parameter type adjustments described in _dcl.fct_ are performed. [Example: A parame- ter type of "void ()(const int, int[5])" becomes "void(*)(int,int*)". ] [Note: A top-level qualifier in a function parameter declaration does not affect the function type but still affects the type of the function parameter variable within the function. --end note] [Exam- ple: template void f(T t); template void g(const X x); template void h(Z, Z*); int main() { // #1: function type is f(int), t is nonconst f(1); // #2: function type is f(int), t is const f(1); // #3: function type is g(int), x is const g(1); // #4: function type is g(int), x is const g(1); // #5: function type is h(int, const int*) h(1,0); } --end example] [Note: f(1) and f(1) call distinct functions even though both of the functions called have the same func- tion type. --end note] 4 The resulting substituted and adjusted function type is used as the type of the function template for template argument deduction. When all template arguments have been deduced, all uses of template parame- ters in nondeduced contexts are replaced with the corresponding deduced argument values. If the substitution results in an invalid type, as described above, type deduction fails. 5 Except as described above, the use of an invalid value shall not cause type deduction to fail. [Example: In the following example 1000 is converted to signed char and results in an implementation-defined value as specified in (_conv.integral_). In other words, both tem- plates are considered even though 1000, when converted to signed char, results in an implementation-defined value. template int f(int); template int f(int); int i1 = f<1>(0); // ambiguous int i2 = f<1000>(0); // ambiguous --end example] 14.8.2.1 Deducing template arguments from a [temp.deduct.call] function call 1 Template argument deduction is done by comparing each function tem- plate parameter type (call it P) with the type of the corresponding argument of the call (call it A) as described below. 2 If P is not a reference type: --If A is an array type, the pointer type produced by the array-to- pointer standard conversion (_conv.array_) is used in place of A for type deduction; otherwise, --If A is a function type, the pointer type produced by the function- to-pointer standard conversion (_conv.func_) is used in place of A for type deduction; otherwise, --If A is a cv-qualified type, the top level cv-qualifiers of A's type are ignored for type deduction. If P is a cv-qualified type, the top level cv-qualifiers of P's type are ignored for type deduction. If P is a reference type, the type referred to by P is used for type deduction. 3 In general, the deduction process attempts to find template argument values that will make the deduced A identical to A (after the type A is transformed as described above). However, there are three cases that allow a difference: --If the original P is a reference type, the deduced A (i.e., the type referred to by the reference) can be more cv-qualified than A. --A can be another pointer or pointer to member type that can be con- verted to the deduced A via a qualification conversion (_conv.qual_). --If P is a class, and P has the form template-id, then A can be a derived class of the deduced A. Likewise, if P is a pointer to a class of the form template-id, A can be a pointer to a derived class pointed to by the deduced A. These alternatives are considered only if type deduction would other- wise fail. If they yield more than one possible deduced A, the type deduction fails. [Note: if a template-parameter is not used in any of the function parameters of a function template, or is used only in a non-deduced context, its corresponding template-argument cannot be deduced from a function call and the template-argument must be explic- itly specified. ] 14.8.2.2 Deducing template arguments [temp.deduct.funcaddr] taking the address of a function template 1 Template arguments can be deduced from the type specified when taking the address of an overloaded function (_over.over_). The function template's function type and the specified type are used as the types of P and A, and the deduction is done as described in _temp.deduct.type_. 14.8.2.3 Deducing conversion function [temp.deduct.conv] template arguments 1 Template argument deduction is done by comparing the return type of the template conversion function (call it P) with the type that is required as the result of the conversion (call it A) as described in _temp.deduct.type_. 2 If A is not a reference type: --If P is an array type, the pointer type produced by the array-to- pointer standard conversion (_conv.array_) is used in place of P for type deduction; otherwise, --If P is a function type, the pointer type produced by the function- to-pointer standard conversion (_conv.func_) is used in place of P for type deduction; otherwise, --If P is a cv-qualified type, the top level cv-qualifiers of P's type are ignored for type deduction. If A is a cv-qualified type, the top level cv-qualifiers of A's type are ignored for type deduction. If A is a reference type, the type referred to by A is used for type deduction. 3 In general, the deduction process attempts to find template argument values that will make the deduced A identical to A. However, there are two cases that allow a difference: --If the original A is a reference type, A can be more cv-qualified than the deduced A (i.e., the type referred to by the reference) --The deduced A can be another pointer or pointer to member type that can be converted to A via a qualification conversion. These alternatives are considered only if type deduction would other- wise fail. If they yield more than one possible deduced A, the type deduction fails. 14.8.2.4 Deducing template arguments from a [temp.deduct.type] type 1 Template arguments can be deduced in several different contexts, but in each case a type that is specified in terms of template parameters (call it P) is compared with an actual type (call it A), and an attempt is made to find template argument values (a type for a type parameter, a value for a non-type parameter, or a template for a tem- plate parameter) that will make P, after substitution of the deduced values (call it the deduced A), compatible with A. 2 In some cases, the deduction is done using a single set of types P and A, in other cases, there will be a set of corresponding types P and A. Type deduction is done independently for each P/A pair, and the deduced template argument values are then combined. If type deduction cannot be done for any P/A pair, or if for any pair the deduction leads to more than one possible set of deduced values, or if different pairs yield different deduced values, or if any template argument remains neither deduced nor explicitly specified, template argument deduction fails. 3 A given type P can be composed from a number of other types, tem- plates, and non-type values: --A function type includes the types of each of the function parame- ters and the return type. --A pointer to member type includes the type of the class object pointed to and the type of the member pointed to. --A type that is a specialization of a class template (e.g., A) includes the types, templates, and non-type values referenced by the template argument list of the specialization. --An array type includes the array element type and the value of the array bound. In most cases, the types, templates, and non-type values that are used to compose P participate in template argument deduction. That is, they may be used to determine the value of a template argument, and the value so determined must be consistent with the values determined elsewhere. In certain contexts, however, the value does not partici- pate in type deduction, but instead uses the values of template argu- ments that were either deduced elsewhere or explicitly specified. If a template parameter is used only in nondeduced contexts and is not explicitly specified, template argument deduction fails. 4 The nondeduced contexts are: --The nested-name-specifier of a type that was specified using a qual- ified-id. --A type that is a template-id in which one or more of the template- arguments is an expression that references a template-parameter. When a type name is specified in a way that includes a nondeduced con- text, all of the types that comprise that type name are also nonde- duced. However, a compound type can include both deduced and nonde- duced types. [Example: If a type is specified as A::B, both T and T2 are nondeduced. Likewise, if a type is specified as A::X, I, J, and T are nondeduced. If a type is specified as void f(A::B, A), the T in A::B is nondeduced but the T in A is deduced. ] 5 [Example: Here is an example in which different parameter/argument pairs produce inconsistent template argument deductions: template void f(T x, T y) { /* ... */ } struct A { /* ... */ }; struct B : A { /* ... */ }; int g(A a, B b) { f(a,b); // error: T could be A or B f(b,a); // error: T could be A or B f(a,a); // OK: T is A f(b,b); // OK: T is B } 6 Here is an example where two template arguments are deduced from a single function parameter/argument pair. This can lead to conflicts that cause type deduction to fail: template void f( T (*)( T, U, U ) ); int g1( int, float, float); char g2( int, float, float); int g3( int, char, float); void r() { f(g1); // OK: T is int and U is float f(g2); // error: T could be char or int f(g3); // error: U could be char or float } 7 Here is an example where a qualification conversion applies between the argument type on the function call and the deduced template argu- ment type: template void f(const T*) {} int *p; void s() { f(p); // f(const int *) } 8 Here is an example where the template argument is used to instantiate a derived class type of the corresponding function parameter type: template struct B { }; template struct D : public B {}; struct D2 : public B {}; template void f(B&){} void t() { D d; D2 d2; f(d); // calls f(B&) f(d2); // calls f(B&) } --end example] 9 A template type argument T, a template template argument TT or a tem- plate non-type argument i can be deduced if P and A have one of the following forms: T cv-list T T* T& T[integer-constant] template-name (where template-name refers to a class template) type(*)(T) T(*)() T(*)(T) T type::* type T::* T T::* T (type::*)() type (T::*)() type (type::*)(T) type (T::*)(T) T (type::*)(T) T (T::*)() T (T::*)(T) type[i] template-name (where template-name refers to a class template) TT TT TT<> where (T) represents argument lists where at least one argument type contains a T, and () represents argument lists where no parameter con- tains a T. Similarly, represents template argument lists where at least one argument contains a T, represents template argument lists where at least one argument contains an i and <> represents template argument lists where no argument contains a T or an i. 10These forms can be used in the same way as T is for further composi- tion of types. [Example: X (*)(char[6]) is of the form template-name (*)(type[i]) which is a variant of type (*)(T) where type is X and T is char[6]. ] 11Template arguments cannot be deduced from function arguments involving constructs other than the ones specified above. 12A template type argument cannot be deduced from the type of a non-type template-argument. [Example: template void f(double a[10][i]); int v[10][20]; f(v); // error: argument for template-parameter T cannot be deduced --end example] 13[Note: except for reference and pointer types, a major array bound is not part of a function parameter type and cannot be deduced from an argument: template void f1(int a[10][i]); template void f2(int a[i][20]); template void f3(int (&a)[i][20]); void g() { int v[10][20]; f1(v); // OK: i deduced to be 20 f1<20>(v); // OK f2(v); // error: cannot deduce template-argument i f2<10>(v); // OK f3(v); // OK: i deduced to be 10 } 14If, in the declaration of a function template with a non-type tem- plate-parameter, the non-type template-parameter is used in an expres- sion in the function parameter-list, the corresponding template-argu- ment must always be explicitly specified or deduced elsewhere because type deduction would otherwise always fail for such a template-argu- ment. template class A { /* ... */ }; template void g(A); void k() { A<1> a; g(a); // error: deduction fails for expression s+1 g<0>(a); // OK } --end note] [Note: template parameters do not participate in template argument deduction if they are used only in nondeduced contexts. For example, template T deduce(typename A::X x, // T is not deduced here T t, // but T is deduced here typename B::Y y); // i is not deduced here A a; B<77> b; int x = deduce<77>(a.xm, 62, y.ym); // T is deduced to be int, a.xm must be convertible to // A::X // i is explicitly specified to be 77, y.ym must be convertible // to B<77>::Y --end note] 15If, in the declaration of a function template with a non-type tem- plate-parameter, the non-type template-parameter is used in an expres- sion in the function parameter-list and, if the corresponding tem- plate-argument is deduced, the template-argument type shall match the type of the template-parameter exactly, except that a template-argu- ment deduced from an array bound may be of any integral type.132) [Example: template class A { /* ... */ }; template void f(A); void k1() { A<1> a; f(a); // error: deduction fails for conversion from int to short f<1>(a); // OK } template class B { }; template void h(B); void k2() { B<1> b; g(b); // OK: cv-qualifiers are ignored on template parameter types } --end example] 16A template-argument can be deduced from a pointer to function or pointer to member function argument if the set of overloaded functions does not contain function templates and at most one of a set of over- loaded functions provides a unique match. [Example: template void f(void(*)(T,int)); template void foo(T,int); void g(int,int); void g(char,int); _________________________ 132) Although the template-argument corresponding to a template-param- eter of type bool may be deduced from an array bound, the resulting value will always be true because the array bound will be non-zero. void h(int,int,int); void h(char,int); int m() { f(&g); // error: ambiguous f(&h); // OK: void h(char,int) is a unique match f(&foo); // error: type deduction fails because foo is a template } --end example] 17A template type-parameter cannot be deduced from the type of a func- tion default argument. [Example: template void f(T = 5, T = 7); void g() { f(1); // OK: call f(1,7) f(); // error: cannot deduce T f(); // OK: call f(5,7) } --end example] 18The template-argument corresponding to a template template-parameter is deduced from the type of the template-argument of a class template specialization used in the argument list of a function call. [Exam- ple: template