_ _____________________________________________________________________________________________________________________________________________________________________________ ___________________________________________

1 General [intro]_ _____________________________________________________________________________________________________________________________________________________________________________ ___________________________________________

[intro.scope] 1.1 Scope

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

2 C + + is a general purpose programming language based on the C programming language as described inISO/IEC 9899:1990 Programming Languages C (1.2). In addition to the facilities provided by C, C + + pro-vides additional data types, classes, templates, exceptions, namespaces, inline functions, operator overload-ing, function name overloading, references, free store management operators, and additional library facili-ties. These extensions to C are summarized in C.1. The differences between C + + and ISO C are summa-rized in C.2. The extensions to C + + since 1985 are summarized in C.1.2.

3 Clauses 17 through 27 (thelibrary clauses) describe the Standard C + + library, which provides definitionsfor the following kinds of entities: macros (16.3), values (3), types (8.1, 8.3), templates (14), classes (9),functions (8.3.5), and objects (7).

4 For classes and class templates, the library clauses specify partial definitions. Private members (11) are notspecified, but each implementation shall supply them to complete the definitions according to the descrip-tion in the library clauses.

5 For functions, function templates, objects, and values, the library clauses specify declarations. Implementa-tions shall supply definitions consistent with the descriptions in the library clauses.

6 The names defined in the library have namespace scope (7.3). A C + + translation unit (2.1) obtains access tothese names by including the appropriate standard library header (16.2).

7 The templates, classes, functions, and objects in the library have external linkage (3.5). The implementa-tion provides definitions for standard library entities, as necessary, while combining translation units toform a complete C + + program (2.1).

[intro.refs] 1.2 Normative references

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

— ISO/IEC 2382Dictionary for Information Processing Systems.

— ISO/IEC 9899:1990Programming Languages– C

— ISO/IEC:1990Programming Languages– C AMENDMENT 1: C Integrity

2 The library described in Clause 7 of the C Standard and Clause 7 of Amendment 1 to the C Standard ishereinafter called theStandard C Library.1)

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

1– 2 General DRAFT: 2 December 1996 1.3 Implementation compliance

[intro.compliance] 1.3 Implementation compliance

1 The set of“diagnosable semantic rules” consists of all semantic rules in this International Standard exceptfor those rules containing an explicit notation that“no diagnostic is required.”

2 Every conforming C + + implementation shall, within its resource limits, accept and correctly execute well-formed C + + programs, and shall issue at least one diagnostic message when presented with any ill-formedprogram that contains a violation of any diagnosable semantic rule or of any syntax rule.

3 If an ill-formed program contains no violations of diagnosable semantic rules, this International Standardplaces no requirement on implementations with respect to that program.

4 Two kinds of implementations are defined:hostedand freestanding. For a hosted implementation, thisInternational Standard defines the set of available libraries. A freestanding implementation is one in whichexecution may take place without the benefit of an operating system, and has an implementation-defined setof libraries that includes certain language-support libraries (17.3.1.3).

5 Although this International Standard states only requirements on C + + implementations, those requirementsare often easier to understand if they are phrased as requirements on programs, parts of programs, or execu-tion of programs. Such requirements have the following meaning:

— Whenever this International Standard places a diagnosable requirement on the form of a program (thatis, the characters, tokens, syntactic elements, and types that make up the program), and a program doesnot meet that requirement, the program is ill-formed and the implementation shall issue a diagnosticmessage when processing that program.

— Whenever this International Standard places a requirement on the execution of a program (that is, thevalues of data that are used as part of program execution) and the data encountered during execution donot meet that requirement, the behavior of the program is undefined and this International Standardplaces no requirements at all on the behavior of the program.

6 In this International Standard, a term is italicized when it is first defined. In this International Standard, theexamples, 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.

7 A conforming implementation may have extensions (including additional library functions), provided theydo not alter the behavior of any well-formed program. One example of such an extension is allowing iden-tifiers to contain characters outside the basic source character set. Implementations are required to diagnoseprograms that use such extensions that are ill-formed according to this Standard. Having done so, however,they can compile and execute such programs.

[intro.defs] 1.4 Definitions

1 For the purposes of this International Standard, the definitions given in ISO/IEC 2382 and the followingdefinitions apply.

— argument: An expression in the comma-separated list bounded by the parentheses in a function callexpression, a sequence of preprocessing tokens in the comma-separated list bounded by the parenthesesin a function-like macro invocation, the operand ofthrow , or an expression,type-idor template-namein the comma-separated list bounded by the angle brackets in a template instantiation. Also known asan“actual argument” or “actual parameter.”

— diagnostic message: A message belonging to an implementation-defined subset of theimplementation’s output messages.

— dynamic type: Thedynamic typeof an lvalue expression is the type of the most derived object (1.7) towhich the lvalue refers. [Example:if a pointer (8.3.1)p whose static type is“pointer to classB” ispointing to an object of classD, derived fromB (10), the dynamic type of the expression*p is “D.” Ref-erences (8.3.2) are treated similarly. ] Thedynamic typeof an rvalue expression is its static type.

1.4 Definitions DRAFT: 2 December 1996 General 1– 3

— ill-formed program: input to a C + + implementation that is not a well-formed program (q. v.).

— implementation-defined behavior: Behavior, for a well-formed program construct and correct data,that depends on the implementation and that each implementation shall document.

— implementation limits: Restrictions imposed upon programs by the implementation.

— locale-specific behavior:Behavior that depends on local conventions of nationality, culture, and lan-guage that each implementation shall document.

— multibyte character: A sequence of one or more bytes representing a member of the extended charac-ter set of either the source or the execution environment. The extended character set is a superset of thebasic character set (2.2).

— parameter: an object or reference declared as part of a function declaration or definition, or in the catchclause of an exception handler that acquires a value on entry to the function or handler; an identifierfrom the comma-separated list bounded by the parentheses immediately following the macro name in afunction-like macro definition; or atemplate-parameter. Parameters are also known as“formal argu-ments” or “formal parameters.”

— signature: The signature of a function is the information about that function that participates in over-load resolution (13.3): the types of its parameters and, if the function is a class member, thecv- quali-fiers (if any) on the function itself and the class in which the member function is declared.2) The signa-ture of a template function specialization includes the types of its template arguments (14.5.5.1).

— static type: The static typeof an expression is the type (3.9) resulting from analysis of the programwithout consideration of execution semantics. It depends only on the form of the program and does notchange while the program is executing.

— undefined behavior: Behavior, such as might arise upon use of an erroneous program construct or oferroneous data, for which the Standard imposes no requirements. Undefined behavior may also beexpected when the standard omits the description of any explicit definition of behavior. [Note:permis-sible undefined behavior ranges from ignoring the situation completely with unpredictable results, tobehaving during translation or program execution in a documented manner characteristic of the environ-ment (with or without the issuance of a diagnostic message), to terminating a translation or execution(with the issuance of a diagnostic message). Note that many erroneous program constructs do notengender undefined behavior; they are required to be diagnosed. ]

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

— well-formed program: a C + + program constructed according to the syntax rules, diagnosable semanticrules, and the One Definition Rule (3.2).

2 Clause 17.1 defines additional terms that are used only in the library clauses (17– 27).

[syntax] 1.5 Syntax notation

1 In the syntax notation used in this International Standard, syntactic categories are indicated byitalic type,and literal words and characters inconstant width type. Alternatives are listed on separate linesexcept in a few cases where a long set of alternatives is presented on one line, marked by the phrase“oneof.” An optional terminal or nonterminal symbol is indicated by the subscript“opt,” so

