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

  --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++ processor 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 subclause _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  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.  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.

  --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, except for bit-
  fields (_class.bit_), occupies one or more contiguous bytes  of  stor­
  age.  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 possible to determine that object's
  type during program execution.  For other objects, the meaning 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_) 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.

4 Certain types have implementation-defined alignment restrictions.   An
  object  of  one of those types shall appear only at an address that is
  compatible with its alignment restriction.

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

2 If an ill-formed program contains no diagnosable errors.   diagnosable
  errors,   this   International   Standard  places  no  requirement  on
  gram does not do anything that depends on the address of the variable.

  processors with respect to that program.

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 standard defines the set of avail­
  able libraries.  A freestanding implementation is one in which  execu­
  tion  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 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 "]".

  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  proces­
  sors.   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 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,  which  documenta­
  tion  defines the instance of the abstract machine that corresponds to
  that implementation (referred to  as  the  ``corresponding  instance''

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).  In each case 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

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 International Standard
  places no requirement on the processor  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,  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 evaluations shall be
  complete and no side effects  of  subsequent  evaluations  shall  have
  taken place.5)

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 is associ­
  ated with each entry into  its  block.   Such  an  object  exists  and
  retains  its  last-stored  value during the execution of the block and
  while the block is suspended (by a call of a function or receipt of  a

12The least requirements on a conforming implementation are:

  --At  sequence  points,  volatile objects are stable in the sense that
  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­
  6) In other words, function executions do  not  interleave  with  each

    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.

13Define  a full-expression as 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_).  [Example: in _dcl.init_ one syntax for  initial­
  izer 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.  [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.  ] ]

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

17When calling a function (whether or not the function is inline), there
  is a sequence point after the evaluation of all function arguments (if
  any)  which  takes place before execution of any expressions or state­
  ments in the function body.  There is also a sequence point after  the
  copying  of  a  returned value and before the execution of any expres­
  sions  outside  the  function8).   Several  contexts  in   C++   cause
  7)  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.
  8) The sequence point at the function return is not explicitly  speci­

  evaluation  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 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 expression  that  calls
  the function might be.

18In the evaluation of each of the expressions
          a && b
          a || b
          a ? b : c
          a , b
  using  the  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 expression9).

  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, as discussed below.
  9)  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.