______________________________________________________________________
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 Standard also defines C++. Other
requirements and relaxations of the first requirement appear at vari
ous 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 (_intro.refs_). In addi
tion to the facilities provided by C, C++ provides additional data
types, classes, templates, exceptions, inline functions, operator
overloading, function name overloading, references, free store manage
ment 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.
--ANSI X3.172:1990, American National Dictionary for Information Pro
cessing 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 4 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 ANSI X3/TR-1-82 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_),
the dynamic type of the pointer is pointer to D. References
(_dcl.ref_) are treated similarly.
--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
_________________________
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.
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.
--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
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 range of pos
sible behaviors is delineated by the standard. The implementation
is not required to document which behavior occurs.
_________________________
2) Function signatures do not include return type, because that does
not participate in overload resolution.
Subclause _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 manual, 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 sym
bol 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. Each byte (except perhaps regis
ters) has a unique address.
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 storageduration which influences its lifetime (_basic.stc_). 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 exe
cution. 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 alignment restrictions. An object of one of those
types shall appear only at an address that is divisible by a particu
lar integer.
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 error 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 Well-formed C++ programs are those that are constructed according to
the syntax rules, diagnosable semantic rules, and the One Definition
Rule (_basic.def_). If a program is not well-formed but does not con
tain any diagnosable errors, this Standard places no requirement on
processors with respect to that program.
3 The set of diagnosable semantic rules consists of all semantic rules
in this Standard except for those rules containing an explicit nota
tion that no diagnostic is required.
1.8 Program execution [intro.execution]
1 The semantic descriptions in this Standard define a parameterized non
deterministic abstract machine. This Standard places no requirement
on the structure of conforming processors. 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 Standard as implementation defined (for example, sizeof(int)).
These constitute the parameters of the abstract machine. Each imple
mentation shall include documentation describing its characteristics
and behavior in these respects, which documentation defines the
instance of the abstract machine that corresponds to that implementa
tion (referred to as the ``corresponding instance'' below).
3 Certain other aspects and operations of the abstract machine are
described in this Standard as unspecified (for example, order of eval
uation of arguments to a function). In each case the 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).
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 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.3)
7 Define a full-expression as an expression that is not a subexpression
of another expression.
8 It is important to note that certain contexts in C++ cause the evalua
tion 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
( 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 is a function-call upon a construc
tor function with one assignment-expression as an argument; again, the
function-call is a full-expression.
_________________________
3) 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.
9 Also note that 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.
10There is a sequence point at the completion of evaluation of each
full-expression4).
11When 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 function5). Several contexts in C++ cause evalua
tion of a function call, even though no corresponding function-call
syntax appears in the translation unit. For example, evaluation of a
new expression invokes one or more allocation and constructor func
tions; see _expr.new_. For another example, invocation of a conver
sion 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 translation unit might
be.
12In the evaluation of each of the expressions
a && b
a || b
a ? b : c
a , b
there is a sequence point after the evaluation of the first
expression6).
+------- BEGIN BOX 1 -------+
The contexts above all correspond to sequence points already specified
_________________________
4) 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
of each temporary object.
5) 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.
6) 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.
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 1 -------+