______________________________________________________________________
1 General [intro]
______________________________________________________________________
1.1 Scope [intro.scope]
1 This International Standard specifies requirements for implementations
of the C++ programming language. The first such requirement is that
they implement the language, and so this International Standard also
defines C++. Other requirements and relaxations of the first require-
ment appear at various places within the Standard.
2 C++ is a general purpose programming language based on the C program-
ming language as described in ISO/IEC 9899:1990 Programming Languages
C (_intro.refs_). In addition to the facilities provided by C, C++
provides additional data types, classes, templates, exceptions, names-
paces, inline functions, operator overloading, function name overload-
ing, references, free store management operators, and additional
library facilities. The differences between C++ and ISO C are summa-
rized in _diff.iso_.
3 Clauses _lib.library_ through _lib.input.output_ (the library clauses)
describe the Standard C++ library, which provides definitions for the
following kinds of entities: macros (_cpp.replace_), values (clause
_basic_), types (_dcl.name_, _dcl.meaning_), templates (clause
_temp_), classes (clause _class_), functions (_dcl.fct_), and objects
(clause _dcl.dcl_).
4 For classes and class templates, the library clauses specify partial
definitions. Private members (clause _class.access_) are not speci-
fied, but each implementation shall supply them to complete the defi-
nitions according to the description in the library clauses.
5 For functions, function templates, objects, and values, the library
clauses specify declarations. Implementations shall supply defini-
tions consistent with the descriptions in the library clauses.
6 The names defined in the library have namespace scope (_basic.names-
pace_). A C++ translation unit (_lex.phases_) obtains access to these
names by including the appropriate standard library header
(_cpp.include_).
7 The templates, classes, functions, and objects in the library have
external linkage (_basic.link_). The implementation provides defini-
tions for standard library entities, as necessary, while combining
translation units to form a complete C++ program (_lex.phases_).
1.2 Normative references [intro.refs]
1 The following standards contain provisions which, through reference in
this text, constitute provisions of this International Standard. At
the time of publication, the editions indicated were valid. All stan-
dards are subject to revision, and parties to agreements based on this
International Standard are encouraged to investigate the possibility
of applying the most recent editions of the standards indicated below.
Members of IEC and ISO maintain registers of currently valid Interna-
tional Standards.
--ISO/IEC 2382 Dictionary for Information Processing Systems.
--ISO/IEC 9899:1990 Programming Languages - C
--ISO/IEC:1990 Programming Languages - C AMENDMENT 1: C Integrity
--ISO/IEC 10646-1:1993 Information technology - Universal Multiple-
Octet Coded Character Set (UCS) - Part 1: Architecture and Basic
Multilingual Plane
2 The library described in clause 7 of the C Standard and clause 7 of
Amendment 1 to the C Standard is hereinafter called the Standard C
Library.1)
1.3 Implementation compliance [intro.compliance]
1 The set of "diagnosable rules" consists of all syntactic and semantic
rules in this International Standard except for those rules containing
an explicit notation that "no diagnostic is required" or which are
described as resulting in "undefined behavior."
2 Although this International Standard states only requirements on C++
implementations, those requirements are often easier to understand if
they are phrased as requirements on programs, parts of programs, or
execution of programs. Such requirements have the following meaning:
--If a program contains no violations of the rules in this Interna-
tional Standard, a conforming implementation shall, within its
resource limits, accept and correctly execute2) that program.
--If a program contains a violation of any diagnosable rule, a con-
forming implementation shall issue at least one diagnostic message,
except that
--If a program contains a violation of a rule for which no diagnostic
is required, this International Standard places no requirement on
_________________________
1) With the qualifications noted in clauses _lib.library_ through
_lib.input.output_, and in _diff.library_, the Standard C library is a
subset of the Standard C++ library.
2) "Correct execution" can include undefined behavior, depending on
the data being processed; see _intro.defs_ and _intro.execution_.
implementations with respect to that program.
3 Two kinds of implementations are defined: hosted and freestanding.
For a hosted implementation, this International Standard defines the
set of available libraries. A freestanding implementation is one in
which execution may take place without the benefit of an operating
system, and has an implementation-defined set of libraries that
includes certain language-support libraries (_lib.compliance_).
4 In this International Standard, a term is italicized when it is first
defined. In this International Standard, the examples, the notes, the
footnotes, and the non-normative annexes are not part of the normative
Standard. Each example is introduced by "[Example:" and terminated by
"]". Each note is introduced by "[Note:" and terminated by "]".
Examples and notes may be nested.
5 A conforming implementation may have extensions (including additional
library functions), provided they do not alter the behavior of any
well-formed program. Implementations are required to diagnose pro-
grams that use such extensions that are ill-formed according to this
Standard. Having done so, however, they can compile and execute such
programs.
1.4 Definitions [intro.defs]
1 For the purposes of this International Standard, the definitions given
in ISO/IEC 2382 and the following definitions apply.
1.4.1 argument [defns.argument]
an expression in the comma-separated list bounded by the parentheses
in a function call expression, a sequence of preprocessing tokens in
the comma-separated list bounded by the parentheses in a function-like
macro invocation, the operand of throw, or an expression, type-id or
template-name in the comma-separated list bounded by the angle brack-
ets in a template instantiation. Also known as an "actual argument"
or "actual parameter."
1.4.2 diagnostic message [defns.diagnostic]
a message belonging to an implementation-defined subset of the imple-
mentation's output messages.
1.4.3 dynamic type [defns.dynamic.type]
the dynamic type of an lvalue expression is the type of the most
derived object (_intro.object_) to which the lvalue refers. [Example:
if a pointer (_dcl.ptr_) p whose static type is "pointer to class B"
is pointing to an object of class D, derived from B (clause
_class.derived_), the dynamic type of the expression *p is D." Refer-
ences (_dcl.ref_) are treated similarly. ] The dynamic type of an
rvalue expression is its static type.
1.4.4 ill-formed program [defns.ill.formed]
input to a C++ implementation that is not a well-formed program (q.
v.).
1.4.5 implementation-defined behavior [defns.impl.defined]
behavior, for a well-formed program construct and correct data, that
depends on the implementation and that each implementation shall docu-
ment.
1.4.6 implementation limits [defns.impl.limits]
restrictions imposed upon programs by the implementation.
1.4.7 locale-specific behavior [defns.locale.specific]
behavior that depends on local conventions of nationality, culture,
and language that each implementation shall document.
1.4.8 multibyte character [defns.multibyte]
a sequence of one or more bytes representing a member of the extended
character set of either the source or the execution environment. The
extended character set is a superset of the basic character set
(_lex.charset_).
1.4.9 parameter [defns.parameter]
an object or reference declared as part of a function declaration or
definition, or in the catch clause of an exception handler that
acquires a value on entry to the function or handler; an identifier
from the comma-separated list bounded by the parentheses immediately
following the macro name in a function-like macro definition; or a
template-parameter. Parameters are also known as "formal arguments"
or "formal parameters."
1.4.10 signature [defns.signature]
the information about a function that participates in overload resolu-
tion (_over.match_): the types of its parameters and, if the function
is a class member, the cv- qualifiers (if any) on the function itself
and the class in which the member function is declared.3) The signa-
ture of a template function specialization includes the types of its
template arguments (_temp.over.link_).
1.4.11 static type [defns.static.type]
of an expression, the type (_basic.types_) resulting from analysis of
the program without consideration of execution semantics. It depends
only on the form of the program and does not change while the program
is executing.
1.4.12 undefined behavior [defns.undefined]
behavior, such as might arise upon use of an erroneous program con-
struct or of erroneous data, for which the Standard imposes no
requirements. Undefined behavior may also be expected when the stan-
dard omits the description of any explicit definition of behavior.
_________________________
3) Function signatures do not include return type, because that does
not participate in overload resolution.
[Note: permissible undefined behavior ranges from ignoring the situa-
tion completely with unpredictable results, to behaving during trans-
lation or program execution in a documented manner characteristic of
the environment (with or without the issuance of a diagnostic mes-
sage), to terminating a translation or execution (with the issuance of
a diagnostic message). Note that many erroneous program constructs do
not engender undefined behavior; they are required to be diagnosed. ]
1.4.13 unspecified behavior [defns.unspecified]
behavior, for a well-formed program construct and correct data, that
depends on the implementation. The implementation is not required to
document which behavior occurs. [Note: usually, the range of possible
behaviors is delineated by the Standard. ]
1.4.14 well-formed program [defns.well.formed]
a C++ program constructed according to the syntax rules, diagnosable
semantic rules, and the One Definition Rule (_basic.def.odr_).
1 _lib.definitions_ defines additional terms that are used only in the
library clauses (_lib.library_-_lib.input.output_).
1.5 Syntax notation [syntax]
1 In the syntax notation used in this International Standard, syntactic
categories are indicated by italic type, and literal words and charac-
ters in constant width type. Alternatives are listed on separate
lines except in a few cases where a long set of alternatives is pre-
sented on one line, marked by the phrase "one of." An optional termi-
nal or nonterminal symbol is indicated by the subscript "opt," so
{ expressionopt }
indicates an optional expression enclosed in braces.
2 Names for syntactic categories have generally been chosen according to
the following rules:
--X-name is a use of an identifier in a context that determines its
meaning (e.g. class-name, typedef-name).
--X-id is an identifier with no context-dependent meaning (e.g. qual-
ified-id).
--X-seq is one or more X's without intervening delimiters (e.g. dec-
laration-seq is a sequence of declarations).
--X-list is one or more X's separated by intervening commas (e.g.
expression-list is a sequence of expressions separated by commas).
1.6 The C++ memory model [intro.memory]
1 The fundamental storage unit in the C++ memory model is the byte. A
byte is at least large enough to contain any member of the basic exe-
cution character set and is composed of a contiguous sequence of bits,
the number of which is implementation-defined. The least significant
bit is called the low-order bit; the most significant bit is called
the high-order bit. The memory available to a C++ program consists of
one or more sequences of contiguous bytes. Every byte has a unique
address.
2 [Note: the representation of types is described in _basic.types_. ]
1.7 The C++ object model [intro.object]
1 The constructs in a C++ program create, destroy, refer to, access, and
manipulate objects. An object is a region of storage. [Note: A func-
tion is not an object, regardless of whether or not it occupies stor-
age in the way that objects do. ] An object is created by a defini-
tion (_basic.def_), by a new-expression (_expr.new_) or by the imple-
mentation (_class.temporary_) when needed. The properties of an
object are determined when the object is created. An object can have
a name (class _basic_). An object has a storage duration
(_basic.stc_) which influences its lifetime (_basic.life_). An object
has a type (_basic.types_). The term object type refers to the type
with which the object is created. Some objects are polymorphic
(_class.virtual_); the implementation generates information associated
with each such object that makes it possible to determine that
object's type during program execution. For other objects, the inter-
pretation of the values found therein is determined by the type of the
expressions (class _expr_) used to access them.
2 Objects can contain other objects, called sub-objects. A sub-object
can be a member sub-object (_class.mem_), a base class sub-object
(clause _class.derived_), or an array element. An object that is not
a sub-object of any other object is called a complete object.
3 For every object x, there is some object called the complete object of
x, determined as follows:
--If x is a complete object, then x is the complete object of x.
--Otherwise, the complete object of x is the complete object of the
(unique) object that contains x.
4 If a complete object, a data member (_class.mem_), or an array element
is of class type, its type is considered the most derived class, to
distinguish it from the class type of any base class subobject; an
object of a most derived class type is called a most derived object.
5 Unless it is a bit-field (_class.bit_), a most derived object shall
have a non-zero size and shall occupy one or more bytes of storage.
Base class sub-objects may have zero size. An object of POD4) type
(_basic.types_) shall occupy contiguous bytes of storage.
6 [Note: C++ provides a variety of built-in types and several ways of
composing new types from existing types (_basic.types_). ]
_________________________
4) The acronym POD stands for "plain old data."
1.8 Program execution [intro.execution]
1 The semantic descriptions in this International Standard define a
parameterized nondeterministic abstract machine. This International
Standard places no requirement on the structure of conforming imple-
mentations. In particular, they need not copy or emulate the struc-
ture of the abstract machine. Rather, conforming implementations are
required to emulate (only) the observable behavior of the abstract
machine as explained below.5)
2 Certain aspects and operations of the abstract machine are described
in this International Standard as implementation-defined (for example,
sizeof(int)). These constitute the parameters of the abstract
machine. Each implementation shall include documentation describing
its characteristics and behavior in these respects. Such documenta-
tion shall define the instance of the abstract machine that corre-
sponds to that implementation (referred to as the ``corresponding
instance'' below).
3 Certain other aspects and operations of the abstract machine are
described in this International Standard as unspecified (for example,
order of evaluation of arguments to a function). Where possible, the
Standard defines a set of allowable behaviors. These define the non-
deterministic aspects of the abstract machine. An instance of the
abstract machine can thus have more than one possible execution
sequence for a given program and a given input.
4 Certain other operations are described in this International Standard
as undefined (for example, the effect of dereferencing the null
pointer). [Note: this International Standard imposes no requirements
on the behavior of programs that contain undefined behavior. ]
5 A conforming implementation executing a well-formed program shall pro-
duce the same observable behavior as one of the possible execution
sequences of the corresponding instance of the abstract machine with
the same program and the same input. However, if any such execution
sequence contains an undefined operation, this International Standard
places no requirement on the implementation executing that program
with that input (not even with regard to operations preceding the
first undefined operation).
6 The observable behavior of the abstract machine is its sequence of
reads and writes to volatile data and calls to library I/O
functions.6)
_________________________
5) This provision is sometimes called the "as-if" rule, because an im-
plementation is free to disregard any requirement of the Standard as
long as the result is as if the requirement had been obeyed, as far as
can be determined from the observable behavior of the program. For
instance, an actual implementation need not evaluate part of an ex-
pression if it can deduce that its value is not used and that no side
effects affecting the observable behavior of the program are produced.
6) An implementation can offer additional library I/O functions as an
extension. Implementations that do so should treat calls to those
7 Accessing an object designated by a volatile lvalue (_basic.lval_),
modifying an object, calling a library I/O function, or calling a
function that does any of those operations are all side effects, which
are changes in the state of the execution environment. Evaluation of
an expression might produce side effects. At certain specified points
in the execution sequence called sequence points, all side effects of
previous evaluations shall be complete and no side effects of subse-
quent evaluations shall have taken place.7)
8 Once the execution of a function begins, no expressions from the call-
ing function are evaluated until execution of the called function has
completed.8)
9 When the processing of the abstract machine is interrupted by receipt
of a signal, the values of objects with type other than volatile
sig_atomic_t are unspecified, and the value of any object not of
volatile sig_atomic_t that is modified by the handler becomes unde-
fined.
10An instance of each object with automatic storage duration
(_basic.stc.auto_) is associated with each entry into its block. Such
an object exists and retains its last-stored value during the execu-
tion of the block and while the block is suspended (by a call of a
function or receipt of a signal).
11The least requirements on a conforming implementation are:
--At sequence points, volatile objects are stable in the sense that
previous evaluations are complete and subsequent evaluations have
not yet occurred.
--At program termination, all data written into files shall be identi-
cal to one of the possible results that execution of the program
according to the abstract semantics would have produced.
--The input and output dynamics of interactive devices shall take
place in such a fashion that prompting messages actually appear
prior to a program waiting for input. What constitutes an interac-
tive device is implementation-defined.
[Note: more stringent correspondences between abstract and actual
semantics may be defined by each implementation. ]
_________________________
functions as ``observable behavior'' as well.
7) Note that some aspects of sequencing in the abstract machine are
unspecified; the preceding restriction upon side effects applies to
that particular execution sequence in which the actual code is gener-
ated. Also note that when a call to a library I/O function returns,
the side effect is considered complete, even though some external ac-
tions implied by the call (such as the I/O itself) may not have com-
pleted yet.
8) In other words, function executions do not interleave with each
other.
12A full-expression is an expression that is not a subexpression of
another expression.
13[Note: certain contexts in C++ cause the evaluation of a full-expres-
sion that results from a syntactic construct other than expression
(_expr.comma_). For example, in _dcl.init_ one syntax for initializer
is
( expression-list )
but the resulting construct is a function call upon a constructor
function with expression-list as an argument list; such a function
call is a full-expression. For example, in _dcl.init_, another syntax
for initializer is
= initializer-clause
but again the resulting construct might be a function call upon a con-
structor function with one assignment-expression as an argument;
again, the function call is a full-expression. ]
14[Note: the evaluation of a full-expression can include the evaluation
of subexpressions that are not lexically part of the full-expression.
For example, subexpressions involved in evaluating default argument
expressions (_dcl.fct.default_) are considered to be created in the
expression that calls the function, not the expression that defines
the default argument. ]
15[Note: operators can be regrouped according to the usual mathematical
rules only where the operators really are associative or
commutative.9) For example, in the following fragment
int a, b;
/*...*/
a = a + 32760 + b + 5;
the expression statement behaves exactly the same as
a = (((a + 32760) + b) + 5);
due to the associativity and precedence of these operators. Thus, the
result of the sum (a + 32760) is next added to b, and that result is
then added to 5 which results in the value assigned to a. On a
machine in which overflows produce an exception and in which the range
of values representable by an int is [-32768,+32767], the implementa-
tion cannot rewrite this expression as
a = ((a + b) + 32765);
since if the values for a and b were, respectively, -32754 and -15,
the sum a + b would produce an exception while the original expression
would not; nor can the expression be rewritten either as
a = ((a + 32765) + b);
or
a = (a + (b + 32765));
since the values for a and b might have been, respectively, 4 and -8
or -17 and 12. However on a machine in which overflows do not produce
an exception and in which the results of overflows are reversible, the
above expression statement can be rewritten by the implementation in
any of the above ways because the same result will occur. ]
_________________________
9) Overloaded operators are never assumed to be associative or commu-
tative.
16There is a sequence point at the completion of evaluation of each
full-expression10).
17When calling a function (whether or not the function is inline), there
is a sequence point after the evaluation of all function arguments (if
any) which takes place before execution of any expressions or state-
ments in the function body. There is also a sequence point after the
copying of a returned value and before the execution of any expres-
sions outside the function11). Several contexts in C++ cause evalua-
tion of a function call, even though no corresponding function call
syntax appears in the translation unit. [Example: evaluation of a new
expression invokes one or more allocation and constructor functions;
see _expr.new_. For another example, invocation of a conversion func-
tion (_class.conv.fct_) can arise in contexts in which no function
call syntax appears. ] The sequence points at function-entry and
function-exit (as described above) are features of the function calls
as evaluated, whatever the syntax of the expression that calls the
function might be.
18In the evaluation of each of the expressions
a && b
a || b
a ? b : c
a , b
using the built-in meaning of the operators in these expressions
(_expr.log.and_, _expr.log.or_, _expr.cond_, _expr.comma_) there is a
sequence point after the evaluation of the first expression12).
_________________________
10) As specified in _class.temporary_, after the "end-of-full-expres-
sion" sequence point, a sequence of zero or more invocations of de-
structor functions for temporary objects takes place, usually in re-
verse order of the construction of each temporary object.
11) The sequence point at the function return is not explicitly speci-
fied in ISO C, and can be considered redundant with sequence points at
full-expressions, but the extra clarity is important in C++. In C++,
there are more ways in which a called function can terminate its exe-
cution, such as the throw of an exception.
12) The operators indicated in this paragraph are the built-in opera-
tors, as described in clause _expr_. When one of these operators is
overloaded (clause _over_) in a valid context, thus designating a us-
er-defined operator function, the expression designates a function in-
vocation, and the operands form an argument list, without an implied
sequence point between them.