______________________________________________________________________

  3   Basic concepts                                   [basic]

  ______________________________________________________________________

1 [Note: this clause presents the basic concepts of  the  C++  language.
  It  explains  the difference between an object and a name and how they
  relate to the notion of an lvalue.  It introduces the  concepts  of  a
  declaration and a definition and presents C++'s notion of type, scope,
  linkage, and storage duration.  The mechanisms for starting and termi­
  nating  a  program  are  discussed.  Finally, this clause presents the
  fundamental types of the language and lists the ways  of  constructing
  compound types from these.

2 This  clause does not cover concepts that affect only a single part of
  the language.  Such concepts are discussed in the relevant clauses.
  --end note]

3 An  entity  is a value, object, subobject, base class subobject, array
  element, variable, function, set of functions, instance of a function,
  enumerator, type, class member, template, or namespace.

4 A  name  is a use of an identifier (_lex.name_) that denotes an entity
  or label (_stmt.goto_, _stmt.label_).

  +-------                 BEGIN BOX 1                -------+
  We need to specifically define ``variable''.  The preceding  sentences
  say  that it is an ``entity'' that has a name.  Probably a variable is
  ``a declared object that has a name''.
  +-------                  END BOX 1                 -------+

5 Every name that denotes an entity  is  introduced  by  a  declaration.
  Every  name that denotes a label is introduced either by a goto state­
  ment (_stmt.goto_) or a labeled-statement (_stmt.label_).

6 Some names denote types, classes, enumerations, or templates.  In gen­
  eral,  it  is necessary to determine whether or not a name denotes one
  of these entities before parsing the program that  contains  it.   The
  process that determines this is called name lookup (_basic.lookup_).

7 Two names are the same if

  --they are identifiers composed of the same character sequence; or

  --they  are the names of overloaded operator functions formed with the
    same operator; or

  --they are the names of user-defined conversion functions formed  with
    the same type.

8 An  identifier  used in more than one translation unit can potentially
  refer to the same entity in these translation units depending  on  the
  linkage (_basic.link_) specified in the translation units.

  3.1  Declarations and definitions                          [basic.def]

1 A  declaration (_dcl.dcl_) introduces one or more names into a program
  and gives each name a meaning.

2 A declaration is a definition unless it declares  a  function  without
  specifying the function's body (_dcl.fct.def_), it contains the extern
  specifier (_dcl.stc_) and neither an initializer nor a  function-body,
  it   declares   a   static   data   member   in  a  class  declaration
  (_class.static_), it is a class name declaration (_class.name_), or it
  is   a   typedef   declaration   (_dcl.typedef_),   a  using  declara­
  tion(_namespace.udecl_), or a using directive(_namespace.udir_).

3 [Example: all but one of the following are definitions:
          int a;                       // defines a
          extern const int c = 1;      // defines c
          int f(int x) { return x+a; } // defines f
          struct S { int a; int b; };  // defines S
          struct X {                   // defines X
              int x;                   // defines nonstatic data member x
              static int y;            // declares static data member y
              X(): x(0) { }            // defines a constructor of X
          };
          int X::y = 1;                // defines X::y
          enum { up, down };           // defines up and down
          namespace N { int d; }       // defines N and N::d
          namespace N1 = N;            // defines N1
          X anX;                       // defines anX
  whereas these are just declarations:
          extern int a;                // declares a
          extern const int c;          // declares c
          int f(int);                  // declares f
          struct S;                    // declares S
          typedef int Int;             // declares Int
          extern X anotherX;           // declares anotherX
          using N::d;                  // declares N::d
   --end example]

4 [Note: in some circumstances, C++  implementations  implicitly  define
  the    default    constructor    (_class.ctor_),    copy   constructor
  (_class.copy_),  assignment  operator  (_class.copy_),  or  destructor
  (_class.dtor_) member functions.  [Example: given

          struct C {
              string s;    // string is the standard library class (_lib.string_)
          };

          int main()
          {
              C a;
              C b = a;
              b = a;
          }
  the  implementation will implicitly define functions to make the defi­
  nition of C equivalent to
          struct C {
              string s;
              C(): s() { }
              C(const C& x): s(x.s) { }
              C& operator=(const C& x) { s = x.s; return *this; }
              ~C() { }
          };
   --end example]  --end note]

5 [Note: a class name can also be implicitly declared by an  elaborated-
  type-specifier (_basic.scope.pdecl_).  ]

  3.2  One definition rule                               [basic.def.odr]

1 No  translation  unit  shall  contain  more than one definition of any
  variable, function, class type, enumeration type or template.

2 A function is used if it is called, its address is taken, it  is  used
  to  form  a pointer to member, or it is a virtual member function that
  is not pure (_class.abstract_).  Every program shall contain at  least
  one  definition  of every function that is used in that program.  That
  definition can appear explicitly in the program, it can  be  found  in
  the  standard  or  a user-defined library, or (when appropriate) it is
  implicitly defined (see _class.ctor_, _class.dtor_ and  _class.copy_).
  If  a  non-virtual  function  is not defined, a diagnostic is required
  only if an attempt is actually made to call that function.  If a  vir­
  tual function is not defined and it is neither called nor used to form
  a pointer to member, no diagnostic is required.

  +-------                 BEGIN BOX 2                -------+
  This  says  nothing  about  user-defined   libraries.    Probably   it
  shouldn't,  but  perhaps it should be more explicit that it isn't dis­
  cussing it.
  +-------                  END BOX 2                 -------+

3 A non-local variable with static storage duration shall  have  exactly
  one  definition  in a program unless the variable either has a builtin
  type or is an aggregate and unless it is either unused or used only as
  the operand of the sizeof operator.

  +-------                 BEGIN BOX 3                -------+
  This is still uncertain.
  +-------                  END BOX 3                 -------+

4 Exactly one definition of a class is required in a translation unit if
  the class is used other than in the formation of a pointer  or  refer­
  ence type.

  +-------                 BEGIN BOX 4                -------+
  This  is not quite right, because it is possible to declare a function
  that has an undefined class type as its return type,  that  has  argu­
  ments of undefined class type.
  +-------                  END BOX 4                 -------+

  +-------                 BEGIN BOX 5                -------+
  There  might  be  other  situations  that do not require a class to be
  defined: extern declarations (i.e.  "extern  X  x;"),  declaration  of
  static members, others???
  +-------                  END BOX 5                 -------+

5 [Example: the following complete translation unit is well-formed, even
  though it never defines X:
          struct X;      // declare X as a struct type
          struct X* x1;  // use X in pointer formation
          X* x2;         // use X in pointer formation
   --end example]

6 There can be more than one definition of a class type (_class_),  enu­
  meration  type  (_dcl.enum_),  inline  function  with external linkage
  (_dcl.fct.spec_), class template (_temp_),  non-static  function  tem­
  plate   (_temp.fct_),   static   data   member  of  a  class  template
  (_temp.static_), member function template (_temp.mem.func_),  or  tem­
  plate specialization for which some template parameters are not speci­
  fied (_temp.spec_, _temp.class.spec_) in a program provided that  each
  definition  appears  in a different translation unit, and provided the
  definitions satisfy the following requirements.  Given such an  entity
  named D defined in more than one translation unit, then

  --each  definition  of D shall consist of the same sequence of tokens;
    and

  --in each definition of D, corresponding names, looked up according to
    _basic.lookup_,  shall refer to an entity defined within the defini­
    tion of D, or shall refer to the same entity, after overload resolu­
    tion  (_over.match_) and after matching of partial template special­
    ization (_temp.over_), except that a  name  can  refer  to  a  const
    object  with internal or no linkage if the object has the same inte­
    gral or enumeration type in all definitions of D, and the object  is
    initialized with a constant expression (_expr.const_), and the value
    (but not the address) of the object is used, and the object has  the

    same value in all definitions of D; and

  --in  each  definition of D, the overloaded operators referred to, the
    implicit calls to conversion operators, constructors,  operator  new
    functions  and  operator  delete  functions, shall refer to the same
    function, or to a function defined within the definition of D; and

  --in each definition of D, a default argument used by an (implicit  or
    explicit)  function  call  is  treated as if its token sequence were
    present in the definition of D; that is,  the  default  argument  is
    subject  to  three requirements described above (and, if the default
    argument has sub-expressions with default arguments,  this  require­
    ment applies recursively).1)

  --if  D  is  a   class   with   an   implicitly-declared   constructor
    (_class.ctor_),  it  is as if the constructor was implicitly defined
    in every translation unit where it is used, and the implicit defini­
    tion in every translation unit shall call the same constructor for a
    base class or a class member of D.  [Example:
              // translation unit 1:
              struct X {
                      X(int);
                      X(int, int);
              };
              X::X(int = 0) { }
              class D: public X { };
              D d2; // X(int) called by D()

              // translation unit 2:
              struct X {
                      X(int);
                      X(int, int);
              };
              X::X(int = 0, int = 0) { } // X(int, int) called by D();
                                         // D()'s implicit definition
                                         // violates the ODR
     --end example] If D is a template, and is defined in more than  one
    translation  unit,  then  the  last  four requirements from the list
    above shall apply to names from the template's enclosing scope  used
    in  the  template  definition  (_temp.encl_),  and also to dependent
    names at the point of instantiation (_temp.dep_).   If  the  defini­
    tions  of  D  satisfy all these requirements, then the program shall
    behave as if there were a single definition of D.   If  the  defini­
    tions  of  D do not satisfy these requirements, then the behavior is
    undefined.

  _________________________
  1)  _dcl.fct.default_  describes how default argument names are looked
  up.

  3.3  Declarative regions and scopes                      [basic.scope]

1 Every name is introduced in some contiguous portion  of  program  text
  called  a declarative region, which is the largest part of the program
  in which that name can possibly be valid.  In general, each particular
  name  is valid only within some possibly discontiguous portion of pro­
  gram text called its scope.  To determine the scope of a  declaration,
  it is sometimes convenient to refer to the potential scope of a decla­
  ration.  The scope of a declaration is the same as its potential scope
  unless  the  potential  scope contains another declaration of the same
  name.  In that case, the potential scope of  the  declaration  in  the
  inner (contained) declarative region is excluded from the scope of the
  declaration in the outer (containing) declarative region.

