-1- This International Standard specifies requirements for implementations of the C++ programming language. The first such requirement is that they implement the language, and so this International Standard also defines C++. Other requirements and relaxations of the first requirement appear at various places within this International Standard.
-2-
C++ is a general purpose programming language based on the C programming
language as described in
ISO/IEC 9899:1990
Programming languages - C
(intro.refs).
In addition to the facilities provided by C, C++
provides additional data types,
classes,
templates,
exceptions,
namespaces,
inline functions,
operator overloading,
function name overloading,
references,
free store management operators,
and additional library facilities.
1.2 - Normative references [intro.refs]
-1- The following standards contain provisions which, through reference in this text, constitute provisions of this International Standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this International Standard are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. Members of IEC and ISO maintain registers of currently valid International Standards.
-2- The library described in clause 7 of ISO/IEC 9899:1990 and clause 7 of ISO/IEC 9899/Amd.1:1995 is hereinafter called the Standard C Library.*
[Footnote: 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. --- end foonote]
-1- For the purposes of this International Standard, the definitions given in ISO/IEC 2382 and the following definitions apply. lib.definitions defines additional terms that are used only in clauses lib.library through lib.input.output.
-2-
Terms that are used only in a small portion of this International Standard
are defined where they are used and italicized where they are defined.
1.3.1 - argument [defns.argument]
an expression in the comma-separated list bounded by the parentheses in a function call expression,
a sequence of preprocessing tokens in the comma-separated list bounded by the parentheses in a function-like macro invocation,
the operand of
throw,
or an expression,
type-id
or
template-name
in the comma-separated list bounded by the angle brackets in a template instantiation.
Also known as an
actual argument
or
actual parameter.
1.3.2 - diagnostic message [defns.diagnostic]
a message belonging to an implementation-defined subset
of the implementation's output messages.
1.3.3 - dynamic type [defns.dynamic.type]
the type of the most derived object (intro.object)
to which the lvalue denoted by an lvalue expression 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.''
References (dcl.ref) are treated similarly.
]
The dynamic type
of an rvalue expression is its static type.
1.3.4 - ill-formed program [defns.ill.formed]
input to a C++ implementation that is not a well-formed program (defns.well.formed).
1.3.5 - implementation-defined behavior [defns.impl.defined]
behavior,
for a well-formed program construct and correct data,
that depends on the implementation
and that each implementation shall document.
1.3.6 - implementation limits [defns.impl.limits]
restrictions imposed upon programs by the implementation.
1.3.7 - locale-specific behavior [defns.locale.specific]
behavior that depends on local conventions
of nationality, culture, and language
that each implementation shall document.
1.3.8 - multibyte character [defns.multibyte]
a sequence of one or more bytes representing a member
of the extended character set of either the source
or the execution environment.
The extended character set is a superset of the basic character set
(lex.charset).
1.3.9 - parameter [defns.parameter]
an object or reference declared as part of a function declaration or definition, or
in the catch clause of an exception handler, that acquires a value on entry
to the function or handler; an identifier from the comma-separated
list bounded by the parentheses immediately following the macro name in
a function-like macro definition; or a
template-parameter.
Parameters are also known as
formal arguments
or
formal parameters.
1.3.10 - signature [defns.signature]
the information about a function
that participates in overload resolution (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.*
[Footnote: Function signatures do not include return type, because that does not participate in overload resolution. --- end foonote]The signature of a template function specialization includes the types of its template arguments (temp.over.link).
-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:
[Footnote: ``Correct execution'' can include undefined behavior, depending on the data being processed; see intro.defs and intro.execution. --- end foonote]
-3- For classes and class templates, the library clauses specify partial definitions. Private members (clause class.access) are not specified, but each implementation shall supply them to complete the definitions according to the description in the library clauses.
-4- For functions, function templates, objects, and values, the library clauses specify declarations. Implementations shall supply definitions consistent with the descriptions in the library clauses.
-5- The names defined in the library have namespace scope (basic.namespace). A C++ translation unit (lex.phases) obtains access to these names by including the appropriate standard library header (cpp.include).
-6- The templates, classes, functions, and objects in the library have external linkage (basic.link). The implementation provides definitions for standard library entities, as necessary, while combining translation units to form a complete C++ program (lex.phases).
-7- Two kinds of implementations are defined: hosted and freestanding. For a hosted implementation, this International Standard defines the set of available libraries. A freestanding implementation is one in which execution may take place without the benefit of an operating system, and has an implementation-defined set of libraries that includes certain language-support libraries (lib.compliance).
-8-
A conforming implementation may have extensions (including
additional library functions), provided they do not alter the
behavior of any well-formed program.
Implementations are required to diagnose programs that use such
extensions that are ill-formed according to this International Standard.
Having done so, however, they can compile and execute such programs.
1.5 - Structure of this International Standard [intro.structure]
-1- Clauses lex through cpp describe the C++ programming language. That description includes detailed syntactic specifications in a form described in syntax. For convenience, Annex gram repeats all such syntactic specifications.
-2- 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).
-3- Annex limits recommends lower bounds on the capacity of conforming implementations.
-4- Annex diff summarizes the evolution of C++ since its first published description, and explains in detail the differences between C++ and C. Certain features of C++ exist solely for compatibility purposes; Annex depr describes those features.
-5- Finally, Annex extendid says what characters are valid in universal-character names in C++ identifiers (lex.name).
-6-
Throughout this International Standard, each example is introduced by ``[Example:''
and terminated by ``]''.
Each note is introduced by ``[Note:''
and terminated by ``]''.
Examples and notes may be nested.
1.6 - Syntax notation [syntax]
-1- In the syntax notation used in this International Standard, syntactic categories are indicated by italic type, and literal words and characters in constant width type. Alternatives are listed on separate lines except in a few cases where a long set of alternatives is presented on one line, marked by the phrase ``one of.'' An optional terminal or nonterminal symbol is indicated by the subscript ``opt,'' so
{ expressionopt }
-2- Names for syntactic categories have generally been chosen according to the following rules:
-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 execution character set and is composed of a contiguous sequence of bits, the number of which is implementation-defined. The least significant bit is called the low-order bit; the most significant bit is called the high-order bit. The memory available to a C++ program consists of one or more sequences of contiguous bytes. Every byte has a unique address.
-2-
[Note:
the representation of types is described in basic.types.
]
1.8 - The C++ object model [intro.object]
-1- The constructs in a C++ program create, destroy, refer to, access, and manipulate objects. An object is a region of storage. [Note: A function is not an object, regardless of whether or not it occupies storage in the way that objects do. ] An object is created by a definition (basic.def), by a new-expression (expr.new) or by the implementation (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 interpretation 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:
-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 POD*
[Footnote: The acronym POD stands for ``plain old data.'' --- end foonote]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).
]
1.9 - Program execution [intro.execution]
-1- The semantic descriptions in this International Standard define a parameterized nondeterministic abstract machine. This International Standard places no requirement on the structure of conforming implementations. In particular, they need not copy or emulate the structure of the abstract machine. Rather, conforming implementations are required to emulate (only) the observable behavior of the abstract machine as explained below.*
[Footnote: This provision is sometimes called the ``as-if'' rule, because an implementation is free to disregard any requirement of this International Standard as long as the result is as if the requirement had been obeyed, as far as can be determined from the observable behavior of the program. For instance, an actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no side effects affecting the observable behavior of the program are produced. --- end foonote]
-2- Certain aspects and operations of the abstract machine are described in this International Standard as implementation-defined (for example, sizeof(int)). These constitute the parameters of the abstract machine. Each implementation shall include documentation describing its characteristics and behavior in these respects. Such documentation shall define the instance of the abstract machine that corresponds to that implementation (referred to as the ``corresponding instance'' below).
-3- Certain other aspects and operations of the abstract machine are described in this International Standard as unspecified (for example, order of evaluation of arguments to a function). Where possible, this International Standard defines a set of allowable behaviors. These define the nondeterministic aspects of the abstract machine. An instance of the abstract machine can thus have more than one possible execution sequence for a given program and a given input.
-4- Certain other operations are described in this International Standard as undefined (for example, the effect of dereferencing the null pointer). [Note: this International Standard imposes no requirements on the behavior of programs that contain undefined behavior. ]
-5- A conforming implementation executing a well-formed program shall produce the same observable 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.*
[Footnote: An implementation can offer additional library I/O functions as an extension. Implementations that do so should treat calls to those functions as ``observable behavior'' as well. --- end foonote]
-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 subsequent evaluations shall have taken place.*
[Footnote: Note that some aspects of sequencing in the abstract machine are unspecified; the preceding restriction upon side effects applies to that particular execution sequence in which the actual code is generated. Also note that when a call to a library I/O function returns, the side effect is considered complete, even though some external actions implied by the call (such as the I/O itself) may not have completed yet. --- end foonote]
-8- Once the execution of a function begins, no expressions from the calling function are evaluated until execution of the called function has completed.*
[Footnote: In other words, function executions do not ``interleave'' with each other. --- end foonote]
-9- When the processing of the abstract machine is interrupted by receipt of a signal, the values of objects with type other than volatile sig_atomic_t are unspecified, and the value of any object not of volatile sig_atomic_t that is modified by the handler becomes undefined.
-10- An instance of each object with automatic storage duration (basic.stc.auto) is associated with each entry into its block. Such an object exists and retains its last-stored value during the execution of the block and while the block is suspended (by a call of a function or receipt of a signal).
-11- The least requirements on a conforming implementation are:
-12- A full-expression is an expression that is not a subexpression of another expression. If a language construct is defined to produce an implicit call of a function, a use of the language construct is considered to be an expression for the purposes of this definition.
-13- [Note: certain contexts in C++ cause the evaluation of a full-expression that results from a syntactic construct other than expression (expr.comma). For example, in dcl.init one syntax for initializer is
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(expression-list )
but again the resulting construct might be a function call upon a constructor function with one assignment-expression as an argument; again, the function call is a full-expression. ]=initializer-clause
-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.*
[Footnote: Overloaded operators are never assumed to be associative or commutative. --- end foonote]For example, in the following fragment
the expression statement behaves exactly the same asint a, b; /*...*/ a = a + 32760 + b + 5;
due to the associativity and precedence of these operators. Thus, the result of the sum (a + 32760) is next added to b, and that result is then added to 5 which results in the value assigned to a. On a machine in which overflows produce an exception and in which the range of values representable by an int is [-32768,+32767], the implementation cannot rewrite this expression asa = (((a + 32760) + b) + 5);
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 asa = ((a + b) + 32765);
ora = ((a + 32765) + b);
since the values for a and b might have been, respectively, 4 and -8 or -17 and 12. However on a machine in which overflows do not produce an exception and in which the results of overflows are reversible, the above expression statement can be rewritten by the implementation in any of the above ways because the same result will occur. ]a = (a + (b + 32765));
-16- There is a sequence point at the completion of evaluation of each full-expression*.
[Footnote: As specified in class.temporary, after the "end-of-full-expression" sequence point, a sequence of zero or more invocations of destructor functions for temporary objects takes place, usually in reverse order of the construction of each temporary object. --- end foonote]
-17- When calling a function (whether or not the function is inline), there is a sequence point after the evaluation of all function arguments (if any) which takes place before execution of any expressions or statements in the function body. There is also a sequence point after the copying of a returned value and before the execution of any expressions outside the function*.
[Footnote: The sequence point at the function return is not explicitly specified in ISO C, and can be considered redundant with sequence points at full-expressions, but the extra clarity is important in C++. In C++, there are more ways in which a called function can terminate its execution, such as the throw of an exception. --- end foonote]Several contexts in C++ cause evaluation 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 function (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.
-18- In the evaluation of each of the expressions
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 expression*.a && b a || b a ? b : c a , b
[Footnote: The operators indicated in this paragraph are the built-in operators, as described in clause expr. When one of these operators is overloaded (clause over) in a valid context, thus designating a user-defined operator function, the expression designates a function invocation, and the operands form an argument list, without an implied sequence point between them. --- end foonote]
-1- The C++ programming language as described in this International Standard is based on the language as described in Chapter R (Reference Manual) of Stroustrup: The C++ Programming Language (second edition, Addison-Wesley Publishing Company, ISBN 0-201-53992-6, copyright © 1991 AT&T). That, in turn, is based on the C programming language as described in Appendix A of Kernighan and Ritchie: The C Programming Language (Prentice-Hall, 1978, ISBN 0-13-110163-3, copyright © 1978 AT&T).
-2- Portions of the library clauses of this International Standard are based on work by P.J. Plauger, which was published as The Draft Standard C++ Library (Prentice-Hall, ISBN 0-13-117003-1, copyright © 1995 P.J. Plauger).
-3- All rights in these originals are reserved.