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, inline
  functions, operator overloading,  function  name  overloading,  refer­
  ences, free store management operators, function argument checking and
  type conversion, and additional library facilities.  These  extensions
  to  C are summarized in _diff.c_.  The differences between C++ and ISO
  C1) are summarized in _diff.iso_.  The extensions to  C++  since  1985
  are summarized in _diff.c++_.

3 Clauses _lib.library_ through _lib.input.output_ (the library clauses)
  describe the Standard C++ library, which provides definitions for  the
  following kinds of entities: macros (_cpp.replace_), values (_basic_),
  types  (_dcl.name_,  _dcl.meaning_),   templates   (_temp_),   classes
  (_class_), functions (_dcl.fct_), and objects (_dcl.dcl_).

4 For  classes  and class templates, the library clauses specify partial
  definitions.  Private members (_class.access_) are not specified,  but
  each  implementation  shall  supply  them  to complete the definitions
  according to the description in the library clauses.

5 For functions, function templates, objects, and  values,  the  library
  clauses  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.namespace_).   A  C++  translation unit (_lex.phases_) obtains
  access to these names by including the  appropriate  standard  library
  header (_cpp.include_).

7 The  templates,  classes,  functions,  and objects in the library have
  external linkage (_basic.link_).  An implementation  provides  defini­
  tions  for  standard  library  entities, as necessary, while combining
  translation units to form a complete C++ program (_lex.phases_).

  1.2  Normative references                                 [intro.refs]

1 The following standards contain provisions which, through reference in
  this  text,  constitute provisions of this International Standard.  At
  the time of publication, the editions indicated were valid.  All stan­
  dards are subject to revision, and parties to agreements based on this
  International Standard are encouraged to investigate  the  possibility
  of applying the most recent editions of the standards indicated below.
  Members of IEC and ISO maintain registers of currently valid  Interna­
  tional Standards.

  --ISO/IEC 2382 Dictionary for Information Processing Systems.

  --ISO/IEC 9899:1990, C Standard

  --ISO/IEC 9899:1990/DAM 1, Amendment 1 to C Standard

2 The  library  described  in Clause 7 of the C Standard and Clause 7 of
  Amendment 1 to the C Standard is hereinafter  called  the  Standard  C

  1.3  Definitions                                          [intro.defs]

1 For the purposes of this International Standard, the definitions given
  in ISO/IEC 2382 and the following definitions apply.

  --argument: An expression in the comma-separated list bounded  by  the
    parentheses in a function call expression, a sequence of preprocess­
    ing tokens in the comma-separated list bounded by the parentheses in
    a  function-like  macro  invocation,  the  operand  of  throw, or an
    expression in the comma-separated list bounded by the angle brackets
    in  a template instantiation.  Also known as an "actual argument" or
    "actual parameter."

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

  --dynamic type: The dynamic type of an expression is determined by its
    current value and can change during the execution of a program.   If
    a  pointer  (_dcl.ptr_) whose static type is "pointer to class B" is
    pointing to an object of class D, derived from B  (_class.derived_),
    the  dynamic  type  of  the  pointer  is "pointer to D."  References
    (_dcl.ref_) are treated similarly.

  --ill-formed program: input to a C++  implementation  that  is  not  a
    well-formed program (q. v.).

  --implementation-defined  behavior:  Behavior,  for  a correct program
  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.

    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 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
    "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.2) The signature of a template function spe­
    cialization  includes  the   types   of   its   template   arguments

  --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.   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  implementa­
    tion is not required to document which behavior occurs.  [Note: usu­
    ally, the range of possible behaviors is delineated by the standard.
     --end note]

  --well-formed program: a C++ program constructed according to the syn­
    tax rules, diagnosable semantic rules, and the One  Definition  Rule

2 Clause  _lib.definitions_  defines additional terms that are used only
  in the library clauses (_lib.library_-_lib.input.output_).

  1.4  Syntax notation                                          [syntax]

1 In the syntax notation used in this International Standard,  syntactic
  categories are indicated by italic type, and literal words and charac­
  ters in constant width type.   Alternatives  are  listed  on  separate
  lines  except  in a few cases where a long set of alternatives is pre­
  sented on one line, marked by the phrase "one of."  An optional termi­
  nal or nonterminal symbol is indicated by the subscript "opt," so
          { expressionopt }
  indicates an optional expression enclosed in braces.

2 Names for syntactic categories have generally been chosen according to
  the following rules:

  --X-name is a use of an identifier in a context  that  determines  its
    meaning (e.g.  class-name, typedef-name).

  --X-id is an identifier with no context-dependent meaning (e.g.  qual­

  --X-seq is one or more X's without intervening delimiters (e.g.   dec­
    laration-seq is a sequence of declarations).

  --X-list  is  one  or  more  X's separated by intervening commas (e.g.
    expression-list is a sequence of expressions separated by commas).

  1.5  The C++ memory model                               [intro.memory]

