______________________________________________________________________
1 General [intro]
______________________________________________________________________
1.1 Scope [intro.scope]
1 This International Standard specifies requirements for processors 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.
+------- BEGIN BOX 1 -------+
The draft uses the word ``implementation'' somewhat more frequently
than ``processor.'' We should either choose only one word, or define
that they are equivalent in meaning.
+------- END BOX 1 -------+
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, inline
functions, operator overloading, function name overloading, refer
ences, free store management operators, function argument checking and
type conversion, and additional library facilities. These extensions
to C are summarized in _diff.c_. The differences between C++ and ISO
C1) are summarized in _diff.iso_. The extensions to C++ since 1985
are summarized in _diff.c++_.
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 (_basic_),
types (_dcl.name_, _dcl.meaning_), templates (_temp_), classes
(_class_), functions (_dcl.fct_), and objects (_dcl.dcl_).
4 For classes and class templates, the library clauses specify partial
definitions. Private members (_class.access_) are not specified, but
each implementation shall supply them to complete the definitions
according to the description in the library clauses.
5 For functions, function templates, objects, and values, the library
clauses specifiy 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.namespace_). 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_). An 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, C Standard
--ISO/IEC 9899:1990/DAM 1, Amendment 1 to C Standard
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 Definitions [intro.defs]
1 For the purposes of this International Standard, the definitions given
in ISO/IEC 2382 and the following definitions apply.
--argument: An expression in the comma-separated list bounded by the
parentheses in a function call expression, a sequence of preprocess
ing tokens in the comma-separated list bounded by the parentheses in
a function-like macro invocation, the operand of throw, or an
expression in the comma-separated list bounded by the angle brackets
in a template instantiation. Also known as an "actual argument" or
"actual parameter."
--diagnostic message: A message belonging to an implementation-defined
subset of the implementation's message output.
--dynamic type: The dynamic type of an expression is determined by its
current value and can change during the execution of a program. If
a pointer (_dcl.ptr_) whose static type is "pointer to class B" is
pointing to an object of class D, derived from B (_class.derived_),
_________________________
1) With the qualifications noted in clauses _lib.library_ through
_lib.input.output_, and in subclause _diff.library_, the Standard C
library is a subset of the Standard C++ library.
the dynamic type of the pointer is "pointer to D." References
(_dcl.ref_) are treated similarly.
--ill-formed program: input to a C++ processor that is not a well-
formed program (q. v.).
--implementation-defined behavior: Behavior, for a correct program
construct and correct data, that depends on the implementation and
that each implementation shall document. The range of possible
behaviors is delineated by the standard.
--implementation limits: Restrictions imposed upon programs by the
implementation.
--locale-specific behavior: Behavior that depends on local conventions
of nationality, culture, and language that each implementation shall
document.
--multibyte character: 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.
--parameter: an object or reference declared as part of a function
declaration or definition in the catch clause of an exception han
dler 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 defi
nition, or a template-parameter. A function can be said to "take
arguments" or to "have parameters." Parameters are also known as a
"formal arguments" or "formal parameters."
--signature: The signature of a function is the information about that
function that participates in overload resolution (_over.match_):
the types of its parameters and, if the function is a non-static
member of a class, the CV-qualifiers (if any) on the function itself
and whether the function is a direct member of its class or inher
ited from a base class. The signature of a template function spe
cialization includes the types of its template arguments
(_temp.over.link_).
--static type: The static type of an expression is the type
(_basic.types_) resulting from analysis of the program without con
sideration of execution semantics. It depends only on the form of
the program and does not change.
--undefined behavior: Behavior, such as might arise upon use of an
erroneous program construct or of erroneous data, for which the
standard imposes no requirements. Permissible undefined behavior
ranges from ignoring the situation completely with unpredictable
_________________________
2) Function signatures do not include return type, because that does
not participate in overload resolution.
results, to behaving during translation or program execution in a
documented manner characteristic of the environment (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 not engender undefined behav
ior; they are required to be diagnosed.
--unspecified behavior: Behavior, for a correct program construct and
correct data, that depends on the implementation. The implementa
tion is not required to document which behavior occurs. [Note: usu
ally, the range of possible behaviors is delineated by the standard.
--end note]
--well-formed program: a C++ program constructed according to the syn
tax rules, diagnosable semantic rules, and the One Definition Rule
(_basic.def_).
2 Clause _lib.definitions_ defines additional terms that are used only
in the library clauses (_lib.library_-_lib.input.output_).
1.4 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.5 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 accessible to a C++ program is one or
more contiguous sequences of bytes. Every byte has a unique
address.3)
2 [Note: the representation of types is described in _basic.types_. ]
1.6 The C++ object model [intro.object]
1 The constructs in a C++ program create, refer to, access, and manipu
late objects. An object is a region of storage and, except for bit-
fields (_class.bit_), occupies one or more contiguous bytes of stor
age. 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 (_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. The
object's type determines the number of bytes that the object occupies
and the interpretation of its content. Some objects are polymorphic
(_class.virtual_); the implementation generates information carried in
each such object that makes it possible to determine that object's
type during program execution. For other objects, the meaning of the
values found therein is determined by the type of the expressions
(_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_) or a base class sub-object
(_class.derived_). An object that is not a sub-object of any other
object is called a complete object. 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.
3 C++ provides a variety of built-in types and several ways of composing
new types from existing types.
4 Certain types have implementation-defined alignment restrictions. An
object of one of those types shall appear only at an address that is
compatible with its alignment restriction.
_________________________
3) An implementation is free to disregard this requirement as long as
doing so has no perceptible effect on the execution of the program.
Thus, for example, an implementations is free to place any variable in
an internal register that does not have an address as long as the pro
gram does not do anything that depends on the address of the variable.
1.7 Processor compliance [intro.compliance]
1 Every conforming C++ processor 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-formed
program that contains a violation of any diagnosable semantic rule or
of any syntax rule, except as noted herein.
2 If an ill-formed program contains no diagnosable errors. diagnosable
errors, this International Standard places no requirement on proces
sors with respect to that program.
3 The set of "diagnosable semantic rules" consists of all semantic rules
in this International Standard except for those rules containing an
explicit notation that "no diagnostic is required."
4 Two kinds of implementations are defined: hosted and freestanding.
For a hosted implementation, this standard defines the set of avail
able libraries. A freestanding implementation is one in which execu
tion 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_).
5 In this International Standard, the examples, the notes, the foot
notes, 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 "]".
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 proces
sors. In particular, they need not copy or emulate the structure of
the abstract machine. Rather, conforming processors are required to
emulate (only) the observable behavior of the abstract machine as
explained below.
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, which documenta
tion defines 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). In each case 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).
5 A conforming processor 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 processor executing that program with
that input (not even with regard to operations previous to 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.4)
7 Accessing an object designated by a volatile lvalue, modifying an
object, modifying a file, 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.5)
8 Once the execution of a function begins, no expressions from the call
ing function are evaluated until execution of the called function is
completed.6)
9 In the abstract machine, all expressions are evaluated as specified by
the semantics. An actual implementation need not evaluate part of an
expression if it can deduce that its value is not used and that no
needed side effects are produced (including any caused by calling a
function or accessing a volatile object).
10When the processing of the abstract machine is interrupted by receipt
of a signal, only the values of objects as of the previous sequence
point may be relied on. Objects that may be modified between the pre
vious sequence point and the next sequence point need not have
received their correct values yet.
_________________________
4) 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.
5) 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.
6) In other words, function executions do not interleave with each
other.
11An instance of each object with automatic storage duration is associ
ated 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).
12The 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.
--More stringent correspondences between abstract and actual semantics
may be defined by each implementation.
13Define a full-expression as 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 construct other than expres
sion (_expr.comma_). [Example: in _dcl.init_ one syntax for initial
izer 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 another 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. ] ]
15[Note: that the evaluation of a full-expression can include the evalu
ation of subexpressions that are not lexically part of the full-
expression. [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. ] ]
16There is a sequence point at the completion of evaluation of each
full-expression7).
_________________________
7) As specified in _class.temporary_, after the "end-of-full-
expression" sequence point, a sequence of zero or more invocations of
destructor functions takes place, in reverse order of the construction
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 function8). 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 builtin 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 expression9).
+------- BEGIN BOX 2 -------+
The contexts above all correspond to sequence points already specified
in ISO C, although they can arise in new syntactic contexts. The
Working Group is still discussing whether there is a sequence point
after the operand of dynamic-cast is evaluated; this is a context from
which an exception might be thrown, even though no function call is
performed. This has not yet been voted upon by the Working Group, and
it may be redundant with the sequence point at function-exit.
+------- END BOX 2 -------+
_________________________
of each temporary object.
8) 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, as discussed below.
9) The operators indicated in this paragraph are the builtin opera
tors, as described in Clause _expr_. When one of these operators is
overloaded (_over_) in a valid context, thus designating a user-
defined operator function, the expression designates a function invo
cation, and the operands form an argument list, without an implied se
quence point between them.