2 [Example: in
          int j = 24;
          int main()
          {
                  int i = j, j;
                  j = 42;
          }
  the identifier j is declared twice as a name (and  used  twice).   The
  declarative  region  of  the first j includes the entire example.  The
  potential scope of the first j begins immediately  after  that  j  and
  extends to the end of the program, but its (actual) scope excludes the
  text between the , and the }.  The declarative region  of  the  second
  declaration of j (the j immediately before the semicolon) includes all
  the text between { and }, but its potential scope excludes the  decla­
  ration  of i.  The scope of the second declaration of j is the same as
  its potential scope.  ]

3 [Note: The name look up rules are summarized in _basic.lookup_.  ]

  3.3.1  Point of declaration                        [basic.scope.pdecl]

1 The point of declaration for a name is immediately after its  complete
  declarator (_dcl.decl_) and before its initializer (if any), except as
  noted below.  [Example:
      int x = 12;
      { int x = x; }
  Here the second x is initialized with its own (unspecified) value.  ]

2 A nonlocal name remains visible up to the point of declaration of  the
  local name that hides it.  [Example:
      const int  i = 2;
      { int  i[i]; }
  declares a local array of two integers.  ]

3 The  point  of  declaration for an enumerator is immediately after its
  enumerator-definition.  [Example:
          const int x = 12;
          { enum { x = x }; }
  Here, the enumerator x is initialized with the value of  the  constant

  x, namely 12.  ]

4 The  point  of declaration of a class first declared in an elaborated-
  type-specifier is as follows:

  --if the elaborated-type-specifier has the form:
              class-key identifier ;
    the elaborated-type-specifier declares the identifier to be a class-
    name in the scope that contains the declaration, otherwise

  --if the elaborated-type-specifier has the form
              class-key identifier ...
    the  identifier  is  declared  as  a class-name in the smallest non-
    class, non-function prototype scope that contains  the  declaration.
    [Note: this also applies to friend declarations of the form:
              friend class-key identifier ;
    where  the identifier refers to a class that has not been previously
    declared.  ]

  [Note: any other form of elaborated-type-specifier must  refer  to  an
  already declared class-name or enum-name; see _basic.lookup.elab_.  ]

5 A function declared as a friend and not previously declared, is intro­
  duced in the  smallest  enclosing  non-class,  non-function  prototype
  scope that contains the friend declaration.

6 [Note: For point of instantiation of a template, see _temp.inst_.  ]

  3.3.2  Local scope                                 [basic.scope.local]

1 A name declared in a block (_stmt.block_) is local to that block.  Its
  scope begins at its point  of  declaration  (_basic.scope.pdecl_)  and
  ends at the end of its declarative region.

2 A  function parameter name in a function definition (_dcl.fct.def_) is
  a local name in the scope of the outermost block of the  function  and
  shall not be redeclared in that scope.

3 The  name in a catch exception-declaration is local to the handler and
  shall not be redeclared in the outermost block of the handler.

4 Names declared in the for-init-statement, and in the condition of  if,
  while,  for, and switch statements are local to the if, while, for, or
  switch statement (including the controlled statement), and  shall  not
  be  redeclared  in a subsequent condition of that statement nor in the
  outermost block (or, for  the  if  statement,  any  of  the  outermost
  blocks) of the controlled statement; see _stmt.select_.

  3.3.3  Function prototype scope                    [basic.scope.proto]

1 In  a  function  declaration, or in any function declarator except the
  declarator of a function definition (_dcl.fct.def_), names of  parame­
  ters  (if supplied) have function prototype scope, which terminates at

  the end of the nearest enclosing function declarator.

  3.3.4  Function scope

1 Labels (_stmt.label_) can be used anywhere in the  function  in  which
  they are declared.  Only labels have function scope.

  3.3.5  Namespace scope                         [basic.scope.namespace]

1 The  declarative  region  of  a namespace-definition is its namespace-
  body.  The potential scope denoted by  an  original-namespace-name  is
  the  concatenation  of  the declarative regions established by each of
  the namespace-definitions in the same  declarative  region  with  that
  original-namespace-name.   Entities  declared  in a namespace-body are
  said to be members of the namespace, and  names  introduced  by  these
  declarations  into the declarative region of the namespace are said to
  be member names of the namespace.  A namespace member name has  names­
  pace  scope.   Its  potential  scope  includes  its namespace from the
  name's point of declaration (_basic.scope.pdecl_) onwards, as well  as
  the  potential  scope  of  any using directive (_namespace.udir_) that
  nominates its namespace.  [Example:
          namespace N {
                  int i;
                  int g(int a) { return a; }
                  int k();
                  void q();
          }
          namespace { int l=1; }
          // the potential scope of l is from its point of declaration
          // to the end of the translation unit
          namespace N {
                  int g(char a)         // overloads N::g(int)
                  {
                          return l+a;   // l is from unnamed namespace
                  }
                  int i;                // error: duplicate definition
                  int k();              // ok: duplicate function declaration
                  int k()               // ok: definition of N::k()
                  {
                          return g(i);  // calls N::g(int)
                  }
                  int q();              // error: different return type
          }
   --end example]

2 A namespace member can also be used  after  the  ::  scope  resolution
  operator  (_expr.prim_)  applied  to  the  name  of its namespace; see
  _namespace.qual_.

3 A  name   declared   outside   all   named   or   unnamed   namespaces
  (_basic.namespace_),  blocks  (_stmt.block_) and classes (_class_) has
  global namespace scope (also  called  global  scope).   The  potential
  scope   of   such   a   name   begins  at  its  point  of  declaration

  (_basic.scope.pdecl_) and ends at the end of the translation unit that
  is  its  declarative  region.   Names declared in the global namespace
  scope are said to be global.

  3.3.6  Class scope                                 [basic.scope.class]