1 The fundamental storage unit in the C++ memory model is the  byte.   A
  byte  is at least large enough to contain any member of the basic exe­
  cution character set and is composed of a contiguous sequence of bits,
  the  number of which is implementation-defined.  The least significant
  bit is called the low-order bit; the most significant  bit  is  called
  the  high-order bit.  The memory accessible to a C++ program is one or
  more  contiguous  sequences  of  bytes.   Every  byte  has  a   unique
  3)  An implementation is free to disregard this requirement as long as
  doing so has no perceptible effect on the execution  of  the  program.
  Thus, for example, an implementations is free to place any variable in
  an internal register that does not have an address as long as the pro­

2 [Note: the representation of types is described in _basic.types_.  ]

  1.6  The C++ object model                               [intro.object]

1 The constructs in a C++ program create, refer to, access, and  manipu­
  late  objects.   An  object is a region of storage and, unless it is a
  bit-field (_class.bit_), or is part of another object and has  a  vir­
  tual base class (_class.mi_), occupies one or more contiguous bytes 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 influ­
  ences   its   lifetime   (_basic.life_).    An   object   has  a  type
  (_basic.types_).  The term object type refers to the type  with  which
  the  object  is  created.   The object's type determines the number of
  bytes that the object occupies and the interpretation of its  content.
  Some  objects  are  polymorphic  (_class.virtual_); the implementation
  generates information carried in each such object that makes it possi­
  ble  to  determine  that  object's type during program execution.  For
  other objects, the interpretation  of  the  values  found  therein  is
  determined  by  the  type  of  the expressions (_expr_) used to access

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 (_basic.types_).

  1.7  Processor compliance                           [intro.compliance]

1 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, except as noted in this International Standard.

2 If an ill-formed program contains no diagnosable errors, this Interna­
  tional  Standard places no requirement on implementations with respect
  to that program.

  gram does not do anything that depends on the address of the variable.

3 The set of "diagnosable semantic rules" consists of all semantic rules
  in  this  International  Standard except for those rules containing an
  explicit notation that "no diagnostic is required."

4 Two kinds of implementations are  defined:  hosted  and  freestanding.
  For  a  hosted implementation, this 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:

  --Whenever this International Standard places  a  requirement  on  the
    form  of  a program (that is, the characters, tokens, syntactic ele­
    ments, and types that make up the program), and a program  does  not
    meet  that requirement, the program is ill-formed and an implementa­
    tion 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, the examples,  the  notes,  the  foot­
  notes,  and  the  non-normative  annexes are not part of the normative
  Standard.  Each example is introduced by "[Example:" and terminated by
  "]".  Each note is introduced by "[Note:" and terminated by "]".

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

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.

  +-------                 BEGIN BOX 1                -------+
  Change:  This  used to say ``In each case.''  It seems unwise to claim
  that the standard does something impossible.
  +-------                  END BOX 1                 -------+

  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

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

7 Accessing  an  object  designated by a volatile lvalue (_basic.lval_),
  modifying an object, modifying a file, or calling a function that does
  any of those operations are all side effects, which are changes in the
  state of the execution environment.  Evaluation of an expression might
  produce  side  effects.   At certain specified points in the execution
  sequence called sequence points, all side effects of previous  evalua­
  tions  shall be complete and no side effects of subsequent evaluations
  shall have taken place.5)
  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

8 Once the execution of a function begins, no expressions from the call­
  ing function are evaluated until execution of the called  function  is

9 In the abstract machine, all expressions are evaluated as specified by
  the  semantics.  An actual implementation need not evaluate part of an
  expression if it can deduce that its value is not  used  and  that  no
  needed  side  effects  are produced (including any caused by calling a
  function or accessing a volatile object).

10When the processing of the abstract machine is interrupted by  receipt
  of  a  signal,  only the values of objects as of the previous sequence
  point may be relied on.  Objects that may be modified between the pre­
  vious  sequence  point  and  the  next  sequence  point  need not have
  received their correct values yet.

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.

  --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-
  expression that results from a syntactic construct other than  expres­
  sion  (_expr.comma_).   For  example,  in  _dcl.init_  one  syntax for
  unspecified;  the  preceding  restriction upon side effects applies to
  that particular execution sequence in which the actual code is  gener­
  6)  In  other  words,  function executions do not interleave with each

  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 might be a function call upon a con­
  structor function  with  one  assignment-expression  as  an  argument;
  again, the function call is a full-expression.  ]

15[Note: that the evaluation of a full-expression can include the evalu­
  ation of subexpressions that are  not  lexically  part  of  the  full-
  expression.    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);
          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
  7) Overloaded operators are never assumed to be associative or  commu­
  8)   As   specified  in  _class.temporary_,  after  the  "end-of-full-
  expression" sequence point, a sequence of zero or more invocations  of
  destructor functions for temporary objects takes place, in reverse or­

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 builtin  meaning  of  the  operators  in  these  expressions
  (_expr.log.and_,  _expr.log.or_, _expr.cond_, _expr.comma_) there is a
  sequence point after the evaluation of the first expression10).

  +-------                 BEGIN BOX 2                -------+
  The  Working  Group  is  still  discussing whether there is a sequence
  point after the operand of dynamic-cast is evaluated; this is  a  con­
  text  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-
  +-------                  END BOX 2                 -------+

  der of the construction of each temporary object.
  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  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.