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

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/TR-1-82:1982,  American National Dictionary for Information
    Processing Systems.

  --ISO/IEC 9899:1990, C Standard

  --ISO/IEC xxxx:199x Amendment 1 to C Standard

  +-------                 BEGIN BOX 1                -------+
  This last title must be filled in when Amendment 1 is  approved.   The
  other titles have not been checked for accuracy.
  +-------                  END BOX 1                 -------+

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

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

    (_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
    behaviors is delineated by the standard.

  --implementation  limits:  Restrictions  imposed  upon programs by the

  --locale-specific behavior: Behavior that depends on local conventions
    of nationality, culture, and language that each implementation shall

  --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 ir 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 may said to take  argu­
    ments  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.
  2)  Function  signatures do not include return type, because that does
  not participate in overload resolution.

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

  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­

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

2 The  constructs in a C++ program create, refer to, access, and manipu­
  late objects in memory.  Each object (except bit-fields) occupies  one
  or   more  contiguous  bytes.   Objects  are  created  by  definitions
  (_basic.def_) and new-expressions (_expr.new_).  The  lifetime  of  an
  object  begins after any required initialization (_dcl.init_) has com­
  pleted.  For  objects  with  destructors,  it  ends  when  destruction
  starts.   Each object has a type determined by the construct that cre­
  ates it.  The type in turn determines the number  of  bytes  that  the
  object occupies and the interpretation of their contents.  Objects may

  contain    other    objects,    called    sub-objects    (_class.mem_,
  _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 may appear only at an address that is divisible by a  particular

  1.6  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 rule that  is  identi­
  fied  as diagnosable in this Standard or of any syntax rule, except as
  noted herein.

2 Well-formed C++ programs are those that are constructed  according  to
  the  syntax  rules,  semantic rules identified as diagnosable, and the
  One Definition Rule (_basic.def_).  If a program  is  not  well-formed
  but  does  not contain any diagnosable errors, this Standard places no
  requirement on processors with respect to that program.

  1.7  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

  may 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

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

6 The observable behavior of the abstract machine  is  its  sequence  of
  reads   and   writes  to  volatile  data  and  calls  to  library  I/O

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

9 Also  note  that  the  evaluation of a full-expression may 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
  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.
  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.

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 may

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

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

  5)  The sequence point at the function return is not explicitly speci­
  fied in ISO C, and may 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.