1 The following rules describe the scope of names declared in classes.

    1)The scope of a name declared in a class consists not only  of  the
      declarative  region  following  the name's declarator, but also of
      all function bodies,  default  arguments,  and  constructor  ctor-
      initializers  in  that  class  (including  such  things  in nested
      classes).

    2)A name N used in a class S shall refer  to  the  same  declaration
      when  re-evaluated in its context and in the completed scope of S.

    3)If reordering member declarations in a class yields  an  alternate
      valid  program  under  (1) and (2), the program's behavior is ill-
      formed, no diagnostic required.

    4)A declaration in a nested declarative region hides  a  declaration
      whose declarative region contains the nested declarative region.

    5)A  declaration  within a member function hides a declaration whose
      scope extends to or past the end of the member function's class.

    6)The scope of a declaration that extends to or past the  end  of  a
      class definition also extends to the regions defined by its member
      definitions, even if defined lexically  outside  the  class  (this
      includes  static data member definitions, nested class definitions
      and  member  function  definitions  (that   is,   the   parameter-
      declaration-clause        including        default       arguments
      (_dcl.fct.default_), the member function body and, for constructor
      functions        (_class.ctor_),        the       ctor-initializer
      (_class.base.init_)).  [Example:
                  typedef int  c;
                  enum { i = 1 };
                  class X {
                      char  v[i];  // error: 'i' refers to ::i
                                   // but when reevaluated is X::i
                      int  f() { return sizeof(c); }  // okay: X::c
                      char  c;
                      enum { i = 2 };
                  };
                  typedef char*  T;
                  struct Y {
                      T  a;    // error: 'T' refers to ::T
                               // but when reevaluated is Y::T
                      typedef long  T;
                      T  b;
                  };

                  struct Z {
                      int  f(const R);  // error: 'R' is parameter name
                                        // but swapping the two declarations
                                        // changes it to a type
                      typedef int  R;
                  };
       --end example]

2 The name of a class member shall only be used as follows:

  --in the scope of its class (as described above) or  a  class  derived
    (_class.derived_) from its class,

  --after  the  .  operator  applied to an expression of the type of its
    class (_expr.ref_) or a class derived from its class,

  --after the -> operator applied to a pointer to an object of its class
    (_expr.ref_) or a class derived from its class,

  --after  the :: scope resolution operator (_expr.prim_) applied to the
    name of its class or a class derived from its class,

  --or after a using declaration (_namespace.udecl_).

3 [Note: The  scope  of  names  introduced  by  friend  declarations  is
  described in _basic.scope.pdecl_.  ]

  3.3.7  Name hiding                                [basic.scope.hiding]

1 A name can be hidden by an explicit declaration of that same name in a
  nested declarative region or derived class (_class.member.lookup_).

2 A class name (_class.name_) or enumeration name  (_dcl.enum_)  can  be
  hidden  by  the name of an object, function, or enumerator declared in
  the same scope.  If a class or enumeration name and an  object,  func­
  tion, or enumerator are declared in the same scope (in any order) with
  the same name, the class or enumeration name is  hidden  wherever  the
  object, function, or enumerator name is visible.

3 In a member function definition, the declaration of a local name hides
  the declaration of a member of the  class  with  the  same  name;  see
  _basic.scope.class_.   The  declaration of a member in a derived class
  (_class.derived_) hides the declaration of a member of a base class of
  the same name; see _class.member.lookup_.

4 If a name is in scope and is not hidden it is said to be visible.

  3.4  Name look up                                       [basic.lookup]

1 The  name  look up rules apply uniformly to all names (including type­
  def-names  (_dcl.typedef_),  namespace-names  (_basic.namespace_)  and
  class-names  (_class.name_)) wherever the grammar allows such names in
  the context discussed by a particular rule.  Name look  up  associates

  the use of a name with a declaration (_basic.def_) of that name.  Name
  look up shall find  an  unambiguous  declaration  for  the  name  (see
  _class.member.lookup_).  Name look up may associate more than one dec­
  laration with a name if it finds the name to be a function  name;  the
  declarations   are   said  to  form  a  set  of  overloaded  functions
  (_over.load_).  Overload resolution (_over.match_) takes  place  after
  name  look  up  has  succeeded.  The access rules (_class.access_) are
  considered only once name look up and function overload resolution (if
  applicable)  have  succeeded.  Only after name look up, function over­
  load resolution (if applicable) and access checking have succeeded are
  the  attributes  introduced  by the name's declaration used further in
  expression processing (_expr_).

2 _basic.link_ discusses linkage issues.  The notions of scope, point of
  declaration and name hiding are discussed in _basic.scope_.

  3.4.1  Unqualified name look up                  [basic.lookup.unqual]

1 In all the cases listed in this subclause, the scopes are searched for
  a declaration in the order listed in each of the respective  category;
  name  look up ends as soon as a declaration is found for the name.  If
  no declaration is found, the program is ill-formed.

2 The declarations from the namespace  nominated  by  a  using-directive
  become  visible  in  a  namespace  enclosing  the using-directive; see
  _namespace.udir_.  For the purpose of the  unqualified  name  look  up
  rules described in this subclause, the declarations from the namespace
  nominated by the using-directive are considered members of the enclos­
  ing namespace.

3 A  name  used in global scope, outside of any function, class or user-
  declared namespace, shall be declared before its used in global scope.

4 A  name  used  in  a  named namespace outside of the definition of any
  function or class shall be declared before its use in  that  namespace
  or before its use in a namespace enclosing its namespace.

5 A name used in the definition of a function that is a member of names­
  pace N (where, only for the purpose of exposition, N  could  represent
  the  global  scope)  shall  be declared before its use in the block in
  which it is used or in one of its enclosing blocks (_stmt.block_)  or,
  shall  be  declared before its use in namespace N or, if N is a nested
  namespace, shall be declared before its use in one  of  N's  enclosing
  named  namespaces,  or shall be declared before its use in a namespace
  enclosing the definition of the function using the name.  [Example:

          namespace A {
                  namespace N {
                          void f();
                  }
          }
          void A::N::f() {
                  i = 5;
                  // The following scopes are searched for a declaration of i:
                  // 1) function scope of A::N::f, before the use of i
                  // 2) scope of namespace N
                  // 3) scope of namespace A
                  // 4) global scope, before the definition of A::N::f
          }
   --end example]

6 A name used in the definition of a class X outside of any inline  mem­
  ber  function  or  nested class definition shall be declared in one of
  the following ways:

  --before its use in class X or be a  member  of  a  base  class  of  X
    (_class.member.lookup_), or

  --if X is a nested class of class Y (_class.nest_), before the defini­
    tion of class X in Y, or shall be a member of  a  base  class  of  Y
    (this look up applies recursively for all of Y's enclosing classes),
    or

  --if X is a local class  (_class.local_),  before  the  definition  of
    class X in a block enclosing the definition of class X, or

  --if X is a member of namespace N, before the definition of class X in
    namespace N or in one of N's enclosing named namespaces, or

  --before the definition of class X, in a namespace enclosing the defi­
    nition of class X.

  [Note:  _basic.scope.class_  further describes the restrictions on the
  use of names in a class definition.   _class.nest_  further  describes
  the  restrictions  on  the  use  of names in nested class definitions.
  _class.local_ further describes the restrictions on the use  of  names
  in local class definitions.  ] [Example:

          namespace M {
                  class B { };
          }
          namespace N {
                  class Y : public M::B {
                          class X {
                                  int a[i];
                          };
                  };
          }
          // The following scopes are searched for a declaration of i:
          // 1) scope of class N::Y::X, before the use of i
          // 2) scope of class N::Y, before the definition of N::Y::X
          // 3) scope of N::Y's base class M::B
          // 4) scope of namespace N, before the definition of N::Y
          // 5) global scope, before the definition of N
   --end example]

7 A  name used in a function that is a member function (_class.mfct_) of
  class X shall be declared in one of the following ways:

  --before its use in the block in which it is used or in  an  enclosing
    block (_stmt.block_), or

  --shall  be  a  member  of class X or be a member of a base class of X
    (_class.member.lookup_), or

  --if X is a nested class of class Y (_class.nest_), shall be a  member
    of  Y,  or  shall  be  a  member  of a base class of Y (this look up
    applies recursively for all of Y's enclosing classes), or

  --if X is a local class  (_class.local_),  before  the  definition  of
    class X in a block enclosing the definition of class X, or

  --if  X is a member of namespace N, before the member function defini­
    tion, in namespace N or in one of N's enclosing named namespaces, or

  --before  the member function definition, in a namespace enclosing the
    member function definition.

  [Note: _class.mfct_ and _class.static_ further describe  the  restric­
  tions   on   the   use   of  names  in  member  function  definitions.
  _class.nest_ further describes the restrictions on the use of names in
  the  scope  of  nested  classes.   _class.local_ further describes the
  restrictions on the use of names in local class definitions.  ] [Exam­
  ple:

          class B { };
          namespace M {
                  namespace N {
                          class X : public B {
                                  void f();
                          };
                  }
          }
          void M::N::X::f() {
                  i = 16;
          }
          // The following scopes are searched for a declaration of i:
          // 1) function scope of M::N::X::f, before the use of i
          // 2) scope of class M::N::X
          // 3) scope of M::N::X's base class B
          // 4) scope of namespace M::N
          // 5) scope of namespace M
          // 5) global scope, before the definition of M::N::X::f
   --end example]

8 Name  look  up  for a name used in the definition of a friend function
  (_class.friend_) defined inline in the class granting friendship shall
  proceed  as  described for look up in member function definitions.  If
  the friend function is not defined in the class  granting  friendship,
  name  look  up  in  the  friend  function  definition shall proceed as
  described for look up in namespace member function definitions.

9 A name used in a function parameter-declaration-clause  as  a  default
  argument  (_dcl.fct.default_)  or  used  in  the  expression of a mem-
  initializer (_class.base.init_) is looked up as if the name were  used
  in the outermost block of the function definition.  In particular, the
  function parameter names are visible for name look up in default argu­
  ments  and  in  mem-initializers.   [Note:  _dcl.fct.default_  further
  describes the restrictions on the use of names in  default  arguments.
  _class.base.init_  further  describes  the  restrictions on the use of
  names in a ctor-initializer.  ]

10A name  used  in  the  definition  of  a  static  member  of  class  X
  (_class.static.data_) (after the qualified-id of the static member) is
  looked up as if the name was used in a member function of  X.   [Note:
  _class.static.data_  further  describes the restrictions on the use of
  names in the definition of a static data member.  ]

  +-------                 BEGIN BOX 6                -------+
  This subclause should probably say something about  name  look  up  in
  template definitions.
  +-------                  END BOX 6                 -------+

  3.4.2  Qualified name look up                      [basic.lookup.qual]

1 The  name  of a class or namespace member can be referred to after the
  :: scope resolution operator (_expr.prim_) applied to  a  nested-name-
  specifier  that  nominates its class or namespace.  During the look up
  for a name preceeding the :: scope  resolution  operator,  only  class
  names  and  namespace  names are considered.  A class-name hidden by a
  name that is not a type name or  namespace-name  is  still  found  and
  used.   The  class-name shall have been previously declared by a class
  declaration (_class_).  A namespace-name hidden by a name that is  not
  a  type  name  is still found and used.  The namespace-name shall have
  been previously defined either by a  named-namespace-definition  or  a
  namespace-alias-definition (_namespace.def_).  [Example:
          class A {
          public:
                  static int n;
          };
          int main()
          {
                  int A;
                  A::n = 42;          // OK
                  A b;                // ill-formed: A does not name a type
          }
   --end example]

2 [Note: Multiply qualified names, such as N1::N2::N3::n, can be used to
  refer to members of nested classes (_class.nest_) or members of nested
  namespaces.  ]

3 In  a  declaration in which the declarator-id is a qualified-id, names
  used before the qualified-id being  declared  are  looked  up  in  the
  defining  namespace scope; names following the qualified-id are looked
  up in the scope of the member's class or namespace.  [Example:
          class X { };
          class C {
                  class X { };
                  const int number = 50;
                  static X arr[number];
          };
          X C::arr number ; // equivalent to:  X  C::arr[C::number];
                            // not to:  C::X  C::arr[C::number];
   --end example]

4 A name prefixed by the unary scope operator :: (_expr.prim_) is looked
  up in global scope.  The use of :: allows a global name to be referred
  to even if its identifier has been hidden (_basic.scope.hiding_).  The
  name  shall be of global namespace scope or shall be a name whose dec­
  laration is visible in global scope because of a using directive  (see
  _namespace.udir_).

  3.4.2.1  Class members                                    [class.qual]

1 If  the nested-name-specifier of a qualified-id nominates a class, the
  name specified after the nested-name-specifier is  looked  up  in  the
  scope  of  the class.  The name shall represent a member of that class
  or a member of one of  its  base  classes  (_class.derived_).   [Note:
  _class.member.lookup_  describes  how  name  look up proceeds in class
  scope.  ]

2 A class member name hidden by a name in a nested declarative region or
  by  the name of a derived class member can still be found if qualified
  by the name of its class followed by the :: operator.

  3.4.2.2  Namespace members                            [namespace.qual]

1 If the nested-name-specifier of a qualified-id nominates a  namespace,
  the name specified after the nested-name-specifier is looked up in the
  scope of the namespace.

2 Given X::m, where X is a namespace, if m is declared  directly  in  X,
  let  S be the set of all such declarations of m.  Else if there are no
  using-directives in X, S is the empty set.  Else let S be the union of
  all  sets  of  declarations of m found in the namespaces designated by
  the using-directives in X.  If m is declared directly in these  names­
  paces,  let S be the set of all such declarations of m.  Else if these
  namespaces do not contain any using-directives, S is  the  empty  set.
  Else,  this search is applied recursively to the namespaces designated
  by the using-directives in these namespaces.  No namespace is searched
  more  than  once  in  the lookup of a name.  If S is the empty set the
  program is ill-formed, otherwise S is the required set of declarations
  of  m.   If  S has exactly one member then X::m refers to that member.
  Otherwise if the use of m is not one that allows a unique  declaration
  to  be  chosen  from  S, the program is ill-formed.  [Note: the choice
  could be made by  overload  resolution  (_over.match_)  or  resolution
  between class names and non-class names (_class.name_).  For example:
          int x;
          namespace Y {
                  void f(float);
                  void h(int);
          }
          namespace Z {
                  void h(float);
          }
          namespace A {
                  using namespace Y;
                  void f(int);
                  void g(int);
                  int i;
          }

          namespace B {
                  using namespace Z;
                  void f(char);
                  int i;
          }
          namespace AB {
                  using namespace A;
                  using namespace B;
                  void g();
          }
          void h()
          {
                  AB::g();     // g is declared directly in AB,
                               // therefore S is { AB::g() } and AB::g() is chosen
                  AB::f(1);    // f is not declared directly in AB so the rules are
                               // applied recursively to A and B;
                               // namespace Y is not searched and Y::f(float)
                               // is not considered;
                               // S is { A::f(int), B::f(char) } and overload
                               // resolution chooses A::f(int)
                  AB::f('c');  // as above but resolution chooses B::f(char)

                  AB::x++;     // x is not declared directly in AB, and
                               // is not declared in A or B, so the rules are
                               // applied recursively to Y and Z,
                               // S is { } so the program is ill-formed
                  AB::i++;     // i is not declared directly in AB so the rules are
                               // applied recursively to A and B,
                               // S is { A::i, B::i } so the use is ambiguous
                               // and the program is ill-formed
                  AB::h(16.8); // h is not declared directly in AB and
                               // not declared directly in A or B so the rules are
                               // applied recursively to Y and Z,
                               // S is { Y::h(int), Z::h(float) } and overload
                               // resolution chooses Z::h(float)
          }

3 The same declaration found more than once is not an ambiguity (because
  it is still a unique declaration). For example:
          namespace A {
                  int a;
          }
          namespace B {
                  using namespace A;
          }
          namespace C {
                  using namespace A;
          }
          namespace BC {
                  using namespace B;
                  using namespace C;
          }

          void f()
          {
                  BC::a++;  // ok: S is { A::a, A::a }
          }
          namespace D {
                  using A::a;
          }
          namespace BD {
                  using namespace B;
                  using namespace D;
          }
          void g()
          {
                  BD::a++;  // ok: S is { A::a, A::a }
          }

4 Since each referenced namespace is searched at most once, the  follow­
  ing is well-defined:
          namespace B {
                  int b;
          }
          namespace A {
                  using namespace B;
                  int a;
          }
          namespace B {
                  using namespace A;
          }
          void f()
          {
                  A::a++;  // ok: a declared directly in A, S is { A::a }
                  B::a++;  // ok: both A and B searched (once), S is { A::a }
                  A::b++;  // ok: both A and B searched (once), S is { B::b }
                  B::b++;  // ok: b declared directly in B, S is { B::b }
          }
   --end note]

5 During  the  look up of a qualified namespace member name, if the look
  up finds more than one declaration of the member, and if one  declara­
  tion  introduces a class name or enumeration name and the other decla­
  rations either introduce the same object, the same enumerator or a set
  of functions, the non-type name hides the class or enumeration name if
  and only if the declarations are from the  same  namespace;  otherwise
  (the  declarations are from different namespaces), the program is ill-
  formed.  [Example:
          namespace A {
                  struct x { };
                  int x;
                  int y;
          }
          namespace B {
                  struct y {};
          }

          namespace C {
                  using namespace A;
                  using namespace B;
                  int i = C::x; // ok, A::x (of type 'int')
                  int j = C::y; // ambiguous, A::y or B::y
          }
   --end example]

  +-------                 BEGIN BOX 7                -------+
  Change: The paragraph above is the result of discussions from the core
  reflector; see core-6070.
  +-------                  END BOX 7                 -------+

6 In  a declaration for a namespace member in which the declarator-id is
  a qualified-id, given that the qualified-id for the  namespace  member
  has the form
          nested-name-specifier unqualified-id
  the  unqualified-id shall name a member of the namespace designated by
  the nested-name-specifier.  [Example:
          namespace A {
                  namespace B {
                          void f1(int);
                  }
                  using namespace B;
          }
          void A::f1(T){}  // ill-formed, f1 is not a member of A
   --end example] However, in such namespace  member  declarations,  the
  nested-name-specifier  may rely on using-directives to implicitly pro­
  vide the initial part of the nested-name-specifier.  [Example:
          namespace A {
                  namespace B {
                          void f1(int);
                  }
          }
          namespace C {
                  namespace D {
                          void f1(int);
                  }
          }
          using namespace A;
          using namespace C::D;
          void B::f1(int){}  // okay, defines A::B::f1(int)
          void f1(int){}  // okay, defines C::D::f1(int)
   --end example]

  +-------                 BEGIN BOX 8                -------+
  Change: The paragraph above is the result of discussions from the core
  reflector; see core-6107.
  +-------                  END BOX 8                 -------+

  3.4.3  Elaborated type specifiers                  [basic.lookup.elab]

1 An  elaborated-type-specifier  may  be  used  to refer to a previously
  declared class-name or enum-name even though the name has been  hidden
  by   an   intervening  object,  function,  or  enumerator  declaration
  (_basic.scope.hiding_).  The class-name or  enum-name  in  the  elabo­
  rated-type-specifier  may  either be a single identifer or be a quali­
  fied-id.

2 If the name in the elaborated-type-specifier is  a  single  identifer,
  and unless the elaborated-type-specifier has the following form:
          class-key identifier ;
  the  identifier  is  looked  up according to _basic.lookup.unqual_ but
  ignoring  any  objects,  functions  or  enumerators  that  have   been
  declared.   If this name look up finds a typedef_name, the elaborated-
  type-specifier is ill-formed.  If the elaborated-type-specifier refers
  to  an  enum-name and this look up does not find a previously declared
  enum-name, the elaborated-type-specifier is ill-formed.  If the elabo­
  rated-type-specifier refers to an class-name and this look up does not
  find a previously declared  class-name,  or  if  the  elaborated-type-
  specifier has the form:
          class-key identifier ;
  the  elaborated-type-specifier  is  a  declaration that introduces the
  class-name as described in _basic.scope.pdecl_.

3 If the elaborated-type-specifier is a qualified-id, the name is looked
  up  according its qualifications, as described in _basic.lookup.qual_,
  but ignoring any objects, functions  or  enumerators  that  have  been
  declared.   If this name look up finds a typedef_name, the elaborated-
  type-specifier is ill-formed.  If this name look up does  not  find  a
  previously  declared  class-name  or  enum-name,  the elaborated-type-
  specifier is ill-formed.  [Example:
          struct Node {
                  struct Node* Next;      // ok: Refers to Node at global scope
                  struct Data* Data;      // ok: Declares type Data
                                          // at global scope and member Data
          };
          struct Data {
                  struct Node* Node;      // ok: Refers to Node at global scope
                  friend struct ::Glob;   // error: Glob is not declared
                                          // cannot introduce a qualified type
                  friend struct Glob;     // ok: Declares Glob in global scope
                  /* ... */
          };
          struct Base {
                  struct Data;                    // ok: Declares nested Data
                  struct ::Data*     thatData;    // ok: Refers to ::Data
                  struct Base::Data* thisData;    // ok: Refers to nested Data
                  friend class ::Data;            // ok: global Data is a friend
                  friend class Data;              // ok: nested Data is a friend
                  struct Data { /* ... */ };      // Defines nested Data
                  struct Data;                    // ok: Redeclares nested Data
          };

          struct Data;            // ok: Redeclares Data at global scope
          struct ::Data;          // error: cannot introduce a qualified type
          struct Base::Data;      // error: cannot introduce a qualified type
          struct Base::Datum;     // error: Datum undefined
          struct Base::Data* pBase;       // ok: refers to nested Data
   --end example]

  3.4.4  Class member access                     [basic.lookup.classref]

1 A name specified after the . operator or -> operator of a class member
  access is looked up as specified in _expr.ref_.

  +-------                 BEGIN BOX 9                -------+
  This subclause needs work.  _expr.ref_ is not really clear in describ­
  ing how names after the . operator and -> operator are looked up.  See
  core issue 452a.
  +-------                  END BOX 9                 -------+

  3.5  Program and linkage                                  [basic.link]

1 A  program  consists  of  one or more translation units (_lex_) linked
  together.  A translation unit consists of a sequence of  declarations.
          translation unit:
                  declaration-seqopt

2 A  name  is said to have linkage when it might denote the same object,
  reference, function, type, template, namespace  or  value  as  a  name
  introduced by a declaration in another scope:

  --When  a  name  has  external  linkage,  the entity it denotes can be
    referred to by names from scopes of other translation units or  from
    other scopes of the same translation unit.

  --When  a  name  has  internal  linkage,  the entity it denotes can be
    referred to by names from other scopes of the same translation unit.

  --When a name has no linkage, the entity it denotes cannot be referred
    to by names from other scopes.

3 A name of namespace scope (_basic.scope.namespace_) has internal link­
  age if it is the name of

  --a  variable  that  is  explicitly  declared static or, is explicitly
    declared const and neither explicitly declared extern nor previously
    declared to have external linkage; or

  --a  function  that  is  explicitly  declared static or, is explicitly
    declared inline and neither explicitly declared  extern  nor  previ­
    ously declared to have external linkage; or

  --the name of a data member of an anonymous union.

4 A name of namespace scope has external linkage if it is the name of

  --a variable, unless it has internal linkage; or

  --a function, unless it has internal linkage; or

  --a  named  class  (_class_), or an unnamed class defined in a typedef
    declaration in which the class has the typedef name for linkage pur­
    poses (_dcl.typedef_); or

  --a  named enumeration (_dcl.enum_), or an unnamed enumeration defined
    in a typedef declaration in which the enumeration  has  the  typedef
    name for linkage purposes (_dcl.typedef_); or

  --an enumerator belonging to an enumeration with external linkage; or

  --a template (_temp_); or

  --a  namespace  (_basic.namespace_),  unless  it is declared within an
    unnamed namespace.

5 In addition, a name of class scope has external linkage if the name of
  the class has external linkage.

6 The  name of a function declared in a block scope has linkage.  If the
  block scope function declaration matches a prior  visible  declaration
  of  the  same  function, the function name receives the linkage of the
  previous declaration; otherwise, it receives  external  linkage.   The
  name  of  an  object  declared by a block scope extern declaration has
  linkage.  If the block scope declaration matches a prior visible  dec­
  laration  of  the  same object, the name introduced by the block scope
  declaration receives the linkage of the previous  declaration;  other­
  wise, it receives external linkage.  [Example:
          static void f();
          static int i = 0;
          void g() {
                  extern void f(); // internal linkage
                  int i; // 'i' has no linkage
                  {
                          extern void f(); // internal linkage
                          extern int i; // external linkage
                  }
          }
   --end example]

7 Names not covered by these rules have no linkage.  Moreover, except as
  noted, a name declared in a local scope (_basic.scope.local_)  has  no
  linkage.  A name with no linkage (notably, the name of a class or enu­
  meration declared in a local scope (_basic.scope.local_)) shall not be
  used to declare an entity with linkage.  If a declaration uses a type­
  def name, it is the linkage of the type  name  to  which  the  typedef
  refers that is considered.  [Example:

          void f()
          {
              struct A { int x; };       // no linkage
              extern A a;                // ill-formed
              typedef A B;
              extern B b;                // ill-formed
          }
   --end example] This implies that names with no linkage cannot be used
  as template arguments (_temp.arg_).

8 Two names that are the same (_basic_) and that are declared in differ­
  ent  scopes  shall  denote the same object, reference, function, type,
  enumerator, template or namespace if

  --both names have external linkage or else both  names  have  internal
    linkage and are declared in the same translation unit; and

  --both names refer to members of the same namespace or to members, not
    by inheritance, of the same class; and

  --when both names denote functions, the function types  are  identical
    for purposes of overloading; and

  --when   both   names   denote   function  templates,  the  signatures
    (_temp.over.link_) are the same.

9 After all adjustments of types (during which typedefs  (_dcl.typedef_)
  are  replaced by their definitions), the types specified by all decla­
  rations of a particular external name shall be identical, except  that
  declarations  for  an array object can specify array types that differ
  by the presence or absence of a major array bound  (_dcl.array_),  and
  declarations  for  functions  with the same name can specify different
  numbers and types of parameters (_dcl.fct_).  A violation of this rule
  on type identity does not require a diagnostic.

10[Note:  linkage  to non-C++ declarations can be achieved using a link­
  age-specification (_dcl.link_).  ]

  3.6  Start and termination                               [basic.start]

  3.6.1  Main function                                [basic.start.main]

1 A program shall contain a global function called main,  which  is  the
  designated start of the program.

  +-------                BEGIN BOX 10                -------+
  In  C,  a  freestanding environment does not require main; the program
  invocation method is implementation-defined.  Should C++?   [Yes,  C++
  should  require  main - because unlike in C, this C++ standard defines
  the semantics of program start and termination.  This was done so that
  freestanding  environments  can  get  the same level of definition for
  order of static constructors/destructors.  --Neal Gafter]
  +-------                 END BOX 10                 -------+

2 This function is not predefined by the implementation,  it  cannot  be
  overloaded,  and  its type is implementation-defined.  All implementa­
  tions shall allow both of the following definitions of main:
          int main() { /* ... */ }
  and
          int main(int argc, char* argv[]) { /* ... */ }
  In the latter form argc shall be the number of arguments passed to the
  program  from the environment in which the program is run.  If argc is
  nonzero  these  arguments  shall  be  supplied  in   argv[0]   through
  argv[argc-1]  as pointers to the initial characters of null-terminated
  multibyte strings (NTMBSs) and argv[0] shall be  the  pointer  to  the
  initial  character  of a NTMBS that represents the name used to invoke
  the program or "".  The value of argc shall be nonnegative.  The value
  of  argv[argc]  shall be 0.  [Note: It is recommended that any further
  (optional) parameters be added after argv.  ]

3 The function main() shall not be called from within  a  program.   The
  linkage  (_basic.link_)  of  main()  is  implementation-defined.   The
  address of main() shall not be taken and main() shall not be  declared
  inline or static.  The name main is not otherwise reserved.  [Example:
  member functions, classes, and enumerations can be called main, as can
  entities in other namespaces.  ]

4 Calling the function
          void exit(int);
  declared  in  <cstdlib> (_lib.support.start.term_) terminates the pro­
  gram without leaving the current block and  hence  without  destroying
  any objects with automatic storage duration (_class.dtor_).  The argu­
  ment value is returned to the program's environment as  the  value  of
  the program.

  +-------                BEGIN BOX 11                -------+
  Several  members  of  the  Core  editing  group question this.  Can we
  require that exit destroy  automatic-duration  objects?   Or  make  it
  implementation-defined  whether  the  unwinding  occurs?  If an imple­
  menter's market _wants_ exit to unwind, and the implementer  can  pro­
  vide  the  necessary stack-unwinding, why should the Standard prohibit
  it?  For an immediate ``get me out of  here'',  there  is  always  the
  abort  function.   The footnote in _lib.exit_ claims that an unwinding
  can be achieved by throwing an exception that is caught in  main,  but
  this  assumes and requires that no handlers for ...  intervene.  There
  appears to be no way of exiting via exception that  cannot  be  inter­
  cepted by such handlers.
  +-------                 END BOX 11                 -------+

5 A  return statement in main() has the effect of leaving the main func­
  tion (destroying any objects  with  automatic  storage  duration)  and
  calling  exit()  with  the  return  value as the argument.  If control
  reaches the end of main without encountering a return  statement,  the
  effect is that of executing
          return 0;

  3.6.2  Initialization of non-local objects          [basic.start.init]

1 The  initialization  of  nonlocal objects with static storage duration
  (_basic.stc_) defined in a translation unit is done before  the  first
  use  of any function or object defined in that translation unit.  Such
  initializations     (_dcl.init_,     _class.static_,     _class.ctor_,
  _class.expl.init_) can be done before the first statement of main() or
  deferred to any point in time before the first use of  a  function  or
  object defined in that translation unit.  The storage for objects with
  static storage duration is zero-initialized  (_dcl.init_)  before  any
  other  initialization  takes place.  Objects with static storage dura­
  tion initialized with constant expressions (_expr.const_) are initial­
  ized  before  any  dynamic  (that  is,  run-time) initialization takes
  place.  The order of initialization of nonlocal  objects  with  static
  storage  duration defined in the same translation unit is the order in
  which their definition appears in this translation unit.   No  further
  order  is  imposed  on  the  initialization  of objects from different
  translation units.  The initialization  of  local  static  objects  is
  described in _stmt.dcl_.

2 If  construction  or  destruction of a non-local static object ends in
  throwing an uncaught exception, the  result  is  to  call  terminate()
  (_lib.terminate_).

  3.6.3  Termination                                  [basic.start.term]

1 Destructors  (_class.dtor_)  for initialized static objects are called
  when   returning    from    main()    and    when    calling    exit()
  (_lib.support.start.term_).   Destruction is done in the reverse order
  of initialization.  The function atexit() from <cstdlib> can  be  used
  to  specify  a  function  to  be called at exit.  If atexit() is to be
  called, the implementation shall not destroy objects with static stor­
  age duration initialized before an atexit() call until after the func­
  tion specified in the atexit() call has been called.

2 Where a C++ implementation  coexists  with  a  C  implementation,  any
  actions  specified  by  the  C  implementation to take place after the
  atexit() functions have been called take place after  all  destructors
  have been called.

3 Calling the function
          void abort();
  declared   in  <cstdlib>  terminates  the  program  without  executing
  destructors for objects of automatic or static  storage  duration  and
  without calling the functions passed to atexit().

  3.7  Storage duration                                      [basic.stc]

1 Storage  duration is a property of an object that indicates the poten­
  tial time extent the storage in which the object resides  might  last.
  The storage duration is determined by the construct used to create the
  object and is one of the following:

  --static storage duration

  --automatic storage duration

  --dynamic storage duration

2 Static and automatic storage durations  are  associated  with  objects
  introduced  by  declarations (_basic.def_).  The dynamic storage dura­
  tion  is  associated  with   objects   created   with   operator   new
  (_expr.new_).

3 The  storage  class  specifiers static and auto are related to storage
  duration as described below.

4 References (_dcl.ref_) might or might not  require  storage;  however,
  the storage duration categories apply to references as well.

  3.7.1  Static storage duration                      [basic.stc.static]

1 All  non-local  objects have static storage duration.  The storage for
  these objects shall last for  the  duration  of  the  program.   These
  objects    are    initialized    and   destroyed   as   described   in
  _basic.start.init_ and _basic.start.term_.

2 If an object of  static  storage  duration  has  initialization  or  a
  destructor  with  side  effects, it shall not be eliminated even if it
  appears to be unused.

3 The keyword static can be used to declare a local variable with static
  storage  duration; for a description of initialization and destruction
  of local static variables, see _stmt.dcl_.

4 The keyword static applied to a class data member in a  class  defini­
  tion gives the data member static storage duration.

  3.7.2  Automatic storage duration                     [basic.stc.auto]

1 Local  objects  explicitly declared auto or register or not explicitly
  declared static or extern have automatic storage duration.  The  stor­
  age  for these objects lasts until the block in which they are created
  exits.

2 [Note: These  objects  are  initialized  and  destroyed  as  described
  _stmt.dcl_.  ]

3 If  a  named  automatic object has initialization or a destructor with
  side effects, it shall not be destroyed before the end of  its  block,
  nor shall it be eliminated as an optimization even if it appears to be
  unused.

  3.7.3  Dynamic storage duration                    [basic.stc.dynamic]

1 Objects  can  be  created   dynamically   during   program   execution
  (_intro.execution_), using new-expressions (_expr.new_), and destroyed
  using delete-expressions (_expr.delete_).  A C++  implementation  pro­
  vides  access  to,  and  management of, dynamic storage via the global
  allocation functions operator new and operator new[]  and  the  global
  deallocation functions operator delete and operator delete[].

2 These  functions are always implicitly declared.  The library provides
  default definitions for them (_lib.new.delete_).  A C++ program  shall
  provide  at  most  one  definition  of any of the functions ::operator
  new(size_t),  ::operator  new[](size_t),   ::operator   delete(void*),
  and/or  ::operator  delete[](void*).   Any  such  function definitions
  replace the default versions.  This replacement is  global  and  takes
  effect  upon program startup (_basic.start_).  Allocation and/or deal­
  location functions can also be declared  and  defined  for  any  class
  (_class.free_).

3 Any  allocation and/or deallocation functions defined in a C++ program
  shall conform to the semantics specified in this subclause.

  3.7.3.1  Allocation functions           [basic.stc.dynamic.allocation]

1 Allocation functions shall be class member functions or  global  func­
  tions; a program is ill-formed if allocation functions are declared in
  a namespace scope other than global scope or declared static in global
  scope.   They  can  be overloaded, but the return type shall always be
  void*  and  the  first  parameter  type   shall   always   be   size_t
  (_expr.sizeof_),  an  implementation-defined  integral type defined in
  the standard header  <cstddef>  (_lib.language.support_).   For  these
  functions, parameters other than the first can have associated default
  arguments (_dcl.fct.default_).

2 The function shall return the address of a block of available  storage
  at  least  as large as the requested size.  The order, contiguity, and
  initial value of storage allocated by successive calls to  an  alloca­
  tion  function  is  unspecified.   The  pointer  returned  is suitably
  aligned so that it can be assigned to a pointer of any type  and  then
  used to access such an object or an array of such objects in the stor­
  age allocated (until the storage is explicitly deallocated by  a  call
  to a corresponding deallocation function).  Each such allocation shall
  yield a pointer to storage (_intro.memory_) disjoint  from  any  other
  currently allocated storage.  The pointer returned points to the start
  (lowest byte address) of the allocated storage.  If the  size  of  the
  space requested is zero, the value returned shall be nonzero and shall
  not point to or within any other  currently  allocated  storage.   The
  results of dereferencing a pointer returned as a request for zero size
  are undefined.2)
  _________________________
  2) The intent is to have operator new() implementable by calling  mal­
  loc()  or calloc(), so the rules are substantially the same.  C++ dif­
  fers from C in requiring a zero request to return a non-null  pointer.