{ expressionopt }

indicates an optional expression enclosed in braces.

__________________2) Function signatures do not include return type, because that does not participate in overload resolution.

1– 4 General DRAFT: 2 December 1996 1.5 Syntax notation

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

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

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

— X-seqis one or moreX’s without intervening delimiters (e.g.declaration-seqis a sequence of declara-tions).

— X-list is one or moreX’s separated by intervening commas (e.g.expression-listis a sequence of expres-sions separated by commas).

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

1 The fundamental storage unit in the C + + memory model is thebyte. A byte is at least large enough to con-tain any member of the basic execution character set and is composed of a contiguous sequence of bits, thenumber of which is implementation-defined. The least significant bit is called thelow-order bit; the mostsignificant bit is called thehigh-orderbit. The memory available to a C + + program consists of one or moresequences of contiguous bytes. Every byte has a unique address.

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

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

1 The constructs in a C + + program create, destroy, refer to, access, and manipulate objects. Anobject is aregion of storage. An object is created by adefinition (3.1), by anew-expression(5.3.4) or by the imple-mentation (12.2) when needed. The properties of an object are determined when the object is created. Anobject can have aname(3). An object has astorage duration(3.7) which influences itslifetime (3.8). Anobject has atype (3.9). The termobject typerefers to the type with which the object is created. Someobjects arepolymorphic(10.3); the implementation generates information associated with each such objectthat makes it possible to determine that object’s type during program execution. For other objects, theinterpretation of the values found therein is determined by the type of theexpressions (5) used to accessthem.

2 Objects can contain other objects, calledsub-objects. A sub-object can be amember sub-object(9.2), abase class sub-object(10), or an array element. An object that is not a sub-object of any other object iscalled acomplete object.

3 For every objectx , there is some object calledthe complete object ofx , determined as follows:

— If x is a complete object, thenx is the complete object ofx .

— Otherwise, the complete object ofx is the complete object of the (unique) object that containsx .

If a complete object, a data member (9.2), or an array element is of class type, its type is considered themost derivedclass, to distinguish it from the class type of any base class subobject; an object of a mostderived class type is called amost derived object.

4 Unless it is a bit-field (9.6), a most derived object shall have a non-zero size and shall occupy one or morebytes of storage. Base class sub-objects may have zero size. An object of POD type (3.9) shall occupycontiguous bytes of storage.

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

1.8 Program execution DRAFT: 2 December 1996 General 1– 5

[intro.execution] 1.8 Program execution

1 The semantic descriptions in this International Standard define a parameterized nondeterministic abstractmachine. This International Standard places no requirement on the structure of conforming implementa-tions. In particular, they need not copy or emulate the structure of the abstract machine. Rather, conform-ing implementations are required to emulate (only) the observable behavior of the abstract machine asexplained below.3)

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

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

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

5 A conforming implementation executing a well-formed program shall produce the same observable behav-ior as one of the possible execution sequences of the corresponding instance of the abstract machine withthe same program and the same input. However, if any such execution sequence contains an undefinedoperation, this International Standard places no requirement on the implementation executing that programwith 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 callsto library I/O functions.4)

7 Accessing an object designated by a volatile lvalue (3.10), modifying an object, calling a library I/O func-tion, or calling a function that does any of those operations are allside effects, which are changes in thestate of the execution environment. Evaluation of an expression might produce side effects. At certainspecified points in the execution sequence calledsequence points, all side effects of previous evaluationsshall be complete and no side effects of subsequent evaluations shall have taken place.5)

8 Once the execution of a function begins, no expressions from the calling function are evaluated until execu-tion of the called function has completed.6)

9 In the abstract machine, all expressions are evaluated as specified by the semantics. An actual implementa-tion need not evaluate part of an expression if it can deduce that its value is not used and that no neededside effects are produced (including any caused by calling a function or accessing a volatile object).

10 When the processing of the abstract machine is interrupted by receipt of a signal, the values of objects mod-ified after the preceding sequence point are indeterminate during the execution of the signal handler, andthe value of any object not ofvolatile sig_atomic_t that is modified by the handler becomesundefined.__________________3) This provision is sometimes called the“as-if” rule, because an implementation is free to disregard any requirement of the Standardas long as the result isas if the requirement had been obeyed, as far as can be determined from the observable behavior of the program.4) An implementation can offer additional library I/O functions as an extension. Implementations that do so should treat calls to thosefunctions as ‘‘observable behavior’’ as well.5) Note that some aspects of sequencing in the abstract machine are unspecified; the preceding restriction upon side effects applies tothat particular execution sequence in which the actual code is generated. Also note that when a call to a library I/O function returns,the side effect is considered complete, even though some external actions implied by the call (such as the I/O itself) may not have com-pleted yet.6) In other words, function executions do not interleave with each other.

1– 6 General DRAFT: 2 December 1996 1.8 Program execution

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

12 The least requirements on a conforming implementation are:

— At sequence points, volatile objects are stable in the sense that previous evaluations are complete andsubsequent evaluations have not yet occurred.

— At program termination, all data written into files shall be identical to one of the possible results thatexecution of the program according to the abstract semantics would have produced.

— The input and output dynamics of interactive devices shall take place in such a fashion that promptingmessages actually appear prior to a program waiting for input. What constitutes an interactive device isimplementation-defined.

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

13 A full-expressionis an expression that is not a subexpression of another expression.

14 [Note: certain contexts in C + + cause the evaluation of a full-expression that results from a syntactic con-struct other thanexpression(5.18). For example, in 8.5 one syntax forinitializer is

( expression-list)

but the resulting construct is a function call upon a constructor function withexpression-listas an argumentlist; such a function call is a full-expression. For example, in 8.5, another syntax forinitializer is

= initializer-clause

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

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

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

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

the expression statement behaves exactly the same as

a = (((a + 32760) + b) + 5);

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

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

since if the values fora andb were, respectively,– 32754 and– 15, the suma + b would produce anexception while the original expression would not; nor can the expression be rewritten either as

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

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

1.8 Program execution DRAFT: 2 December 1996 General 1– 7

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

since the values fora and b might have been, respectively, 4 and– 8 or – 17 and 12. However on amachine in which overflows do not produce an exception and in which the results of overflows arereversible, the above expression statement can be rewritten by the implementation in any of the above waysbecause the same result will occur. ]

17 There is a sequence point at the completion of evaluation of each full-expression8).

18 When calling a function (whether or not the function is inline), there is a sequence point after the evaluationof all function arguments (if any) which takes place before execution of any expressions or statements inthe function body. There is also a sequence point after the copying of a returned value and before the exe-cution of any expressions outside the function9). Several contexts in C + + cause evaluation of a functioncall, even though no corresponding function call syntax appears in the translation unit. [Example:evalua-tion of anew expression invokes one or more allocation and constructor functions; see 5.3.4. For anotherexample, invocation of a conversion function (12.3.2) can arise in contexts in which no function call syntaxappears. ] The sequence points at function-entry and function-exit (as described above) are features of thefunction calls as evaluated, whatever the syntax of the expression that calls the function might be.

19 In the evaluation of each of the expressions

a && ba || ba ? b : ca , b

using the built-in meaning of the operators in these expressions (5.14, 5.15, 5.16, 5.18) there is a sequencepoint after the evaluation of the first expression10).

