______________________________________________________________________
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. ]
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_). A variable is introduced by the
declaration of an object. The variable's name denotes the object.
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_) of the identifier specified in each translation
unit.
3.1 Declarations and definitions [basic.def]
1 A declaration (_dcl.dcl_) introduces names into a translation unit or
redeclares names introduced by previous declarations. A declaration
specifies the interpretation and attributes of these names.
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 and defines x
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_). ]
6 A program is ill-formed if the definition of any object gives the
object an incompletely-defined object type (_basic.types_).
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 1 -------+
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 1 -------+
3 A non-local variable with static storage duration shall have exactly
one definition in a program unless the variable either has a built-in
type or is an aggregate and unless it is either unused or used only as
the operand of the sizeof operator.
+------- BEGIN BOX 2 -------+
This is still uncertain.
+------- END BOX 2 -------+
4 Exactly one definition of a class is required in a translation unit if
the class is used in a way that requires the class type to be
complete. [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] [Note: the rules for declarations and expressions
describe in which contexts complete class types are required. A class
type T must be complete if:
--an object of type T is defined (_basic.def_, _expr.new_), or
--an lvalue-to-rvalue conversion is applied to an lvalue referring to
an object of type T (_conv.lval_), or
--an expression is converted (either implicitly or explicitly) to type
T (_conv_, _expr.type.conv_, _expr.dynamic.cast_,
_expr.static.cast_, _expr.cast_), or
--an expression is converted to the type pointer to T or reference to
T using an implicit conversion (_conv_), a dynamic_cast
(_expr.dynamic.cast_) or a static_cast (_expr.static.cast_), or
--a class member access operator is applied to an object expression of
type T (_expr.ref_), or
--the typeid operator (_expr.typeid_) or the sizeof operator
(_expr.sizeof_) is applied to an operand of type T, or
--a function with a return type of type T is called (_expr.call_), or
--an lvalue of type T is assigned to (_expr.ass_). ]
5 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 the three requirements described above (and, if the
default argument has sub-expressions with default arguments, this
requirement 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) { }
class D: public X { }; // 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.nondep_), 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 portion of program text called a
declarative region, which is the largest part of the program in which
that name is valid, that is, in which that name may be used as an
unqualified name to refer to the same entity. In general, each par
ticular name is valid only within some possibly discontiguous portion
of program text called its scope. To determine the scope of a decla
ration, it is sometimes convenient to refer to the potential scope of
a declaration. The scope of a declaration is the same as its poten
tial 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 The names declared by a declaration are introduced into the scope in
which the declaration occurs, except that the presence of a friend
specifier (_class.friend_), certain uses of the elaborated-type-
specifier (_basic.scope.pdecl_), and using-directives (_names
pace.udir_) alter this general behavior.
4 [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 (indeterminate) value.
]
2 [Note: 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 After the point of declaration of a class member, the member name can
be looked up in the scope of its class. [Note: this is true even if
the class is an incomplete class. For example,
struct X {
enum E { z = 16 };
int b[X::z]; //ok
};
--end note]
5 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: except for the friend class declaration case mentioned below,
any other form of elaborated-type-specifier must refer to an already
declared class-name or enum-name; see _basic.lookup.elab_. ]
6 A class declared as a friend with a declaration of the form:
friend class-key identifier ;
and not previously declared is introduced in the smallest enclosing
non-class scope that contains the friend declaration. A function
declared as a friend and not previously declared, is introduced in the
smallest enclosing non-class scope that contains the friend declara
tion. [Note: when looking for a prior declaration of a class or func
tion introduced by a friend declaration, scopes outside of the inner
most enclosing namespace scope are not considered; see _names
pace.memdef_. ]
7 [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
potential scope begins at its point of declaration
(_basic.scope.pdecl_) and ends at the end of its declarative region.
2 The potential scope of a function parameter name in a function defini
tion (_dcl.fct.def_) begins at its point of declaration and ends at
the end of the outermost block of the function definition. A parame
ter name shall not be redeclared in the outermost block of the func
tion definition.
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_) have function scope and may 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 referred to after the :: scope resolu
tion 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 potential 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 construc
tor 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 is required.
4)A name declared within a member function hides a declaration of
the same name whose scope extends to or past the end of the member
function's class.
5)The potential 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 the members are 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 A name "looked up in the context of an expression" is looked up as an
unqualified name in the scope where the expression is found.
3 [Note: _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 use in global scope.
4 A name used in a user-declared namespace outside of the definition of
any function or class shall be declared before its use in that names
pace or before its use in a namespace enclosing its namespace.
5 A name used in the definition of a function2) that is a member of
namespace N (where, only for the purpose of exposition, N could repre
sent 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 namespaces. [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 a member func
tion body or nested class definition3) 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
_________________________
2) This refers to unqualified names following the function declarator;
such a name may be used as a type or as a default argument name in the
parameter-declaration-clause, or may be used in the function body.
3) This refers to unqualified names following the class name; such a
name may be used in the base-clause or may be used in the class defi
nition.
--if X is a nested class of class Y (_class.nest_), before the defini
tion of X in Y, or shall be a member of a base class of Y (this look
up applies in turn to Y's enclosing classes, starting with the
innermost enclosing class),4) or
--if X is a local class (_class.local_) or is a nested class of a
local class, before the definition of class X in a block enclosing
the definition of class X, or
--if X is a member of namespace N, or is a nested class of a class
that is a member of N, or is a local class or a nested class within
a local class of a function that is a member of N, before the defi
nition of class X in namespace N or in one of N's enclosing names
paces.
[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] [Note: when looking for a prior declaration of a class
or function introduced by a friend declaration, scopes outside of the
innermost enclosing namespace scope are not considered; see _names
pace.memdef_. ] [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. ]
7 A name used in the definition of a function that is a member function
(_class.mfct_)5) of class X shall be declared in one of the following
_________________________
4) This look up applies whether the definition of X is nested within
Y's definition or whether X's definition appears in a namespace scope
enclosing Y's definition (_class.nest_).
5) That is, an unqualified name following the function declarator;
such a name may be used as a type or as a default argument name in the
parameter-declaration-clause, or may be used in the function body, or,
if the function is a constructor, may be used in the expression of a
mem-initializer.
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 in turn to Y's enclosing classes, starting with the inner
most enclosing class),6) or
--if X is a local class (_class.local_) or is a nested class of a
local class, before the definition of class X in a block enclosing
the definition of class X, or
--if X is a member of namespace N, or is a nested class of a class
that is a member of N, or is a local class or a nested class within
a local class of a function that is a member of N, before the member
function definition, in namespace N or in one of N's enclosing named
namespaces.
[Example:
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
// 6) global scope, before the definition of M::N::X::f
--end example] [Note: _class.mfct_ and _class.static_ further
describe the restrictions on the use of names in member function defi
nitions. _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 defini
tions. ]
_________________________
6) This look up applies whether the member function is defined within
the definition of class X or whether the member function is defined in
a namespace scope enclosing X's definition.
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. ]
11A name used in the handler for a function-try-block (_except_) is
looked up as if the name was used in the outermost block of the func
tion definition. In particular, the function parameter names shall
not be redeclared in the exception-declaration or in the outermost
block of a handler for the function-try-block. Names declared in the
outermost block of the function definition are not found when looked
up in the scope of a handler for the function-try-block.
12[Note: the rules for name look up in template definitions are
described in _temp.res_. ]
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 preceding the :: scope resolution operator, object, func
tion, and enumerator names are ignored. If the name found is not a
class-name (_class_) or namespace-name (_namespace.def_), the program
is ill-formed. [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 { };
static const int number = 50;
static X arr[number];
};
X C::arr[number]; // ill-formed:
// 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, in the translation unit where it is used. The
name shall be declared in global namespace scope or shall be a name
whose declaration is visible in global scope because of a using direc
tive (_namespace.qual_). The use of :: allows a global name to be
referred to even if its identifier has been hidden
(_basic.scope.hiding_).
5 A nested-name-specifier that names a scalar type, followed by ::, fol
lowed by ~type-name is a pseudo-destructor-name for a scalar type
(_expr.pseudo_). The type-name is looked up as a type in the scope of
the nested-name-specifier. [Example:
struct A {
typedef int I;
};
typedef int I1, I2;
extern int* p;
extern int* q;
p->A::I::~I(); // I is looked up in the scope of A
q->I1::~I2(); // I2 is looked up in the scope of
// the postfix-expression
--end example] [Note: _basic.lookup.classref_ describes how name look
up proceeds after the . and -> operators. ]
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: a
class member can be referred to using a qualified-id as soon as the
member point of declaration (_basic.scope.pdecl_) in the class member-
specification has been encountered. ] [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(double);
}
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]
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(int){} // 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]
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 object, function, or enumerator declaration
(_basic.scope.hiding_). The class-name or enum-name in the elabo
rated-type-specifier may either be a simple identifer or be a quali
fied-id.
2 If the name in the elaborated-type-specifier is a simple 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 name 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 If the id-expression in a class member access (_expr.ref_) is an
unqualified-id, and the type of the object expression is of a class
type C (or of pointer to a class type C), the unqualified-id is looked
up in the scope of class C. If the type of the object expression is
of pointer to scalar type, the unqualified-id is looked up in the
scope of the object expression.
2 If the unqualified-id is ~type-name, and the type of the object
expression is of a class type C (or of pointer to a class type C), the
type-name is looked up in the context of the entire postfix-expression
and in the scope of class C. The type-name shall refer to a class-
name. If type-name is found in both contexts, the name shall refer to
the same class type. If the type of the object expression is of
scalar type, the type-name is looked up in the scope of the object
expression (_expr.pseudo_).
3 If the id-expression in a class member access is a qualified-id of the
form
class-name-or-namespace-name::...
the class-name-or-namespace-name following the . or -> operator is
looked up both in the context of the entire postfix-expression and in
the scope of the class of the object expression. If the name is found
only in the scope of the class of the object expression, the name
shall refer to a class-name. If the name is found only in the context
of the entire postfix-expression, the name shall refer to a class-name
or namespace-name. If the name is found in both contexts, the class-
name-or-namespace-name shall refer to the same entity. [Note: because
the name of a class is inserted in its class scope (_class_), the name
of a class is also considered a nested member of that class. ]
4 If the qualified-id has the form
::class-name-or-namespace-name::...
the class-name-or-namespace-name is looked up in global scope as a
class-name or namespace-name.
5 If the nested-name-specifier contains a class template-id
(_temp.names_), its template-arguments are evaluated in the context in
which the entire postfix-expression occurs.
6 If the id-expression is a conversion-function-id, its conversion-type-
id shall denote the same type in both the context in which the entire
postfix-expression occurs and in the context of the class of the
object expression (or the class pointed to by the pointer expression).
3.4.5 Using directives and namespace aliases [basic.lookup.udir]
1 When looking up a namespace-name in a using-directive or namespace-
alias-definition, only namespace names are considered.
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 in 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 having namespace scope (_basic.scope.namespace_) has internal
linkage if it is the name of
--an object 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
--a function template that is explicitly declared static or, is
explicitly declared inline; or
--the name of a data member of an anonymous union.
4 A name having namespace scope has external linkage if it is the name
of
--an object, 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, unless it is a function template that has internal link
age (_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. It is implementation-defined whether
a program in a freestanding environment is required to define a main
function. [Note: in a freestanding environment, start-up and termina
tion is implementation-defined; start-up contains the execution of
constructors for objects of namespace scope with static storage dura
tion; termination contains the execution of destructors for objects
with static storage duration. ]
2 An implementation shall not predefine the main function. This func
tion shall not be overloaded. It shall have a return type of type
int, but otherwise its type is implementation-defined. All implemen
tations 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. A program
that takes the address of main, or declares it inline or static is
ill-formed. The name main is not otherwise reserved. [Example: mem
ber 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_). If exit
is called to end a program during the destruction of an object with
static storage duration, the program has undefined behavior.
5 A return statement in main has the effect of leaving the main function
(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 storage for objects with static storage duration
(_basic.stc.static_) shall be zero-initialized (_dcl.init_) before any
other initialization takes place. Objects of POD types
(_basic.types_) with static storage duration initialized with constant
expressions (_expr.const_) shall be initialized before any dynamic
initialization takes place. Objects of namespace scope with static
storage duration defined in the same translation unit and dynamically
initialized shall be initialized in the order in which their defini
tion appears in the translation unit. [Note: _dcl.init.aggr_
describes the order in which aggregate members are initialized. The
initialization of local static objects is described in _stmt.dcl_. ]
2 An implementation is permitted to perform the initialization of an
object of namespace scope with static storage duration as a static
initialization even if such initialization is not required to be done
statically, provided that
--the dynamic version of the initialization does not change the value
of any other object of namespace scope with static storage duration
prior to its initialization, and
--the static version of the initialization produces the same value in
the initialized object as would be produced by the dynamic initial
ization if all objects not required to be initialized statically
were initialized dynamically.
[Note: as a consequence, if the initialization of an object obj1
refers to an object obj2 of namespace scope with static storage dura
tion potentially requiring dynamic initialization and defined later in
the same translation unit, it is unspecified whether the value of obj2
used will be the value of the fully initialized obj2 (because obj2 was
statically initialized) or will be the value of obj2 merely zero-
initialized. For example,
inline double fd() { return 1.0; }
extern double d1;
double d2 = d1; // unspecified:
// may be statically initialized to 0.0 or
// dynamically initialized to 1.0
double d1 = fd(); // may be initialized statically to 1.0
--end note]
3 It is implementation-defined whether the dynamic initialization
(_dcl.init_, _class.static_, _class.ctor_, _class.expl.init_) of an
object of namespace scope with static storage duration is done before
the first statement of main or deferred to any point in time after the
first statement of main but before the first use of a function or
object defined in the same translation unit. [Example:
// -- File 1 --
#include "a.h"
#include "b.h"
B b;
A::A(){
b.Use();
}
// -- File 2 --
#include "a.h"
A a;
// -- File 3 --
#include "a.h"
#include "b.h"
extern A a;
extern B b;
main() {
a.Use();
b.Use();
}
It is implementation-defined whether a is defined before main is
entered or whether its definition is delayed until a is first used in
main. It is implementation-defined whether b is defined before main
is entered or whether its definition is delayed until b is first used
in main. In particular, if a is defined before main is entered, it is
not guaranteed that b will be initialized before it is used by the
initialization of a, that is, before A::A is called. ]
4 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 objects of static storage
duration (declared at block scope or at namespace scope) are called
when returning from main and when calling exit
(_lib.support.start.term_). These objects are destroyed in the
reverse order of the completion of their constructors. For an object
of array or class type, all subobjects of that object are destroyed
before any local object with static storage duration initialized dur
ing the construction of the subobjects is destroyed.
2 If a function contains a local object of static storage duration that
has been destroyed and the function is called during the destruction
of an object with static storage duration, the program has undefined
behavior if the flow of control passes through the definition of the
previously destroyed local object.
3 If a function is registered with atexit (see <cstdlib>,
_lib.support.start.term_) then following the call to exit, any objects
with static storage duration initialized prior to the registration of
that function will not be destroyed until the registered function is
called from the termination process and has completed. For an object
with static storage duration constructed after a function is regis
tered with atexit, then following the call to exit, the registered
function is not called until the execution of the object's destructor
has completed.
4 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.
5 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 the property of an object that defines the minimum
potential lifetime of the storage containing the object. 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
(_basic.start.init_, _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. [Note: _stmt.dcl_ describes the initialization of
local static variables; _basic.start.term_ describes the destruction
of local static variables. ]
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 The global allocation and deallocation functions are always implicitly
declared. The library provides default definitions for them
(_lib.new.delete_). A C++ program shall provide at most one defini
tion of any of the functions
::operator new(size_t)
::operator new(size_t, void*)
::operator new(size_t, const std::nothrow&)
::operator new[](size_t)
::operator new[](size_t, void*)
::operator new[](size_t, const std::nothrow&)
::operator delete(void*)
::operator delete(void*, void*)
::operator delete(void*, const std::nothrow&)
::operator delete[](void*)
::operator delete[](void*, void*)
::operator delete[](void*, const nothrow&)
Any such function definitions replace the default versions. This
replacement is global and takes effect upon program startup
(_basic.start_). Allocation and/or deallocation 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). 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
not be a null pointer value (_conv.ptr_) and shall not point to or
within any other currently allocated storage. The results of derefer
encing a pointer returned as a request for zero size are undefined.7)
3 If an allocation function is unable to obtain an appropriate block of
storage, it can invoke the currently installed new_handler8) 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 (_lib.support.types_) may be added. If both
versions are declared in the same class, the one-parameter form is the
_________________________
7) 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.
8) 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_).
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 a null pointer value, 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 a null pointer value, 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 If the argument given to a deallocation function is a pointer that is
not the null pointer value (_conv.ptr_), the deallocation function
will deallocate the storage referenced by the pointer and render the
pointer invalid. The value of a pointer that refers to deallocated
storage is indeterminate. The effect of using the value of a pointer
to deallocated storage is undefined.9)
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.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. ]
_________________________
9) On some implementations, it causes a system-generated runtime
fault.
3 The properties ascribed to objects throughout this International Stan
dard apply for a given object only during its lifetime. [Note: in
particular, before the lifetime of an object starts and after its
lifetime ends there are significant restrictions on the use of the
object, as described below, in _class.base.init_ and in _class.cdtor_.
Also, 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 objects during the construction and destruction
phases. ]
4 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
shall not be implicitly called and any program that depends on the
side effects produced by the destructor has undefined behavior.
5 Before the lifetime of an object has started but after the storage
which the object will occupy has been allocated10) or, after the life
time of an object has ended and before the storage which the object
occupied is reused or released, any pointer that refers to the storage
location where the object will be or was located may be used but only
in limited ways. Such a pointer refers to allocated storage
(_basic.stc.dynamic.deallocation_), and using the pointer as if the
pointer were of type void*, is well-defined. Such a pointer may be
dereferenced (to initialize a reference, for example) but converting
the resulting lvalue to an rvalue (_conv.lval_) results in undefined
behavior. If the object will be or was of a class type with a non-
trivial destructor, and the pointer is used as the operand of a
delete-expression, the program has undefined behavior. If the object
will be or was of a non-POD class type, the program has undefined
behavior if:
--the pointer is used to access a non-static data member or call a
non-static member function of the object, or
--the pointer is implicitly converted (_conv.ptr_) to a pointer to a
base class type, or
--the pointer is used as the operand of a static_cast
(_expr.static.cast_) (except when the conversion is to void* or
char*)
--the pointer is used as the operand of a dynamic_cast
(_expr.dynamic.cast_). [Example:
_________________________
10) For example, before the construction of a global object of non-POD
class type (_class.cdtor_).
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]
6 Similarly, before the lifetime of an object has started but after the
storage which the object will occupy has been allocated or, after the
lifetime of an object has ended and before the storage which the
object occupied is reused or released, any reference to the original
object may be used but only in limited ways. Such a reference refers
to allocated storage (_basic.stc.dynamic.deallocation_), and using the
reference as an lvalue (to initialize another reference, for example)
is well-defined. If an lvalue-to-rvalue conversion (_conv.lval_) is
applied to such a reference, the program has undefined behavior; if
the original object will be or was of a non-POD class type, the pro
gram has undefined behavior if:
--the reference is used to access a non-static data member or call a
non-static member function of the object, or
--the reference is used as the operand of a static_cast
(_expr.static.cast_) (except when the conversion is to char&), or
--the reference is used as the operand of a dynamic_cast
(_expr.dynamic.cast_) or as the operand of typeid.
7 If, after the lifetime of an object has ended and before the storage
which the object occupied is reused or released, a new object is cre
ated at the storage location which the original object occupied, a
pointer that pointed to the original object or, a reference that
referred to the original object or, the name of 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 most derived object (_intro.object_) of
type T and the new object is a most derived 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,11) 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:
class T { };
struct B {
~B();
};
void h() {
B b;
new (&b) T;
} // undefined behavior at block exit
--end example]
9 Creating a new object at the storage location that a const object with
static or automatic storage duration occupies or, at the storage
_________________________
11) that is, an object for which a destructor will be called implicit
ly -- either upon exit from the block for an object with automatic
storage duration or upon exit from the program for an object with
static storage duration.
location that such a const object used to occupy before its lifetime
ended results in undefined behavior. [Example:
struct B {
B();
~B();
};
const B b;
void h() {
b.~B();
new (&b) const B; // undefined behavior
}
--end example]
3.9 Types [basic.types]
1 [Note: these clauses impose requirements on implementations regarding
the representation of types. There are two kinds of types: fundamen
tal types and compound types. Types describe objects
(_intro.object_), references (_dcl.ref_), or functions (_dcl.fct_). ]
2 For any object type T, whether or not the object holds a valid value
of type T, the underlying bytes (_intro.memory_) making up the object
can be copied into an array of char or unsigned char.12) If the con
tent of the array of char or unsigned char is copied back into the
object, the object shall subsequently hold its original value. [Exam
ple:
#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 POD 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]
_________________________
12) By using, for example, the library functions (_lib.headers_) mem
cpy or memmove.
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 that hold the value of type T. For POD types, the value repre
sentation is a sequence of bits in the object representation that
determines a value, which is one discrete element of an implementa
tion-defined set of values.13)
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 A class that has been declared but not defined or, an array of unknown
size or of incomplete element type is an incomplete type.14) Also, the
void type is an incomplete type (_basic.fundamental_). Objects shall
not be defined to have an incomplete type. The term incompletely-
defined object type is a synonym for incomplete type; the term com
pletely-defined object type is a synonym for complete 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 object might be an
array of incomplete class type and therefore incomplete; if the class
type is completed later on in the translation unit, the array type
becomes complete; the array type at those two points is the same type.
The declared type of an array object might be an array of unknown size
and therefore be incomplete 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. The type
of a pointer to array of unknown size, or of a type defined by a type
def declaration 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
_________________________
13) The intent is that the memory model of C++ is compatible with that
of ISO/IEC 9899 Programming Language C.
14) The size and layout of an instance of an incomplete type is un
known.
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
}
--end example]
8 [Note: the rules for declarations and expressions describe in which
contexts incomplete types are prohibited. ]
9 Arithmetic types (_basic.fundamental_), enumeration types, pointer
types, and pointer to member types (_basic.compound_), and cv-
qualified versions of these types (_basic.type.qualifier_) are collec
tively called 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 collectively called 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 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. Plain ints have the
natural size suggested by the architecture of the execution
environment15) ; the other signed integer types are provided to meet
_________________________
15) that is, large enough to contain any value in the range of INT_MIN
and INT_MAX, as defined in the header <climits>.
special needs.
3 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
type16) ; 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 each
corresponding signed/unsigned type shall be the same.
4 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.17)
5 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.
6 Values of type bool are either true or false.18) [Note: 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 par
ticipate in integral promotions (_conv.prom_).
7 Types bool, char, wchar_t, and the signed and unsigned integer types
are collectively called integral types.19) A synonym for integral type
is integer type. The representations of integral types shall define
values by use of a pure binary numeration system.20) [Example: this
_________________________
16) See _dcl.type.simple_ regarding the correspondence between types
and the sequences of type-specifiers that designate them.
17) 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.
18) 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.
19) 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_.
20) A positional representation for integers that uses the binary dig
its 0 and 1, in which the values represented by successive bits are
additive, begin with 1, and are multiplied by successive integral pow
er of 2, except perhaps for the bit with the highest position.
(Adapted from the American National Dictionary for Information Pro
cessing Systems.)
International Standard permits 2's complement, 1's complement and
signed magnitude representations for integral types. ]
8 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 maximum and minimum values of each arithmetic types for an
implementation.
9 The void type has an empty set of values. The void type is an incom
plete type that cannot be completed. It is used as the return type
for functions that do not return a value. Any expression can be
explicitly converted to type void (_expr.cast_); the resulting expres
sion 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_).
10[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_;
--enumerations, which comprise a set of named constant values. Each
distinct enumeration constitutes a different enumerated type,
_dcl.enum_;
--pointers to non-static21) class members, which identify members of a
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*.
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_).22)
_________________________
21) Static class members are objects or functions, and pointers to
them are ordinary pointers to objects or functions.
22) The same representation and alignment requirements are meant to
imply interchangeability as arguments to functions, return values from
functions, and members of unions.
2 A compound type (_basic.compound_) is not cv-qualified by the cv-
qualifiers (if any) of the type from which it is compounded. Any cv-
qualifiers that appear in an array declaration apply to the array ele
ment 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.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.23)
3 [Note: some built-in 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();
_________________________
23) 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.
yields an lvalue, so the call f() is an lvalue expression. ] ]
4 [Note: some built-in operators expect lvalue operands. [Example:
built-in assignment operators all expect their left hand operands to
be lvalues. ] Other built-in 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 built-in
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 rvalue is 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 shall always have complete types
or the void type; in addition to these types, lvalues can also have
incomplete 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 the pointed to type is complete, the object at which
the pointer points can also be modified.
12The 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_).
13If an expression can be used to modify the object to which it refers,
the expression is called modifiable. A program that attempts to mod
ify an object through a nonmodifiable lvalue or rvalue expression is
ill-formed.
14If 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
undefined24):
_________________________
--the dynamic type of the object,
--a cv-qualified version of the dynamic type of the object,
--a type that is the signed or unsigned type corresponding to the
dynamic type of the object,
--a type that is the signed or unsigned type corresponding to a cv-
qualified version of the dynamic 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
dynamic type of the object,
--a char or unsigned char type.
_________________________
24) The intent of this list is to specify those circumstances in which
an object may or may not be aliased.