3 If  an allocation function is unable to obtain an appropriate block of
  storage, it can invoke  the currently installed  new_handler3)  and/or
  throw  an exception (_except_) of class bad_alloc (_lib.bad.alloc_) or
  a class derived from bad_alloc.

4 If the allocation function returns the  null  pointer  the  result  is
  implementation-defined.

  3.7.3.2  Deallocation functions       [basic.stc.dynamic.deallocation]

1 Deallocation functions shall be class member functions or global func­
  tions; a program is ill-formed if deallocation functions are  declared
  in  a  namespace  scope  other than global scope or declared static in
  global scope.

2 Each deallocation function shall return void and its  first  parameter
  shall  be  void*.   For  class member deallocation functions, a second
  parameter of type size_t may be added. If both versions  are  declared
  in  the  same  class, the one-parameter form is the usual deallocation
  function and the two-parameter  form  is  used  for  placement  delete
  (_expr.new_).  If the second version is declared but not the first, it
  is the usual deallocation function, not placement delete.

3 The value of the first parameter supplied to a  deallocation  function
  shall  be  zero,  or  refer  to storage allocated by the corresponding
  allocation function (even if that allocation function was called  with
  a  zero  argument).   If  the value of the first argument is zero, the
  call to the deallocation function has no effect.  If the value of  the
  first  argument refers to a pointer already deallocated, the effect is
  undefined.