__________________8) As specified in 12.2, after the "end-of-full-expression" sequence point, a sequence of zero or more invocations of destructor func-tions for temporary objects takes place, usually in reverse order of the construction of each temporary object.9) The sequence point at the function return is not explicitly specified in ISO C, and can be considered redundant with sequence pointsat full-expressions, but the extra clarity is important in C + +. In C + +, there are more ways in which a called function can terminate itsexecution, such as the throw of an exception.10) The operators indicated in this paragraph are the built-in operators, as described in Clause 5. When one of these operators is over-loaded (13) in a valid context, thus designating a user-defined operator function, the expression designates a function invocation, andthe operands form an argument list, without an implied sequence point between them.

_ _____________________________________________________________________________________________________________________________________________________________________________ ___________________________________________

2 Lexical conventions [lex]_ _____________________________________________________________________________________________________________________________________________________________________________ ___________________________________________

1 The text of the program is kept in units calledsource filesin this International Standard. A source filetogether with all the headers (17.3.1.2) and source files included (16.2) via the preprocessing directive#include , less any source lines skipped by any of the conditional inclusion (16.1) preprocessing direc-tives, is called atranslation 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 inlibraries. The separate translation units of a program communicate (3.5) by (for example) calls to functionswhose identifiers have external linkage, manipulation of objects whose identifiers have external linkage, ormanipulation of data files. Translation units can be separately translated and then later linked to produce anexecutable program. (3.5). ]

[lex.phases] 2.1 Phases of translation

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

1 Physical source file characters are mapped, in an implementation-defined manner, to the sourcecharacter set (introducing new-line characters for end-of-line indicators) if necessary. Trigraphsequences (2.3) are replaced by corresponding single-character internal representations. Any sourcefile character not in the basic source character set (2.2) is replaced by the universal-character-namethat designates that character.12)

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 thatmatches the syntax of a universal-character-name is produced, the behavior is undefined. If a sourcefile that is not empty does not end in a new-line character, or ends in a new-line character immedi-ately preceded by a backslash character, the behavior is undefined.

3 The source file is decomposed into preprocessing tokens (2.4) and sequences of white-space charac-ters (including comments). A source file shall not end in a partial preprocessing token or partialcomment13). 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 orreplaced by one space character is implementation-defined. The process of dividing a source file’scharacters into preprocessing tokens is context-dependent. [Example:see the handling of< within a#include preprocessing directive. ]

4 Preprocessing directives are executed and macro invocations are expanded. If a character sequencethat matches the syntax of a universal-character-name is produced by token concatenation (16.3.3),the behavior is undefined. A#include preprocessing directive causes the named header or sourcefile to be processed from phase 1 through phase 4, recursively.

__________________11) Implementations must behave as if these separate phases occur, although in practice different phases might be folded together.12)The process of handling extended characters is specified in terms of mapping to an encoding that uses only the basic source charac-ter set, and, in the case of character literals and strings, further mapping to the execution character set. In practical terms, however, anyinternal encoding may be used, so long as an actual extended character encountered in the input, and the same extended characterexpressed in the input as a universal-character-name (i.e. using the notation), are handled equivalently.13)A partial preprocessing token would arise from a source file ending in the first portion of a multi-character token that requires a ter-minating sequence of characters, such as aheader-namethat is missing the closing" or >. A partial comment would arise from asource file ending with an unclosed/* comment.

2– 2 Lexical conventions DRAFT: 2 December 1996 2.1 Phases of translation

5 Each source character set member, escape sequence, or universal-character-name in character literalsand string literals is converted to a member of the execution character set.

6 Adjacent ordinary string literal tokens are concatenated. Adjacent wide string literal tokens are con-catenated.

7 White-space characters separating tokens are no longer significant. Each preprocessing token is con-verted into a token. (2.6). The resulting tokens are syntactically and semantically analyzed andtranslated. [Note:Source files, translation units and translated translation units need not necessarilybe stored as files, nor need there be any one-to-one correspondence between these entities and anyexternal representation. The description is conceptual only, and does not specify any particularimplementation. ]

8 Translated translation units and instantiation units are combined as follows: [Note: some or all ofthese may be supplied from a library. ] Each translated translation unit is examined to produce a listof required instantiations. [Note: this may include instantiations which have been explicitlyrequested (14.7.2). ] The definitions of the required templates are located. It is implementation-defined whether the source of the translation units containing these definitions is required to beavailable. [Note:an implementation could encode sufficient information into the translated transla-tion unit so as to ensure the source is not required here. ] All the required instantiations are per-formed to produceinstantiation units. [Note: these are similar to translated translation units, butcontain no references to uninstantiated templates and no template definitions. ] The program is ill-formed if any instantiation fails.

9 All external object and function references are resolved. Library components are linked to satisfyexternal references to functions and objects not defined in the current translation. All such translatoroutput is collected into a program image which contains information needed for execution in its exe-cution environment.

[lex.charset] 2.2 Basic source character set

1 The basic source character setconsists of 96 characters: the space character, the control characters repre-senting horizontal tab, vertical tab, form feed, and new-line, plus the following 91 graphical characters:

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 zA B C D E F G H I J K L M N O P Q R S T U V W X Y Z0 1 2 3 4 5 6 7 8 9_ { } [ ] # ( ) < > % : ; . ? * + - / ^ & | ~ ! = , \ " ’

2 Theuniversal-character-nameconstruct 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\UNNNNNNNNis that character whose encodingin ISO/IEC 10646 is the hexadecimal valueNNNNNNNN; the character designated by the universal-character-name\uNNNN is that character whose encoding in ISO/IEC 10646 is the hexadecimal value0000NNNN.

[lex.trigraph] 2.3 Trigraph sequences

1 Before any other processing takes place, each occurrence of one of the following sequences of three charac-ters (“trigraph sequences”) is replaced by the single character indicated in Table 1.

2.3 Trigraph sequences DRAFT: 2 December 1996 Lexical conventions 2– 3

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 [Note:no other trigraph sequence exists. Each? that does not begin one of the trigraphs listed above is notchanged. ]

4 Trigraph replacement is done left to right, so that when two sequences which could represent trigraphsoverlap, only the first sequence is replaced. Characters that result from trigraph replacement are never partof a subsequent trigraph. [Example: The sequence "???=" becomes "?=", not "?#". The sequence"?????????" becomes "???", not "?".—end example]

[lex.pptoken] 2.4 Preprocessing tokens

preprocessing-token:header-nameidentifierpp-numbercharacter-literalstring-literalpreprocessing-op-or-punceach non-white-space character that cannot be one of the above

1 Each preprocessing token that is converted to a token (2.6) shall have the lexical form of a keyword, anidentifier, a literal, an operator, or a punctuator.

2 A preprocessing tokenis the minimal lexical element of the language in translation phases 3 through 6.The categories of preprocessing token are:header names, identifiers, preprocessing numbers, characterliterals, string literals, preprocessing-op-or-punc, and single non-white-space characters that do not lexi-cally match the other preprocessing token categories. If a’ or a" character matches the last category, thebehavior is undefined. Preprocessing tokens can be separated bywhite space; this consists of comments(2.7), orwhite-space characters(space, horizontal tab, new-line, vertical tab, and form-feed), or both. Asdescribed in Clause 16, in certain circumstances during translation phase 4, white space (or the absencethereof) serves as more than preprocessing token separation. White space can appear within a preprocess-ing token only as part of a header name or between the quotation characters in a character literal or stringliteral.

3 If the input stream has been parsed into preprocessing tokens up to a given character, the next preprocessingtoken is the longest sequence of characters that could constitute a preprocessing token, even if that wouldcause further lexical analysis to fail.

