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

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

  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

  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.

  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-

  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

  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-

  --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

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
  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

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-

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

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
  ( 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);
  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-

16There is a sequence point at the  completion  of  evaluation  of  each

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.