4 A deallocation function can free the storage referenced by the pointer
  given  as  its  argument and renders the pointer invalid.  The storage
  can be made available for further allocation.  An invalid pointer con­
  tains an unusable value:  it cannot even be used in an expression.

5 If  the  argument  is  non-zero, the value of a pointer that refers to
  deallocated space is indeterminate.  The effect  of  dereferencing  an
  indeterminate pointer value is undefined.4)

  3.7.4  Duration of sub-objects                     [basic.stc.inherit]

1 The storage duration of member subobjects, base class  subobjects  and
  array elements is that of their complete object (_intro.object_).

  _________________________
  3) A program-supplied allocation function can obtain  the  address  of
  the  currently  installed  new_handler  (_lib.new.handler_)  using the
  set_new_handler() function (_lib.set.new.handler_).
  4)  On some architectures, it causes a system-generated runtime fault.

  3.8  Object Lifetime                                      [basic.life]

1 The  lifetime  of  an object is a runtime property of the object.  The
  lifetime of an object of type T begins when:

  --storage with the proper alignment and size for type T  is  obtained,
    and

  --if  T is a class type with a non-trivial constructor (_class.ctor_),
    the constructor call has completed.

  The lifetime of an object of type T ends when:

  --if T is a class type with a non-trivial  destructor  (_class.dtor_),
    the destructor call starts, or

  --the storage which the object occupies is reused or released.