4 [Example:The program fragment1Ex is parsed as a preprocessing number token (one that is not a validfloating or integer literal token), even though a parse as the pair of preprocessing tokens1 andEx mightproduce a valid expression (for example, ifEx were a macro defined as+1). Similarly, the program frag-ment1E1 is parsed as a preprocessing number (one that is a valid floating literal token), whether or notE is

2– 4 Lexical conventions DRAFT: 2 December 1996 2.4 Preprocessing tokens

a macro name. ]

5 [Example:The program fragmentx+++++y is parsed asx ++ ++ + y , which, if x andy are of built-intypes, violates a constraint on increment operators, even though the parsex ++ + ++ y might yield acorrect expression. ]

[lex.digraph] 2.5 Alternative tokens

1 Alternative token representations are provided for some operators and punctuators14).

2 In all respects of the language, each alternative token behaves the same, respectively, as its primary token,except for its spelling15). The set of alternative tokens is defined in Table 2.

Table 2—alternative tokens_ ______________________________________________________________alternative primary alternative primary alternative primary_ _______________________________________________________________ ______________________________________________________________

} bitor | or_eq |=_ ______________________________________________________________ ] xor ^ not !_ ______________________________________________________________%: # compl ~ not_eq !=_ ______________________________________________________________

%:%: ## bitand &_ ______________________________________________________________

[lex.token] 2.6 Tokens

token:identifierkeywordliteraloperatorpunctuator

1 There are five kinds of tokens: identifiers, keywords, literals,16) operators, and other separators. Blanks,horizontal and vertical tabs, newlines, formfeeds, and comments (collectively,“white space”), as describedbelow, are ignored except as they serve to separate tokens. Some white space is required to separate other-wise adjacent identifiers, keywords, and literals.

[lex.comment] 2.7 Comments

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

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

2.8 Header names DRAFT: 2 December 1996 Lexical conventions 2– 5

[lex.header] 2.8 Header names

header-name:

" q-char-sequence"

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

h-char:any member of the source character set except

new-line and>

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

q-char:any member of the source character set except

new-line and"

1 Header name preprocessing tokens shall only appear within a#include preprocessing directive (16.2).The sequences in both forms ofheader-names are mapped in an implementation-defined manner to headersor to external source file names as specified in 16.2.

