      ______________________________________________________________________

      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.  These extensions to C are summarized in _diff.c_.
      The  differences  between  C++ and ISO C 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 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

    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 semantic rules" consists of all semantic rules
      in  this  International  Standard except for those rules containing an
      explicit notation that "no diagnostic is required."

    2 Every conforming C++ implementation 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.

    3 If an ill-formed program contains no violations of diagnosable  seman-
      tic rules, this International Standard places no requirement on imple-
      mentations with respect to that program.

    4 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_).

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

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

      --Whenever this International Standard places a  diagnosable  require-
        ment on the form of a program (that is, the characters, tokens, syn-
        tactic elements, and types that make up the program), and a  program
        does  not  meet  that requirement, the program is ill-formed and the
        implementation shall issue a diagnostic message when processing that
        program.

      --Whenever  this  International  Standard  places a requirement on the
        execution of a program (that is, the values of data that are used as
        part of program execution) and the data encountered during execution
        do not meet that requirement, the behavior of the program  is  unde-
        fined  and this International Standard places no requirements at all
        on the behavior of the program.

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

    7 A  conforming implementation may have extensions (including additional
      library functions), provided they do not alter  the  behavior  of  any
      well-formed  program.   One  example  of such an extension is allowing
      identifiers to contain characters outside the basic  source  character
      set.   Implementations are required to diagnose programs 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.

      --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, type-id or template-name  in  the  comma-separated  list
        bounded  by  the  angle  brackets in a template instantiation.  Also
        known as an "actual argument" or "actual parameter."

      --diagnostic message: A message belonging to an implementation-defined
        subset of the implementation's output messages.

      --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  (_class.derived_), the dynamic type of the expression *p is
        "D."  References (_dcl.ref_) are treated similarly.  ]  The  dynamic
        type of an rvalue expression is its static type.

      --ill-formed  program:  input  to  a  C++ implementation that is not a

        well-formed program (q. v.).

      --implementation-defined behavior: Behavior, for a well-formed program
        construct  and  correct data, that depends on the implementation and
        that each implementation shall document.

      --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 (_lex.charset_).

      --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 parenthe-
        ses 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."

      --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 class  member,
        the  cv- qualifiers (if any) on the function itself and the class in
        which the member function is declared.2) The signature of a template
        function specialization 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 while the program is executing.

      --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.  Undefined behavior  may  also  be
        expected  when  the  standard  omits the description of any explicit
        definition  of  behavior.   [Note:  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
      _________________________
      2) Function signatures do not include return type, because  that  does
      not participate in overload resolution.

        behavior; they are required to be diagnosed.  ]

      --unspecified  behavior: Behavior, for a well-formed program construct
        and correct data, that depends on the implementation.  The implemen-
        tation  is  not  required to document which behavior occurs.  [Note:
        usually, the range of possible behaviors is delineated by the  Stan-
        dard.  ]

      --well-formed program: a C++ program constructed according to the syn-
        tax rules, diagnosable semantic rules, and the One  Definition  Rule
        (_basic.def.odr_).

    2 Clause  _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.  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.   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 (_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
      (_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.

      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.

    4 Unless it is a bit-field (_class.bit_), a most  derived  object  shall
      have  a  non-zero  size and shall occupy one or more bytes of storage.
      Base class sub-objects may have zero size.   An  object  of  POD  type
      (_basic.types_) shall occupy contiguous bytes of storage.

    5 [Note:  C++  provides  a variety of built-in types and several ways of
      composing new types from existing types (_basic.types_).  ]

      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.3)
      _________________________
      3) This provision is sometimes called the "as-if" rule, because an im-

    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.4)

    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.5)
      _________________________
      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.
      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.  Also note that when a call to a library I/O  function  returns,

    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.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,  the  values  of  objects  modified after the preceding
      sequence point are indeterminate during the execution  of  the  signal
      handler, and the value of any object not of volatile sig_atomic_t that
      is modified by the handler becomes undefined.

    11An  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).

    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.

      [Note:  more  stringent  correspondences  between  abstract and actual
      semantics may be defined by each implementation.  ]

    13A full-expression is an expression that  is  not  a  subexpression  of
      another expression.

    14[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
      _________________________
      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.
      6)  In  other  words,  function executions do not interleave with each
      other.

              ( 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.  ]

    15[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.  ]

    16[Note: operators can be regrouped according to the usual  mathematical
      rules   only   where   the   operators   really   are  associative  or
      commutative.7) 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.  ]

    17There is a sequence point at the  completion  of  evaluation  of  each
      full-expression8).
      _________________________
      7) Overloaded operators are never assumed to be associative or  commu-
      tative.
      8)  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.

    18When 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 function9).  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.

    19In 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 expression10).

      _________________________
      9)  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.
      10) The operators indicated in this paragraph are the built-in  opera-
      tors,  as  described in Clause _expr_.  When one of these operators is
      overloaded (_over_) in a valid context, thus  designating  a  user-de-
      fined  operator function, the expression designates a function invoca-
      tion, and the operands form an argument list, without an  implied  se-
      quence point between them.