2 [Note:  the  lifetime  of an array object or of an object of POD types
  (_basic.types_) starts as soon as storage with proper size and  align­
  ment  is  obtained,  and  its lifetime ends when the storage which the
  array or object occupies is  reused  or  released.   _class.base.init_
  describes the lifetime of base and member subobjects.  ]

3 The properties ascribed to objects throughout this International Stan­
  dard apply for a given object only during its lifetime.   In  particu­
  lar,  except  as  noted during object construction (_class.base.init_)
  and destruction (_class.cdtor_), before the  lifetime  of  the  object
  starts  and after its lifetime ends the value of the storage which the
  object occupies is indeterminate and, for an object of  non-POD  class
  type, referring to a non-static data member, calling a non-static mem­
  ber function or converting  the  object  to  a  base  class  subobject
  results in undefined behavior.

4 [Note:  the  behavior  of an object under construction and destruction
  might not be the same as the behavior of an object whose lifetime  has
  started  and  not ended.  _class.base.init_ and _class.cdtor_ describe
  the behavior of an object  during  the  construction  and  destruction
  phases.  ]

5 A  program  may  end the lifetime of any object by reusing the storage
  which the object occupies or by explicitly calling the destructor  for
  an  object  of  a  class  type  with a non-trivial destructor.  For an
  object of a class type with a non-trivial destructor, the  program  is
  not  required  to  call  the  destructor explicitly before the storage
  which the object occupies is reused or released; however, if there  is
  no   explicit  call  to  the  destructor  or  if  a  delete-expression
  (_expr.delete_) is not used to release the storage, the destructor  is
  not implicitly called and any program that depends on the side effects
  produced by the destructor has unspecified behavior.

6 After the lifetime of an object has ended and while the storage  which
  the  object  occupied still exists, any pointer to the original object

  can be used but only in limited ways.  Such a pointer still points  to
  valid  storage and using the pointer as a pointer to the storage where
  the object was located, as if the pointer were of type void*, is well-
  defined.   However,  using the pointer to refer to the original object
  is no longer valid.  In particular, such a pointer cannot be  derefer­
  enced; for a non-POD class type T, a pointer of type T* that points to
  the  original  object  cannot  be  the  operand   of   a   static_cast
  (_expr.static.cast_) (except when the conversion is to void* or char*)
  and cannot be the operand of a dynamic_cast (_expr.dynamic.cast_);  if
  T  is  a class with a non-trivial destructor, such a pointer cannot be
  used as the operand of a delete-expression.  [Example:
          struct B {
                  virtual void f();
                  void mutate();
                  virtual ~B();
          };

          struct D1 : B { void f(); };
          struct D2 : B { void f(); };
          void B::mutate() {
                  new (this) D2;  // reuses storage - ends the lifetime of '*this'
                  f();            // undefined behavior
                  ... = this;     // ok, 'this' points to valid memory
          }
          void g() {
                  void* p = malloc(sizeof(D1) + sizeof(D2));
                  B* pb = new (p) D1;
                  pb->mutate();
                  &pb;            // ok: pb points to valid memory
                  void* q = pb;   // ok: pb points to valid memory
                  pb->f();        // undefined behavior, lifetime of *pb has ended
          }
   --end example]

7 If, after the lifetime of an object has ended and  while  the  storage
  which the object occupied still exists, a new object is created at the
  storage location which the original object occupied,  a  pointer  that
  pointed  to  the  original  object will automatically refer to the new
  object and, once the lifetime of the new object has  started,  can  be
  used to manipulate the new object, if:

  --the storage for the new object exactly overlays the storage location
    which the original object occupied, and

  --the new object is of the same type as the original object  (ignoring
    the top-level cv-qualifiers), and

  --the  original  object  was  a  complete object of type T and the new
    object is a complete object of type T (that is, they  are  not  base
    class subobjects).  [Example:

              struct C {
                      int i;
                      void f();
                      const C& operator=( const C& );
              };
              const C& C::operator=( const C& other)
              {
                      if ( this != &other )
                      {
                              this->~C();          // lifetime of '*this' ends
                              new (this) C(other); // new object of type C created
                              f();                 // well-defined
                      }
                      return *this;
              }
              C c1;
              C c2;
              c1 = c2; // well-defined
              c1.f();  // well-defined; c1 refers to a new object of type C
     --end example]

8 If  a  program  ends  the  lifetime of an object of type T with static
  (_basic.stc.static_) or automatic (_basic.stc.auto_) storage  duration
  and if T has a non-trivial destructor,5) the program must ensure  that
  an  object  of  the  original type occupies that same storage location
  when the implicit destructor call takes place; otherwise the  behavior
  of the program is undefined.  This is true even if the block is exited
  with an exception.  [Example:
          struct B {
                  ~B();
          };
          void h() {
                  B b;
                  new (&b) T;
          } // undefined behavior at block exit
   --end example]

  +-------                BEGIN BOX 12                -------+
  const objects need special treatment. A possible solution  that  still
  needs work:

