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

  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 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, 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 "]".

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 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
    "pointer to 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

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

  --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  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 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.   --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.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
  3) An implementation is free to disregard this, or any other, require­
  ment as long as doing so has no perceptible effect on the execution of
  the  program.   Thus,  for example, an implementation is free to place
  any variable in an internal register that does not have an address  as

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, refer to, access, and  manipu­
  late 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.  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.  If a complete object, a  nonstatic
    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.

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

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

  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
  long  as  the program does not do anything that depends on the address
  of the variable.

  implementations.  In particular, they need not  copy  or  emulate  the
  structure 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.  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 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 has

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.

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

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

  +-------                 BEGIN BOX 1                -------+
  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 1                 -------+

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