2 If either of the characters’ or \ , or either of the character sequences/* or // appears in aq-char-sequenceor a h-char-sequence, or the character" appears in ah-char-sequence, the behavior is unde-fined.17)

[lex.ppnumber] 2.9 Preprocessing numbers

pp-number:digit. digitpp-number digitpp-number nondigitpp-numbere signpp-numberE signpp-number.

1 Preprocessing number tokens lexically include all integral literal tokens (2.13.1) and all floating literaltokens (2.13.3).

2 A preprocessing number does not have a type or a value; it acquires both after a successful conversion (aspart of translation phase 7, 2.1) to an integral literal token or a floating literal token.

[lex.name] 2.10 Identifiers

identifier:nondigitidentifier nondigitidentifier digit

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

2– 6 Lexical conventions DRAFT: 2 December 1996 2.10 Identifiers

nondigit: one ofuniversal-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 zA B C D E F G H I J K L MN O P Q R S T U V W X Y Z

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

1 An identifier is an arbitrarily long sequence of letters and digits. Each universal-character-name in an iden-tifier shall designate a character whose encoding in ISO 10646 falls into one of the ranges specified in E.Upper- and lower-case letters are different. All characters are significant.18)

2 In addition, identifiers containing a double underscore (_ _ ) or beginning with an underscore and anupper-case letter are reserved for use by C + + implementations and standard libraries and shall not be usedotherwise; no diagnostic is required.

[lex.key] 2.11 Keywords

1 The identifiers shown in Table 3 are reserved for use as keywords (that is, they are unconditionally treatedas keywords in phase 7):

Table 3—keywords_ _____________________________________________________________________________________asm do inline short typeidauto double int signed typenamebool dynamic_cast long sizeof unionbreak else mutable static unsignedcase enum namespace static_cast usingcatch explicit new struct virtualchar extern operator switch voidclass false private template volatileconst float protected this wchar_tconst_cast for public throw whilecontinue friend register truedefault goto reinterpret_cast trydelete if return typedef_ _____________________________________________________________________________________

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

Table 4—alternative representations_ _______________________________________________________and and_eq bitand bitor compl notnot_eq or or_eq xor xor_eq_ _______________________________________________________

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

2.12 Operators and punctuators DRAFT: 2 December 1996 Lexical conventions 2– 7

2.12 Operators and punctuators

1 The lexical representation of C + + programs includes a number of preprocessing tokens which are used inthe 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_eqxor xor_eq

Eachpreprocessing-op-or-puncis converted to a single token in translation phase 7 (2.1).

[lex.literal] 2.13 Literals

1 There are several kinds of literals.19)

literal:integer-literalcharacter-literalfloating-literalstring-literalboolean-literal

[lex.icon] 2.13.1 Integer literals

integer-literal:decimal-literal integer-suffixoptoctal-literal integer-suffixopthexadecimal-literal integer-suffixopt

decimal-literal:nonzero-digitdecimal-literal digit

octal-literal:0octal-literal octal-digit

hexadecimal-literal:0x hexadecimal-digit0X hexadecimal-digithexadecimal-literal hexadecimal-digit

nonzero-digit: one of1 2 3 4 5 6 7 8 9

octal-digit: one of0 1 2 3 4 5 6 7

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

2– 8 Lexical conventions DRAFT: 2 December 1996 2.13.1 Integer literals

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

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

unsigned-suffix:one ofu U

long-suffix: one ofl L

1 An integer literal is a sequence of digits that has no period or exponent part. An integer literal may have aprefix that specifies its base and a suffix that specifies its type. The lexically first digit of the sequence ofdigits is the most significant. Adecimalinteger literal (base ten) begins with a digit other than0 and con-sists of a sequence of decimal digits. Anoctal integer literal (base eight) begins with the digit0 and con-sists of a sequence of octal digits.20) An hexadecimalinteger literal (base sixteen) begins with0x or 0X andconsists of a sequence of hexadecimal digits, which include the decimal digits and the lettersa throughfandA throughF with decimal values ten through fifteen. [Example:the number twelve can be written12 ,014 , or0XC. ]

2 The type of an integer literal depends on its form, value, and suffix. If it is decimal and has no suffix, it hasthe first of these types in which its value can be represented:int , long int , unsigned long int .21)

If it is octal or hexadecimal and has no suffix, it has the first of these types in which its value can be repre-sented:int , unsigned int , long int , unsigned long int . If it is suffixed byu or U, its type isthe first of these types in which its value can be represented:unsigned int , unsigned long int . Ifit is suffixed byl 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 byul , lu , uL , Lu , Ul , lU , UL, or LU, its type isunsignedlong int .

3 A program is ill-formed if one of its translation units contains an integer literal that cannot be representedby any of the allowed types.

[lex.ccon] 2.13.2 Character literals

character-literal:’ c-char-sequence’L’ c-char-sequence’

c-char-sequence:c-charc-char-sequence c-char

c-char:any member of the source character set except

the single-quote’ , backslash\ , or new-line characterescape-sequenceuniversal-character-name

__________________20)The digits8 and9 are not octal digits.21) A decimal integer literal with no suffix never has typeunsigned int . Otherwise, for example, on an implementation whereunsigned int values have 16 bits andunsigned long values have strictly more than 17 bits, we would have-300000 (because50000 would have typeunsigned int ), and-70000

2.13.2 Character literals DRAFT: 2 December 1996 Lexical conventions 2– 9

escape-sequence:simple-escape-sequenceoctal-escape-sequencehexadecimal-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-digithexadecimal-escape-sequence hexadecimal-digit

1 A character literal is one or more characters enclosed in single quotes, as in’x’ , optionally preceded bythe letterL, as inL’x’ . A character literal that does not begin withL is an ordinary character literal, alsoreferred to as a narrow-character literal. An ordinary character literal that contains a singlec-charhas typechar , with value equal to the numerical value of the encoding of thec-char in the execution character set.An ordinary character literal that contains more than onec-char is amulticharacter literal. A multicharac-ter literal has typeint and implementation-defined value.

2 A character literal that begins with the letterL, such asL’x’ , is a wide-character literal. A wide-characterliteral has typewchar_t .22) The value of a wide-character literal containing a singlec-char has valueequal to the numerical value of the encoding of thec-char in the execution wide-character set. The value ofa wide-character literal containing multiplec-chars is implementation-defined.

3 Certain nongraphic characters, the single quote’ , the double quote" , the question mark?, and the back-slash\ , can be represented according to Table 5.

Table 5—escape sequences_ ______________________________new-line NL (LF) \nhorizontal tab HT \tvertical tab VT \vbackspace BS \bcarriage return CR \rform feed FF \falert BEL \abackslash \ \\question mark ? \?single quote ’ \’double quote " \"octal number ooo \ooohex 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 escapesequences\’ and\\ respectively. If the character following a backslash is not one of those specified, thebehavior is undefined. An escape sequence specifies a single character.__________________22)They are intended for character sets where a character does not fit into a single byte.

2– 10 Lexical conventions DRAFT: 2 December 1996 2.13.2 Character literals

4 The escape\ oooconsists of the backslash followed by one, two, or three octal digits that are taken to spec-ify the value of the desired character. The escape\x hhhconsists of the backslash followed byx followedby one or more hexadecimal digits that are taken to specify the value of the desired character. There is nolimit to the number of digits in a hexadecimal sequence. A sequence of octal or hexadecimal digits is ter-minated by the first character that is not an octal digit or a hexadecimal digit, respectively. The value of acharacter literal is implementation-defined if it falls outside of the implementation-defined range definedfor char (for ordinary literals) orwchar_t (for wide literals).

5 A universal-character-name is translated to the encoding, in the execution character set, of the characternamed. If there is no such encoding, the universal-character-name is translated to an implementation-defined encoding. [Note: in translation phase 1, a universal-character-name is introduced whenever anactual extended character is encountered in the source text. Therefore, all extended characters are describedin terms of universal-character-names. However, the actual compiler implementation may use its ownnative character set, so long as the same results are obtained. ]

[lex.fcon] 2.13.3 Floating literals

floating-literal:fractional-constant exponent-partopt floating-suffixoptdigit-sequence exponent-part floating-suffixopt

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

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

sign: one of+ -

digit-sequence:digitdigit-sequence digit

floating-suffix: one off l F L

1 A floating literal consists of an integer part, a decimal point, a fraction part, ane or E, an optionally signedinteger exponent, and an optional type suffix. The integer and fraction parts both consist of a sequence ofdecimal (base ten) digits. Either the integer part or the fraction part (not both) can be omitted; either thedecimal point or the lettere (or E) and the exponent (not both) can be omitted. The integer part, theoptional decimal point and the optional fraction part form thesignificant partof the floating literal. Theexponent, if present, indicates the power of 10 by which the significant part is to be scaled. If the scaledvalue is in the range of representable values for its type, the result is the scaled value if representable, elsethe larger or smaller representable value nearest the scaled value, chosen in an implementation-definedmanner. The type of a floating literal isdouble unless explicitly specified by a suffix. The suffixesf andF specify float , the suffixesl andL specify long double . If the scaled value is not in the range ofrepresentable values for its type, the program is ill-formed.

[lex.string] 2.13.4 String literals

string-literal:" s-char-sequenceopt"L" s-char-sequenceopt"

2.13.4 String literals DRAFT: 2 December 1996 Lexical conventions 2– 11

s-char-sequence:s-chars-char-sequence s-char

s-char:any member of the source character set except

the double-quote" , backslash\ , or new-line characterescape-sequenceuniversal-character-name

1 A string literal is a sequence of characters (as defined in 2.13.2) surrounded by double quotes, optionallybeginning with the letterL, as in"..." or L"..." . A string literal that does not begin withL is an ordi-nary string literal, also referred to as a narrow string literal. An ordinary string literal has type“array ofnconst char ” andstaticstorage duration (3.7), wheren is the size of the string as defined below, and isinitialized with the given characters. A string literal that begins withL, such asL"asdf" , is a wide stringliteral. A wide string literal has type“array ofn const wchar_t ” and has static storage duration, wheren is the size of the string as defined below, and is initialized with the given characters.

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

3 In translation phase 6 (2.1), adjacent narrow string literals are concatenated and adjacent wide string literalsare concatenated. If a narrow string literal token is adjacent to a wide string literal token, the behavior isundefined. Characters in concatenated strings are kept distinct. [Example:

"\xA" "B"

contains the two characters’\xA’ and ’B’ after concatenation (and not the single hexadecimal character’\xAB’ ). ]

4 After any necessary concatenation, in translation phase 7 (2.1),’\0’ is appended to every string literal sothat programs that scan a string can find its end.

5 Escape sequences and universal-character-names in string literals have the same meaning as in character lit-erals (2.13.2), except that the single quote’ is representable either by itself or by the escape sequence\’ ,and the double quote" shall be preceded by a\ . In a narrow string literal, a universal-character-name maymap to more than onechar element due tomultibyte encoding. The size of a wide string literal is the totalnumber of escape sequences, universal-character-names, and other characters, plus one for the terminatingL’\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’ .

[lex.bool] 2.13.5 Boolean literals

boolean-literal:falsetrue

1 The Boolean literals are the keywordsfalse andtrue . Such literals have typebool . They are not lval-ues.

_ _____________________________________________________________________________________________________________________________________________________________________________ ___________________________________________

3 Basic concepts [basic]_ _____________________________________________________________________________________________________________________________________________________________________________ ___________________________________________

1 [Note: this clause presents the basic concepts of the C + + language. It explains the difference between anobjectand anameand how they relate to the notion of anlvalue. It introduces the concepts of adeclarationand adefinition and presents C + +’s notion oftype, scope, linkage, andstorage duration. The mechanismsfor starting and terminating a program are discussed. Finally, this clause presents the fundamental types ofthe language and lists the ways of constructingcompoundtypes from these.

2 This clause does not cover concepts that affect only a single part of the language. Such concepts are dis-cussed in the relevant clauses. ]

3 An entity is a value, object, subobject, base class subobject, array element, variable, function, instance of afunction, enumerator, type, class member, template, or namespace.

4 A nameis a use of an identifier (2.10) that denotes an entity orlabel (6.6.4, 6.1). Avariable is introducedby the declaration of an object. The variable’s name denotes the object.

5 Every name that denotes an entity is introduced by adeclaration. Every name that denotes a label is intro-duced either by agoto statement (6.6.4) or alabeled-statement(6.1).

6 Some names denote types, classes, enumerations, or templates. In general, it is necessary to determinewhether or not a name denotes one of these entities before parsing the program that contains it. The processthat determines this is calledname lookup(3.4).

7 Two names arethe sameif

— they are identifiers composed of the same character sequence; or

— they are the names of overloaded operator functions formed with the same operator; or

— they are the names of user-defined conversion functions formed with the same type.

8 An identifier used in more than one translation unit can potentially refer to the same entity in these transla-tion units depending on the linkage (3.5) of the identifier specified in each translation unit.

[basic.def] 3.1 Declarations and definitions

1 A declaration (7) introduces names into a translation unit or redeclares names introduced by previous decla-rations. A declaration specifies the interpretation and attributes of these names.

2 A declaration is adefinition unless it declares a function without specifying the function’s body (8.4), itcontains theextern specifier (7.1.1) or alinkage-specification23) (7.5) and neither aninitializer nor afunction-body, it declares a static data member in a class declaration (9.4), it is a class name declaration(9.1), or it is atypedef declaration (7.1.3), ausing-declaration(7.3.3), or ausing-directive(7.3.4).

3 [Example:all but one of the following are definitions:

__________________23) Appearing inside the braced-encloseddeclaration-seqin a linkage-specificationdoes not affect whether a declaration is a defini-tion.

3– 2 Basic concepts DRAFT: 2 December 1996 3.1 Declarations and definitions

int a; // definesaextern const int c = 1; // definescint f(int x) { return x+a; } // definesf and definesxstruct S { int a; int b; }; // definesS, S::a , andS::bstruct X { // definesX

int x; // defines nonstatic data memberxstatic int y; // declares static data memberyX(): x(0) { } // defines a constructor ofX

};int X::y = 1; // definesX::yenum { up, down }; // definesup and downnamespace N { int d; } // definesN and N::dnamespace N1 = N; // definesN1X anX; // definesanX

whereas these are just declarations:

extern int a; // declaresaextern const int c; // declarescint f(int); // declaresfstruct S; // declaresStypedef int Int; // declaresIntextern X anotherX; // declaresanotherXusing N::d; // declaresN::d

—end example]

4 [Note: in some circumstances, C + + implementations implicitly define the default constructor (12.1), copyconstructor (12.8), assignment operator (12.8), or destructor (12.4) member functions. [Example:given

struct C {string s; // string is the standard library class (21)

};

int main(){

C a;C b = a;b = a;

}

the implementation will implicitly define functions to make the definition ofCequivalent 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 anelaborated-type-specifier(3.3.1). ]

6 A program is ill-formed if the definition of any object gives the object an incompletely-defined object type(3.9).

[basic.def.odr] 3.2 One definition rule

1 No translation unit shall contain more than one definition of any variable, function, class type, enumerationtype or template.

3.2 One definition rule DRAFT: 2 December 1996 Basic concepts 3– 3

2 An expression ispotentially evaluatedunless either it is the operand of thesizeof operator (5.3.3), or it isthe operand of thetypeid operator and does not designate an lvalue of polymorphic class type (5.2.8).An object or non-overloaded function isusedif its name appears in a potentially-evaluated expression. Avirtual member function is used if it is not pure. An overloaded function is used if it is selected by overloadresolution when referred to from a potentially-evaluated expression. [Note: this covers calls to named func-tions (5.2.2), operator overloading (13), user-defined conversions (12.3.2), allocation function for place-ment new (5.3.4), as well as non-default initialization (8.5). A copy constructor is used even if the call isactually elided by the implementation. ] An allocation or deallocation function for a class is used by a newexpression appearing in a potentially-evaluated expression as specified in 5.3.4 and 12.5. A deallocationfunction for a class is used by a delete expression appearing in a potentially-evaluated expression as speci-fied in 5.3.5 and 12.5. A copy-assignment function for a class is used by an implicitly-defined copy-assignment function for another class as specified in 12.8. A default constructor for a class is used bydefault initialization as specified in 8.5. A constructor for a class is used as specified in 8.5. A destructorfor a class is used as specified in 12.4.

3 Every program shall contain exactly one definition of every non-inline function or object that is used in thatprogram; no diagnostic required. The definition can appear explicitly in the program, it can be found in thestandard or a user-defined library, or (when appropriate) it is implicitly defined (see 12.1, 12.4 and 12.8).An inline function shall be defined in every translation unit in which it is used.

4 Exactly one definition of a class is required in a translation unit if the class is used in a way that requires theclass type to be complete. [Example:the following complete translation unit is well-formed, even though itnever definesX:

struct X; // declareX as a struct typestruct X* x1; // useX in pointer formationX* x2; // useX in pointer formation

—end example] [Note:the rules for declarations and expressions describe in which contexts complete classtypes are required. A class typeT must be complete if:

— an object of typeT is defined (3.1, 5.3.4), or

— an lvalue-to-rvalue conversion is applied to an lvalue referring to an object of typeT (4.1), or

— an expression is converted (either implicitly or explicitly) to typeT (4, 5.2.3, 5.2.7, 5.2.9, 5.4), or

— an expression is converted to the type pointer toT or reference toT using an implicit conversion (4), adynamic_cast (5.2.7) or astatic_cast (5.2.9), or

— a class member access operator is applied to an expression of typeT (5.2.5), or

— thetypeid operator (5.2.8) or thesizeof operator (5.3.3) is applied to an operand of typeT, or

— a function with a return type or argument type of typeT is defined (3.1) or called (5.2.2), or

— an lvalue of typeT is assigned to (5.17). ]

5 There can be more than one definition of a class type (9), enumeration type (7.2), inline function with exter-nal linkage (7.1.2), class template (14), non-static function template (14.5.5), static data member of a classtemplate (14.5.1.3), member function template (14.5.1.1), or template specialization for which some tem-plate parameters are not specified (14.7, 14.5.4) in a program provided that each definition appears in a dif-ferent translation unit, and provided the definitions satisfy the following requirements. Given such anentity namedDdefined in more than one translation unit, then

— each definition ofDshall consist of the same sequence of tokens; and

— in each definition ofD, corresponding names, looked up according to 3.4, shall refer to an entity definedwithin the definition ofD, or shall refer to the same entity, after overload resolution (13.3) and aftermatching of partial template specialization (14.8.3), except that a name can refer to aconst objectwith internal or no linkage if the object has the same integral or enumeration type in all definitions ofD,and the object is initialized with a constant expression (5.19), and the value (but not the address) of the

3– 4 Basic concepts DRAFT: 2 December 1996 3.2 One definition rule

object is used, and the object has the same value in all definitions ofD; and

— in each definition ofD, the overloaded operators referred to, the implicit calls to conversion operators,constructors, operator new functions and operator delete functions, shall refer to the same function, or toa function defined within the definition ofD; and

— in each definition ofD, a default argument used by an (implicit or explicit) function call is treated as ifits token sequence were present in the definition ofD; that is, the default argument is subject to the threerequirements described above (and, if the default argument has sub-expressions with default arguments,this requirement applies recursively).24)

— if D is a class with an implicitly-declared constructor (12.1), it is as if the constructor was implicitlydefined in every translation unit where it is used, and the implicit definition in every translation unitshall call the same constructor for a base class or a class member ofD. [Example:

// translation unit 1:struct X {

X(int);X(int, int);

};X::X(int = 0) { }class D: public X { };D d2; // X(int) called by D()

// translation unit 2:struct X {

X(int);X(int, int);

};X::X(int = 0, int = 0) { }class D: public X { }; // X(int, int) called by D();

// D()’s implicit definition// violates the ODR

—end example] If D is a template, and is defined in more than one translation unit, then the last fourrequirements from the list above shall apply to names from the template’s enclosing scope used in the tem-plate definition (14.6.3), and also to dependent names at the point of instantiation (14.6.2). If the defini-tions ofDsatisfy all these requirements, then the program shall behave as if there were a single definition ofD. If the definitions ofDdo not satisfy these requirements, then the behavior is undefined.

[basic.scope] 3.3 Declarative regions and scopes

1 Every name is introduced in some portion of program text called adeclarative region, which is the largestpart of the program in which that name isvalid, that is, in which that name may be used as an unqualifiedname to refer to the same entity. In general, each particular name is valid only within some possibly dis-contiguous portion of program text called itsscope. To determine the scope of a declaration, it is some-times convenient to refer to thepotential scopeof a declaration. The scope of a declaration is the same asits potential scope unless the potential scope contains another declaration of the same name. In that case,the potential scope of the declaration in the inner (contained) declarative region is excluded from the scopeof the declaration in the outer (containing) declarative region.

2 [Example:in

__________________24)8.3.6 describes how default argument names are looked up.

3.3 Declarative regions and scopes DRAFT: 2 December 1996 Basic concepts 3– 5

int j = 24;int main(){

int i = j, j;j = 42;

}

the identifierj is declared twice as a name (and used twice). The declarative region of the firstj includesthe entire example. The potential scope of the firstj begins immediately after thatj and extends to the endof the program, but its (actual) scope excludes the text between the, and the} . The declarative region ofthe second declaration ofj (the j immediately before the semicolon) includes all the text between{ and} ,but its potential scope excludes the declaration ofi . The scope of the second declaration ofj is the sameas its potential scope. ]

3 The names declared by a declaration are introduced into the scope in which the declaration occurs, exceptthat the presence of afriend specifier (11.4), certain uses of theelaborated-type-specifier(3.3.1), andusing-directives (7.3.4) alter this general behavior.

4 [Note:the name look up rules are summarized in 3.4. ]

[basic.scope.pdecl] 3.3.1 Point of declaration

1 Thepoint of declarationfor a name is immediately after its complete declarator (8) and before itsinitializer(if any), except as noted below. [Example:

int x = 12;{ int x = x; }

Here the secondx 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 itsenumerator-definition. [Example:

const int x = 12;{ enum { x = x }; }

Here, the enumeratorx is initialized with the value of the constantx , namely 12. ]

4 After the point of declaration of a class member, the member name can be looked up in the scope of itsclass. [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 anelaborated-type-specifieris as follows:

— for anelaborated-type-specifierof the form

class-key identifier;

theelaborated-type-specifierdeclares theidentifier to be aclass-namein the scope that contains the decla-ration, otherwise

— for anelaborated-type-specifierof the form

3– 6 Basic concepts DRAFT: 2 December 1996 3.3.1 Point of declaration

class-key identifier

if the elaborated-type-specifieris used in thedecl-specifier-seqor parameter-declaration-clauseof a func-tion defined in namespace scope, theidentifier is declared as aclass-namein the namespace that containsthe declaration; otherwise, except as a friend declaration, theidentifier is declared in the smallest non-class,non-function-prototype scope that contains the declaration. [Note: if the elaborated-type-specifierdesig-nates an enumeration, theidentifier must refer to an already declaredenum-name. If the identifier in theelaborated-type-specifieris a qualified-id, it must refer to an already declaredclass-nameor enum-name.See 3.4.4. ]

6 [Note:friend declarations refer to functions or classes that are members of the nearest enclosing namespace,but they do not introduce new names into that namespace (7.3.1.2). Function declarations at block scopeand object declarations with theextern specifier at block scope refer to delarations that are members ofan enclosing namespace, but they do not introduce new names into that scope. ]

7 [Note:For point of instantiation of a template, see 14.7.1. ]

[basic.scope.local] 3.3.2 Local scope

1 A name declared in a block (6.3) is local to that block. Its potential scope begins at its point of declaration(3.3.1) and ends at the end of its declarative region.

2 The potential scope of a function parameter name in a function definition (8.4) begins at its point of decla-ration. If the function has afunction try-blockthe potential scope of a parameter ends at the end of the lastassociated handler, else it ends at the end of the outermost block of the function definition. A parametername shall not be redeclared in the outermost block of the function definition nor in the outermost block ofany handler associated with afunction try-block .

3 The name in acatch exception-declaration is local to the handler and shall not be redeclared in the outer-most block of the handler.

4 Names declared in thefor-init-statement, and in theconditionof if , while , for , andswitch statementsare local to theif , while , for , or switch statement (including the controlled statement), and shall notbe redeclared in a subsequent condition of that statement nor in the outermost block (or, for theif state-ment, any of the outermost blocks) of the controlled statement; see 6.4.

[basic.scope.proto] 3.3.3 Function prototype scope

1 In a function declaration, or in any function declarator except the declarator of a function definition (8.4),names of parameters (if supplied) have function prototype scope, which terminates at the end of the nearestenclosing function declarator.

3.3.4 Function scope

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

[basic.scope.namespace] 3.3.5 Namespace scope

1 The declarative region of anamespace-definitionis itsnamespace-body. The potential scope denoted by anoriginal-namespace-nameis the concatenation of the declarative regions established by each of thenamespace-definitionsin the same declarative region with thatoriginal-namespace-name. Entities declaredin a namespace-bodyare said to bemembersof the namespace, and names introduced by these declarationsinto the declarative region of the namespace are said to bemember namesof the namespace. A namespacemember name has namespace scope. Its potential scope includes its namespace from the name’s point ofdeclaration (3.3.1) onwards; and for eachusing-directive(7.3.4) that nominates the member’s namespace,the member’s potential scope includes that portion of the potential scope of theusing-directivethat followsthe member’s point of declaration. [Example:

3.3.5 Namespace scope DRAFT: 2 December 1996 Basic concepts 3– 7

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 k+a; // k is from unnamed namespace}

int i; // error: duplicate definitionint j(); // ok: duplicate function declaration

int j() // ok: definition of N::j(){

return g(i); // calls N::g(int)}int q(); // error: different return type

}

—end example]

2 A namespace member can also be referred to after the:: scope resolution operator (5.1) applied to thename of its namespace or the name of a namespace which nominates the member’s namespace in ausing-directive;see 3.4.3.2.

3 A name declared outside all named or unnamed namespaces (7.3), blocks (6.3), function declarations(8.3.5), function definitions (8.4) and classes (9) hasglobal namespace scope(also calledglobal scope).The potential scope of such a name begins at its point of declaration (3.3.1) and ends at the end of the trans-lation unit that is its declarative region. Names declared in the global namespace scope are said to beglobal.

[basic.scope.class] 3.3.6 Class scope

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 followingthe name’s declarator, but also of all function bodies, default arguments, and constructorctor-initializers in that class (including such things in nested classes).

2) A nameNused in a classS shall refer to the same declaration in its context and when re-evaluated in thecompleted scope ofS. 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), theprogram’s behavior is ill-formed, no diagnostic is required.

4) A name declared within a member function hides a declaration of the same name whose scope extendsto or past the end of the member function’s class.

5) The potential scope of a declaration that extends to or past the end of a class definition also extends tothe regions defined by its member definitions, even if the members are defined lexically outside theclass (this includes static data member definitions, nested class definitions, member function definitions(including the member function body and, for constructor functions (12.1), the ctor-initializer (12.6.2))and any portion of the declarator part of such definitions which follows the identifier, including aparameter-declaration-clauseand any default arguments (8.3.6). [Example:

3– 8 Basic concepts DRAFT: 2 December 1996 3.3.6 Class scope

typedef int c;enum { i = 1 };

class X {char v[i]; // error: ’i’ refers to ::i

// but when reevaluated is X::iint f() { return sizeof(c); } // okay: X::cchar 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;

};

—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 (10) from its class,

— after the. operator applied to an expression of the type of its class (5.2.5) or a class derived from itsclass,

— after the-> operator applied to a pointer to an object of its class (5.2.5) or a class derived from its class,

— after the:: scope resolution operator (5.1) applied to the name of its class or a class derived from itsclass.

[basic.scope.hiding] 3.3.7 Name hiding

1 A name can be hidden by an explicit declaration of that same name in a nested declarative region or derivedclass (10.2).

2 A class name (9.1) or enumeration name (7.2) can be hidden by the name of an object, function, or enumer-ator declared in the same scope. If a class or enumeration name and an object, function, or enumerator aredeclared in the same scope (in any order) with the same name, the class or enumeration name is hiddenwherever 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 theclass with the same name; see 3.3.6. The declaration of a member in a derived class (10) hides the declara-tion of a member of a base class of the same name; see 10.2.

4 During the lookup of a name qualified by a namespace name, declarations that would otherwise be madevisible by ausing-directivecan be hidden by declarations with the same name in the namespace containingtheusing-directive;see (3.4.3.2).

5 If a name is in scope and is not hidden it is said to bevisible.

[basic.lookup] 3.4 Name look up

1 The name look up rules apply uniformly to all names (includingtypedef-names(7.1.3),namespace-names(7.3) andclass-names(9.1)) wherever the grammar allows such names in the context discussed by a partic-ular rule. Name look up associates the use of a name with a declaration (3.1) of that name. Name look upshall find an unambiguous declaration for the name (see 10.2). Name look up may associate more than onedeclaration with a name if it finds the name to be a function name; the declarations are said to form a set ofoverloaded functions (13.1). Overload resolution (13.3) takes place after name look up has succeeded. The

3.4 Name look up DRAFT: 2 December 1996 Basic concepts 3– 9

access rules (11) are considered only once name look up and function overload resolution (if applicable)have succeeded. Only after name look up, function overload resolution (if applicable) and access checkinghave succeeded are the attributes introduced by the name’s declaration used further in expression process-ing (5).

2 A name“looked up in the context of an expression” is looked up as an unqualified name in the scope wherethe expression is found.

3 [Note: 3.5 discusses linkage issues. The notions of scope, point of declaration and name hiding are dis-cussed in 3.3. ]

[basic.lookup.unqual] 3.4.1 Unqualified name look up

1 In all the cases listed in this subclause, the scopes are searched for a declaration in the order listed in eachof the respective categories; name look up ends as soon as a declaration is found for the name. If no decla-ration is found, the program is ill-formed.

2 The declarations from the namespace nominated by ausing-directivebecome visible in a namespaceenclosing theusing-directive; see 7.3.4. For the purpose of the unqualified name look up rules described inthis subclause, the declarations from the namespace nominated by theusing-directiveare considered mem-bers of that enclosing namespace.

3 The lookup for an unqualified name used as thepostfix-expressionof a function call is described in 3.4.2.[Note: for purposes of determining (during parsing) whether an expression is apostfix-expressionfor afunction call, the usual name lookup rules apply. The rules in 3.4.2 have no effect on the syntactic interpre-tation of an expression. For example,

typedef int f;struct A {

friend void f(A &);operator int();void g(A a) {

f(a);}

};

The expressionf(a) is acast-expressionequivalent toint(a) . Because the expression is not a functioncall, the argument-dependent name lookup (3.4.2) does not apply and the friend functionf is not found. ]

4 A name used in global scope, outside of any function, class or user-declared namespace, shall be declaredbefore its use in global scope.

5 A name used in a user-declared namespace outside of the definition of any function or class shall bedeclared before its use in that namespace or before its use in a namespace enclosing its namespace.

6 A name used in the definition of a function25) that is a member of namespaceN (where, only for the pur-pose of exposition,Ncould represent the global scope) shall be declared before its use in the block in whichit is used or in one of its enclosing blocks (6.3) or, shall be declared before its use in namespaceNor, if N isa nested namespace, shall be declared before its use in one ofN’s enclosing namespaces. [Example:

__________________25) This refers to unqualified names following the function declarator; such a name may be used as a type or as a default argumentname in theparameter-declaration-clause, or may be used in the function body.

3– 10 Basic concepts DRAFT: 2 December 1996 3.4.1 Unqualified name look up

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 classX outside of a member function body or nested class definition26)

shall be declared in one of the following ways:

— before its use in classX or be a member of a base class ofX (10.2), or

— if X is a nested class of classY (9.7), before the definition ofX in Y, or shall be a member of a base classof Y (this look up applies in turn toY’s enclosing classes, starting with the innermost enclosingclass),27) or

— if X is a local class (9.8) or is a nested class of a local class, before the definition of classX in a blockenclosing the definition of classX, or

— if X is a member of namespaceN, or is a nested class of a class that is a member ofN, or is a local classor a nested class within a local class of a function that is a member ofN, before the definition of classXin namespaceNor in one ofN’s enclosing namespaces.

[Example:

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 afrienddeclaration, scopes outside of the innermost enclosing namespace scope are not considered; see 7.3.1.2. ][Note:3.3.6 further describes the restrictions on the use of names in a class definition. 9.7 further describesthe restrictions on the use of names in nested class definitions. 9.8 further describes the restrictions on the__________________26) This refers to unqualified names following the class name; such a name may be used in thebase-clauseor may be used in the classdefinition.27) This look up applies whether the definition ofX is nested withinY’s definition or whetherX’s definition appears in a namespacescope enclosingY’s definition (9.7).

3.4.1 Unqualified name look up DRAFT: 2 December 1996 Basic concepts 3– 11

use of names in local class definitions. ]

8 A name used in the definition of a function that is a member function (9.3)28) of classX shall be declared inone of the following ways:

— before its use in the block in which it is used or in an enclosing block (6.3), or

— shall be a member of classX or be a member of a base class ofX (10.2), or

— if X is a nested class of classY (9.7), shall be a member ofY, or shall be a member of a base class ofY(this look up applies in turn toY’s enclosing classes, starting with the innermost enclosing class),29) or

— if X is a local class (9.8) or is a nested class of a local class, before the definition of classX in a blockenclosing the definition of classX, or

— if X is a member of namespaceN, or is a nested class of a class that is a member ofN, or is a local classor a nested class within a local class of a function that is a member ofN, before the member functiondefinition, in namespaceNor in one ofN’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:9.3 and 9.4 further describe the restrictions on the use of names in member functiondefinitions. 9.7 further describes the restrictions on the use of names in the scope of nested classes. 9.8 fur-ther describes the restrictions on the use of names in local class definitions. ]

9 Name look up for a name used in the definition of afriend function (11.4) defined inline in the classgranting friendship shall proceed as described for look up in member function definitions. If thefriendfunction is not defined in the class granting friendship, name look up in thefriend function definitionshall proceed as described for look up in namespace member function definitions.

10 During the lookup for a name used as a default argument (8.3.6) in a functionparameter-declaration-clauseor used in theexpressionof a mem-initializerfor a constructor (12.6.2), the function parameter names arevisible and hide the names of entities declared in the block, class or namespace scopes containing the func-tion declaration. [Note: 8.3.6 further describes the restrictions on the use of names in default arguments.12.6.2 further describes the restrictions on the use o