9 The  storage  which  a  const  object occupies may be write-protected.
  Creating a new object at the storage location  which  a  const  object
  occupies  or  at  the  storage  location  which a const object used to
  occupy before  its  lifetime  ended  results  in  undefined  behavior.
  [Example:

  _________________________
  5) that is, an object for which a destructor will be called implicitly
  -- either upon exit from the block for an object with automatic  stor­
  age  duration  or upon exit from the program for an object with static
  storage duration.

          struct B {
                  ~B();
          };
          void h() {
                  const B b;
                  b.~B();
                  new (&b) const B; // undefined behavior
          }
   --end example]
  +-------                 END BOX 12                 -------+

  3.9  Types                                               [basic.types]

1 This  clauses  imposes  requirements  on implementations regarding the
  representation of types.  There are two kinds  of  types:  fundamental
  types  and  compound  types.  Types describe objects (_intro.object_),
  references (_dcl.ref_), or functions (_dcl.fct_).

2 For any object type T, the underlying bytes  (_intro.memory_)  of  the
  object   can   be   copied   (using   the   memcpy   library  function
  (_lib.headers_)) into an array of char or unsigned  char.   This  copy
  operation  is  well-defined,  even if the object does not hold a valid
  value of type T.  Whether or not the value  of  the  object  is  later
  changed,  if  the  content  of  the  array of char or unsigned char is
  copied back into the object using the  memcpy  library  function,  the
  object shall subsequently hold its original value.  [Example:
          #define N sizeof(T)
          char buf[N];
          T obj;  // obj initialized to its original value
          memcpy(buf, &obj, N);
                  // between these two calls to memcpy,
                  // obj might be modified
          memcpy(&obj, buf, N);
                  // at this point, each subobject of obj of scalar type
                  // holds its original value
   --end example]

3 For  any  scalar  type  T,  if  two  pointers to T point to distinct T
  objects obj1 and obj2, if the value of obj1 is copied into obj2, using
  the  memcpy  library  function,  obj2 shall subsequently hold the same
  value as obj1.  [Example:
          T* t1p;
          T* t2p;
                  // provided that t2p points to an initialized object ...
          memcpy(t1p, t2p, sizeof(T));
                  // at this point, every subobject of scalar type in *t1p
                  // contains the same value as the corresponding subobject in
                  // *t2p
   --end example]

4 The object representation of an object of type T is the sequence of  N
  unsigned char objects taken up by the object of type T, where N equals
  sizeof(T).  The value representation of an object is the  sequence  of

  bits  in the object representation that hold the value of type T.  The
  bits of the value representation determine a value, which is one  dis­
  crete element of an implementation-defined set of values.6)

5 Object  types  have   alignment   requirements   (_basic.fundamental_,
  _basic.compound_).   The alignment of an object type is an implementa­
  tion-defined integer value representing a number of bytes;  an  object
  is  allocated  at  an address that meets the alignment requirements of
  its object type.

6 Arrays of unknown size and classes that have  been  declared  but  not
  defined are called incomplete types.7)  Also,  the  void  type  is  an
  incomplete  type  (and not an object type); it represents an empty set
  of values.  No objects shall be created to have incomplete type.   The
  term  incompletely-defined  object  type  is  a synonym for incomplete
  type; the term completely-defined object type is a  synonym  for  com­
  plete type.

7 A class type (such as "class X") might be incomplete at one point in a
  translation unit and complete later on; the type "class X" is the same
  type  at  both  points.  The declared type of an array might be incom­
  plete at one point in a translation unit and complete  later  on;  the
  array  types  at  those  two points ("array of unknown bound of T" and
  "array of N T") are different types.  However, the type of  a  pointer
  to  array  of unknown size, or of a type defined by a typedef declara­
  tion to be an array of unknown size, cannot be completed.  [Example:
          class X;             // X is an incomplete type
          extern X* xp;        // xp is a pointer to an incomplete type
          extern int arr[];    // the type of arr is incomplete
          typedef int UNKA[];  // UNKA is an incomplete type
          UNKA* arrp;          // arrp is a pointer to an incomplete type
          UNKA** arrpp;
          void foo()
          {
              xp++;             // ill-formed:  X is incomplete
              arrp++;           // ill-formed:  incomplete type
              arrpp++;          // okay: sizeof UNKA* is known
          }
          struct X { int i; };  // now X is a complete type
          int  arr[10];         // now the type of arr is complete
          X x;
          void bar()
          {
              xp = &x;          // okay; type is ``pointer to X''
              arrp = &arr;      // ill-formed: different types
              xp++;             // okay:  X is complete
              arrp++;           // ill-formed:  UNKA can't be completed
          }
  _________________________
  6)  The intent is that the memory model of C++ is compatible with that
  of ISO/IEC 9899 Programming Language C.
  7)  The  size  and  layout of an instance of an incomplete type is un­
  known.

   --end example]

8 [Note: Clause _expr_, _stmt.stmt_, _dcl.dcl_ and  _dcl.decl_  describe
  in which contexts incomplete types are prohibited.  ]

9 Arithmetic  and enumeration types (_basic.fundamental_), pointer types
  (_basic.compound_),  and  cv-qualified   versions   of   these   types
  (_basic.type.qualifier_)  are  scalar  types.  Scalar types, POD class
  types, POD union  types  (_class_),  arrays  of  such  types  and  cv-
  qualified  versions  of  these  types (_basic.type.qualifier_) are POD
  types.

10If two types T1 and T2 are the same type, then T1 and T2  are  layout-
  compatible types.  [Note: Layout-compatible enumerations are described
  in  _dcl.enum_.   Layout-compatible  POD-structs  and  POD-unions  are
  described in _class.mem_.  ]

  3.9.1  Fundamental types                           [basic.fundamental]

1 Objects  declared  as  characters char) shall be large enough to store
  any member of the implementation's basic character set.  If a  charac­
  ter  from this set is stored in a character object, its value shall be
  equivalent to the integer code of that character.  It  is  implementa­
  tion-defined  whether a char object can hold negative values.  Charac­
  ters can be explicitly  declared  unsigned  or  signed.   Plain  char,
  signed char,  and  unsigned char  are three distinct types.  A char, a
  signed char, and an unsigned char occupy the same  amount  of  storage
  and  have  the  same  alignment requirements (_basic.types_); that is,
  they have the same object representation.  For  character  types,  all
  bits of the object representation participate in the value representa­
  tion. For unsigned character types, all possible bit patterns  of  the
  value representation represent numbers. These requirements do not hold
  for other types.  In  any  particular  implementation,  a  plain  char
  object  can  take  on  either  the  same values as a signed char or an
  unsigned char; which one is implementation-defined.

2 An enumeration comprises a set of named integer constant values, which
  form  the  basis  for an integral subrange that includes those values.
  Each distinct enumeration constitutes  a  different  enumerated  type.
  Each constant has the type of its enumeration.

3 There  are  four  signed  integer  types:  "signed char", "short int",
  "int", and "long int."  In this list, each type provides at  least  as
  much storage as those preceding it in the list, but the implementation
  can otherwise make any of them equal in storage size.  Plain ints have
  the  natural  size  suggested  by  the  architecture  of the execution
  environment8)  ;  the  other signed integer types are provided to meet
  special needs.

  _________________________
  8) that is, large enough to contain any value in the range of  INT_MIN
  and INT_MAX, as defined in the header <climits>.

4 For each of the signed integer types,  there  exists  a  corresponding
  (but  different)  unsigned  integer  type:  "unsigned char", "unsigned
  short int", "unsigned int", and "unsigned long  int,"  each  of  which
  occupies  the  same  amount  of  storage  and  has  the same alignment
  requirements  (_basic.types_)  as  the  corresponding  signed  integer
  type9) ; that is, each signed integer type has the same object  repre­
  sentation  as  its  corresponding unsigned integer type.  The range of
  nonnegative values of a signed integer type is a subrange of the  cor­
  responding  unsigned integer type, and the value representation of the
  same value in each type shall be the same.

5 Unsigned integers, declared unsigned, shall obey the  laws  of  arith­
  metic modulo 2n where n is the number of bits in the representation of
  that particular size of integer.10)

6 Type wchar_t is a distinct type whose values  can  represent  distinct
  codes  for all members of the largest extended character set specified
  among the supported locales (_lib.locale_).  Type wchar_t  shall  have
  the same size, signedness, and alignment requirements (_intro.memory_)
  as one of the other integral types, called its underlying type.

7 Values  of type bool are either true or false.11) There are no signed,
  unsigned, short, or long bool types or values.   As  described  below,
  bool values behave as integral types.  Values of type bool participate
  in integral promotions (_conv.prom_).

8 Types bool, char, wchar_t, and the signed and unsigned  integer  types
  are collectively called integral types.12) A synonym for integral type
  is integer type.  The representations of integral types  shall  define
  values by use of  a pure binary numeration system.

  +-------                     BEGIN BOX 13                     -------+
  Does  this  mean  two's  complement?   Is  there a definition of "pure
  binary numeration system?"
  +-------                      END BOX 13                      -------+

  _________________________
  9)  See  _dcl.type.simple_  regarding the correspondence between types
  and the sequences of type-specifiers that designate them.
  10) This implies that unsigned arithmetic does not overflow because  a
  result  that  cannot  be represented by the resulting unsigned integer
  type is reduced modulo the number that is one greater than the largest
  value  that can be represented by the resulting unsigned integer type.
  11) Using a bool value in ways described by this  International  Stan­
  dard as ``undefined,'' such as by examining the value of an uninitial­
  ized automatic variable, might cause it to behave  as  if  is  neither
  true nor false.
  12)  Therefore,  enumerations  (_dcl.enum_) are not integral; however,
  enumerations can be promoted to int, unsigned int, long,  or  unsigned
  long, as specified in _conv.prom_.

