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.172:1990, American National Dictionary for Information Pro­
    cessing 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  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 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.

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

    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.

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

  --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.
  2) Function signatures do not include return type, because  that  does
  not participate in overload resolution.

  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.

  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  storageduration  which  influences  its lifetime (_basic.stc_).  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 exe­
  cution.  For other objects, the meaning 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.

4 Certain types have alignment restrictions.  An object of one of  those
  types  shall appear only at an address that is divisible by a particu­
  lar integer.

  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 error 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 Well-formed C++ programs are those that are constructed  according  to
  the  syntax  rules, diagnosable semantic rules, and the One Definition
  Rule (_basic.def_).  If a program is not well-formed but does not con­
  tain  any  diagnosable  errors, this Standard places no requirement on
  processors with respect to that program.

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

  1.8  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
  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 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 Accessing a volatile object, 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.4)

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

  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) 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­
  5)  In  other  words,  function executions do not interleave with each

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

14It 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_).  For example, 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.

15Also  note  that  the  evaluation of a full-expression can include the
  evaluation of subexpressions that are not lexically part of the  full-
  expression.    For  example,  subexpressions  involved  in  evaluating
  default argument expressions (_dcl.fct.default_) are considered to  be
  created  in the expression that calls the function, not the expression
  that defines the default argument.

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

18In 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 1                -------+
  The contexts above all correspond to sequence points already specified
  in  ISO  C,  although  they  can arise in new syntactic contexts.  The
  6)   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.
  7)  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, as discussed below.
  8)  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.

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