9 There are three floating point types: float, double, and long  double.
  The  type double provides at least as much precision as float, and the
  type long double provides at least as much precision as  double.   The
  set  of  values  of the type float is a subset of the set of values of
  the type double; the set of values of the type double is a  subset  of
  the  set  of values of the type long double.  The value representation
  of floating-point is implementation-defined.   Integral  and  floating
  types  are  collectively  called arithmetic types.  Specializations of
  the  standard  template  numeric_limits  (_lib.support.limits_)  shall
  specify  the  largest and smallest values of each arithmetic types for
  an implementation.

10The void type has an empty set of values.  It is used  as  the  return
  type  for  functions that do not return a value.  The void type is not
  an object type and objects of type void shall  not  be  created.   Any
  expression can be explicitly converted to type void (_expr.cast_); the
  resulting expression shall be used only  as  an  expression  statement
  (_stmt.expr_),   as   the   left   operand   of   a  comma  expression
  (_expr.comma_), or as a second or third operand of ?: (_expr.cond_).

11[Note: Even if the implementation defines two or more basic  types  to
  have  the  same  value representation, they are nevertheless different
  types.  ]

  3.9.2  Compound types                                 [basic.compound]

1 Compound types can be constructed from the fundamental  types  in  the
  following ways:

  --arrays of objects of a given type, _dcl.array_;

  --functions,  which  have parameters of given types and return void or
    references or objects of a given type, _dcl.fct_;

  --pointers to void or objects or functions (including  static  members
    of classes) of a given type, _dcl.ptr_;

  --references to objects or functions of a given type, _dcl.ref_;

  --constants, which are values of a given type, _dcl.type_;

  --classes containing a sequence of objects of various types (_class_),
    a set of functions for manipulating  these  objects  (_class.mfct_),
    and  a  set of restrictions on the access to these objects and func­
    tions, _class.access_;

  --unions, which are classes capable of containing objects of different
    types at different times, _class.union_;

  --pointers to non-static13) class members, which identify members of a
  _________________________
  13)  Static  class  members  are objects or functions, and pointers to
  them are ordinary pointers to objects or functions.

    given type within objects of a given class, _dcl.mptr_.

2 These  methods  of  constructing  types  can  be  applied recursively;
  restrictions are mentioned in _dcl.ptr_, _dcl.array_,  _dcl.fct_,  and
  _dcl.ref_.

3 A  pointer  to  objects  of type T is referred to as a "pointer to T."
  [Example: a pointer to an  object  of  type  int  is  referred  to  as
  "pointer  to  int"  and  a pointer to an object of class X is called a
  "pointer to X."  ] Except for pointers to static members, text  refer­
  ring to "pointers" does not apply to pointers to members.  Pointers to
  incomplete types are allowed although there are restrictions  on  what
  can  be  done  with them (_basic.types_).  The value representation of
  pointer types is implementation-defined.  Pointers to cv-qualified and
  cv-unqualified  versions (_basic.type.qualifier_) of layout-compatible
  types shall have the same value representation and alignment  require­
  ments (_basic.types_).

4 Objects  of  cv-qualified  (_basic.type.qualifier_)  or cv-unqualified
  type void* (pointer to void), can be  used  to  point  to  objects  of
  unknown  type.   A  void* shall be able to hold any object pointer.  A
  cv-qualified or cv-unqualified  (_basic.type.qualifier_)  void*  shall
  have  the  same  representation  and  alignment  requirements as a cv-
  qualified or cv-unqualified char*.

5 Except for pointers to static members, text  referring  to  "pointers"
  does not apply to pointers to members.

  3.9.3  CV-qualifiers                            [basic.type.qualifier]

1 A  type mentioned in _basic.fundamental_ and _basic.compound_ is a cv-
  unqualified    type.     Each    cv-unqualified    fundamental    type
  (_basic.fundamental_) has three corresponding cv-qualified versions of
  its type: a const-qualified version, a volatile-qualified version, and
  a    const-volatile-qualified   version.    The   term   object   type
  (_intro.object_) includes the cv-qualifiers specified when the  object
  is created.  The presence of a const specifier in a decl-specifier-seq
  declares an object of const-qualified  object  type;  such  object  is
  called  a  const  object.   The  presence of a volatile specifier in a
  decl-specifier-seq declares an  object  of  volatile-qualified  object
  type;  such  object is called a volatile object.  The presence of both
  cv-qualifiers in a decl-specifier-seq declares  an  object  of  const-
  volatile-qualified object type; such object is called a const volatile
  object.  The cv-qualified or cv-unqualified versions  of  a  type  are
  distinct  types;  however, they shall have the same representation and
  alignment requirements (_basic.types_).14)

2 A compound type (_basic.compound_) is  not  cv-qualified  by  the  cv-
  qualifiers (if any) of the type from which it is compounded.  However,
  _________________________
  14) The same representation and alignment requirements  are  meant  to
  imply interchangeability as arguments to functions, return values from
  functions, and members of unions.

  any cv-qualifiers that appear in an array  declaration  apply  to  the
  array element type, not the array type (_dcl.array_).

3 Each non-function, non-static, non-mutable member of a const-qualified
  class object is const-qualified, each non-function, non-static  member
  of  a  volatile-qualified class object is volatile-qualified and simi­
  larly for  members  of  a  const-volatile  class.  See  _dcl.fct_  and
  _class.this_ regarding cv-qualified function types.

4 There  is a (partial) ordering on cv-qualifiers, so that a type can be
  said to be more cv-qualified than another.  Table 1  shows  the  rela­
  tions that constitute this ordering.

                 Table 1--relations on const and volatile

                               +----------+
                  no cv-qualifier   <     const
                 no cv-qualifier   <     volatile
              no cv-qualifier  |<     const volatile
                  const     <  |  const volatile
                  volatile  <  |  const volatile
                               +----------+

5 In  this  International Standard, the notation cv (or cv1, cv2, etc.),
  used in the description of types, represents an arbitrary set  of  cv-
  qualifiers,  i.e.,  one  of {const}, {volatile}, {const, volatile}, or
  the empty set.  Cv-qualifiers applied to an array type attach  to  the
  underlying  element  type, so the notation "cv T," where T is an array
  type, refers to an array whose elements are so-qualified.  Such  array
  types  can  be said to be more (or less) cv-qualified than other types
  based on the cv-qualification of the underlying element types.

  3.9.4  Type names                                    [basic.type.name]

1 [Note: Fundamental and compound types can be given names by the  type­
  def mechanism (_dcl.typedef_), and families of types and functions can
  be specified and named by the template mechanism (_temp_).  ]

  3.10  Lvalues and rvalues                                 [basic.lval]

1 Every expression is either an lvalue or an rvalue.

2 An lvalue refers to an object or function.  Some rvalue  expressions--
  those of class or cv-qualified class type--also refer to objects.15)

  _________________________
  15)  Expressions  such as invocations of constructors and of functions
  that return a class type refer to objects, and the implementation  can
  invoke  a  member  function upon such objects, but the expressions are
  not lvalues.

3 [Note: some  builtin  operators  and  function  calls  yield  lvalues.
  [Example:  if E is an expression of pointer type, then *E is an lvalue
  expression referring to the object or function to which E points.   As
  another example, the function
          int& f();
  yields an lvalue, so the call f() is an lvalue expression.  ] ]

4 [Note:  some  builtin  operators  expect  lvalue  operands.  [Example:
  builtin assignment operators all expect their left hand operands to be
  lvalues.   ]  Other  builtin  operators yield rvalues, and some expect
  them.  [Example: the unary and binary + operators expect rvalue  argu­
  ments  and  yield  rvalue  results.   ] The discussion of each builtin
  operator in clause _expr_ indicates whether it expects lvalue operands
  and whether it yields an lvalue.  ]

5 Constructor invocations and calls to functions that do not return ref­
  erences are always rvalues.  User defined operators are functions, and
  whether  such operators expect or yield lvalues is determined by their
  type.

6 Whenever an lvalue appears  in  a  context  where  an  lvalue  is  not
  expected,  the  lvalue  is  converted  to  an rvalue; see _conv.lval_,
  _conv.array_, and _conv.func_.

7 The discussion of reference initialization in  _dcl.init.ref_  and  of
  temporaries in _class.temporary_ indicates the behavior of lvalues and
  rvalues in other significant contexts.

8 Class rvalues can have cv-qualified types;  non-class  rvalues  always
  have  cv-unqualified types.  Rvalues always have complete types or the
  void type; in addition to these types, lvalues can  also  have  incom­
  plete types.

9 An  lvalue  for  an  object is necessary in order to modify the object
  except that an rvalue of class type can also be  used  to  modify  its
  referent  under  certain  circumstances.   [Example: a member function
  called for an object (_class.mfct_) can modify the object.  ]

10Functions cannot be modified, but pointers to functions can be modifi­
  able.

11A  pointer  to an incomplete type can be modifiable.  At some point in
  the program when this pointer type is complete, the  object  at  which
  the pointer points can also be modified.

12Array  objects  cannot  be modified, but their elements can be modifi­
  able.

13The referent of a const-qualified expression  shall  not  be  modified
  (through  that expression), except that if it is of class type and has
  a mutable component, that component can be modified (_dcl.type.cv_).

14If an expression can be used to modify its object, it is called  modi­
  fiable.  A program that attempts to modify an object through a nonmod­
  ifiable lvalue or rvalue expression is ill-formed.

15If a program attempts to access the stored value of an object  through
  an  lvalue  of  other  than one of the following types the behavior is
  undefined:

  --the dynamic type of the object,

  --a cv-qualified version of the declared type of the object,

  --a type that is the signed or  unsigned  type  corresponding  to  the
    declared type of the object,

  --a  type  that  is the signed or unsigned type corresponding to a cv-
    qualified version of the declared type of the object,

  --an aggregate or union type that includes one of  the  aforementioned
    types  among its members (including, recursively, a member of a sub­
    aggregate or contained union),

  --a type that is a (possibly cv-qualified)  base  class  type  of  the
    declared type of the object,

  --a char or unsigned char type.16)

  _________________________
  16) The intent of this list is to specify those circumstances in which
  an object may or may not be aliased.