#FredOverflow mentioned in the C++ chatroom that this is a rare case of rvalues that have names. The C++0x FDIS mentions under 5.1.1 [expr.prim.general] p4:
Otherwise, if a member-declarator declares a non-static data member (9.2) of a class X, the expression this is a prvalue of type “pointer to X” within the optional brace-or-equal-initializer. It shall not appear elsewhere in the member-declarator. (emphasis mine)
What others are there, if any?
One prominent case are enumerators
enum arity { one, two };
The expressions one and two are rvalues (more specifically, prvalues in C++0x). Another are template non-type parameters
template<int *P> struct A { };
The expression P is an rvalue too (more specifically again, a prvalue in C++0x).
The boolean literals true and false are prvalues of type bool.
nullptr is a prvalue of type nullptr_t.
When you return a named variable from a function, it becomes an xvalue in the context of that expression, and an xvalue is an rvalue (per §3.10/1).
There may be more, but those are all I can think of at the moment (and the third is questionable -- it's really the expression that's the xvalue, but with something like return x; (where x is a local variable and you're returning the value, not a reference), the name of the variable is the expression. The name really refers to a glvalue, and in the expression that value (but not really the name) gets converted to an xvalue (which is an rvalue).
Related
This is a follow-up of the question: What does the void() in decltype(void()) mean exactly?.
decltype(void()) compiles fine and what the void() means in this case is explained in the above mentioned question (actually in the answer).
On the other side, I noticed that decltype(void{}) doesn't compile.
What's the difference between them (in the context of a decltype at least)?
Why doesn't the second expression compile?
For completeness, it follows a minimal (not-)working example:
int main() {
// this doesn't compile
//decltype(void{}) *ptr = nullptr;
// this compiles fine
decltype(void()) *ptr = nullptr;
(void)ptr;
}
void() is interpreted as type-id when used with sizeof.
void() is interpreted as an expression when used with decltype.
I don't think void{} is valid in any context. It is neither a valid type-id nor a valid expression.
(Building on discussion in the question comments)
Note: I was referencing C++17 or close-to for the answer. C++14 works the same way, the text difference is noted near the end of the answer.
void() is a special exception. See N4618 5.2.3 [expr.type.conv], emphasis mine:
1 A simple-type-specifier (7.1.7.2) or typename-specifier (14.6) followed by a parenthesized optional expression-list or by a braced-init-list (the initializer) constructs a value of the specified type given the initializer. If the type is a placeholder for a deduced class type, it is replaced by the return type of the function selected by overload resolution for class template deduction (13.3.1.8) for the remainder of this section.
2 If the initializer is a parenthesized single expression, the type conversion expression is equivalent (in definedness, and if defined in meaning) to the corresponding cast expression (5.4). If the type is (possibly cv-qualified) void and the initializer is (), the expression is a prvalue of the specified type that performs no initialization. Otherwise, the expression is a prvalue of the specified type whose result object is direct-initialized (8.6) with the initializer. For an expression of the form T(), T shall not be an array type.
So void() is only valid because it's explicitly identified in [expr.type.conv]/2 as no initialization. void{} doesn't meet that exception, so it attempts to be a direct-initialized object.
tl;dr here through C++14 notes: You cannot direct-initialize a void object.
Rabbit-holing through N4618 8.6 [dcl.init] to see what's actually going on with void{}
8.6/16 => direct-initialization
8.6/17.1 => list-initialized, jump to 8.6.4
8.6.4/3.10 => value-initialized
void() would have shortcut the above three with 8.6/11 => value-initialized, and then rejoined the trail, which is why the special exception in [expr.type.conv] is needed.
8.6/8.4 => zero-initialized
Now, 8.6/6 defines zero-initialize for:
scalar
non-union class type
union type
array type
reference type
N4618 3.9 [basic.types]/9 defines scalar:
Arithmetic types (3.9.1), enumeration types, pointer types, pointer to member types(3.9.2), std::nullptr_t, and cv-qualified versions of these types (3.9.3) are collectively called scalar types.
N4618 3.9.1 [basic.fundamental]/8 defines arithmetic types:
Integral and floating types are collectively called arithmetic types.
So void is not an arithmetic type, so it's not a scalar, so it cannot be zero-initialized, so it cannot be value-initialized, so it cannot be direct-initialized, so the expression is not valid.
Apart from the initialisation, void() and void{} would work the same way, producing a prvalue expression of type void. Even though you cannot have a result object for an incomplete type, and void is always incomplete:
N4618 3.9.1 [basic.fundamental]/9 (bold mine):
A type cv void is an incomplete type that cannot be completed; such a type has an empty set of values.
decltype specifically allows incomplete types:
N4618 7.1.7.2 [decl.type.simple]/5 (bold mine):
If the operand of a decltype-specifier is a prvalue, the temporary materialization conversion is not applied (4.4) and no result object is provided for the prvalue. The type of the prvalue may be incomplete.
In C++14, N4296 5.2.3 [expr.type.conv] is differently worded. The braced form was almost an afterthought to the parenthesised version:
A simple-type-specifier (7.1.6.2) or typename-specifier (14.6) followed by a parenthesized expression-list constructs a value of the specified type given the expression list. If the expression list is a single expression, the type conversion expression is equivalent (in definedness, and if defined in meaning) to the corresponding cast expression (5.4). If the type specified is a class type, the class type shall be complete. If the expression list specifies more than a single value,the type shall be a class with a suitably declared constructor(8.5,12.1), and the expression T(x1, x2, ...) is equivalent in effect to the declaration T t(x1, x2, ...); for some invented temporary variable t, with the result being the value of t as a prvalue.
The expression T(), where T is a simple-type-specifier or typename-specifier for a non-array complete object type or the (possibly cv-qualified) void type, creates a prvalue of the specified type, whose value is that produced by value-initializing (8.5) an object of type T; no initialization is done for the void() case. [Note: if T is a non-class type that is cv-qualified, the cv-qualifiers are discarded when determining the type of the resulting prvalue (Clause 5). —end note]
Similarly, a simple-type-specifier or typename-specifier followed by a braced-init-list creates a temporary object of the specified type direct-list-initialized (8.5.4) with the specified braced-init-list, and its value is that temporary object as a prvalue.
The effect is the same for our purposes, the change relates to P0135R1 Wording for guaranteed copy elision through simplified value categories, which removed temporary object creation from expressions. Instead, the context of the expression provides a result object to be initialised by the expression, if the context needs it.
As noted above, decltype (unlike sizeof or typeid) doesn't provide a result-object for the expression, which is why void() works even though it cannot initialise a result object.
I feel that the exception in N4618 5.2.3 [expr.type.conv] ought to be applied to void{} too. It means that guidelines around {} get more complex. See for example ES.23: Prefer the {} initializer syntax in the C++ Core Guidelines, which would currently recommend decltype(void{}) over decltype(void()). decltype(T{}) is more likely to be where this one bites you...
Why is it that the template argument of a non-type reference cannot be another reference (g++ 4.8.1):
template <int& N> void test() { }
int x = 5;
int& p = x;
int main(){
test<x>(); //compiles fine
test<p>(); //error: could not convert template argument 'p' to 'int&'|
}
I can't see where from the standard p is violating anything, these seemed the most relevant sections (N3337):
[14.3.2] [.1] A template-argument for a non-type, non-template template-parameter shall be one of:
— for a non-type template-parameter of integral or enumeration type, a converted constant expression (5.19) of the type of the template-parameter; or
— the name of a non-type template-parameter; or
— a constant expression (5.19) that designates the address of an object with static storage duration and external or internal linkage or a function with external or internal linkage, including function templates
and function template-ids but excluding non-static class members, expressed (ignoring parentheses) as & id-expression, except that the & may be omitted if the name refers to a function or array and shall be omitted if the corresponding template-parameter is a reference; or .....
[.4]
[ Note: Temporaries, unnamed lvalues, and named lvalues with no linkage are not acceptable templatearguments
when the corresponding template-parameter has reference type.
[.5]
— For a non-type template-parameter of type reference to object, no conversions apply. The type referred
to by the reference may be more cv-qualified than the (otherwise identical) type of the templateargument.
The template-parameter is bound directly to the template-argument, which shall be an
lvalue.
p should be considered an lvalue shouldn't it? The only other thing I could think of was maybe a lack of linkage for references but adding extern int& p = x didn't fix it either.
This is related to the previous question template instantiation with constexpr function failure which I linked to a while ago in the comments, although your case is different.
It looks the example was previously not allowed but support was added in to C++1z via the proposal Allow constant evaluation for all non-type template arguments which opens with:
the syntactic restrictions for pointers, references, and pointers to
members are awkward and prevent reasonable refactorings. [...] The
historical reason for the restriction was most likely that C++
previously did not have a sufficiently strong specification for
constant expressions of pointer, reference, or pointer-to-member type.
However, that is no longer the case. [...]
The specific changes that seems relevant to your case is the rewording of the draft C++ standard section 14.3.2 Template non-type arguments [temp.arg.nontype]/p1 from:
A template-argument for a non-type, non-template template-parameter shall be one of:
[...]
a constant expression (5.19) that designates the address of a complete object with static storage durationtion
and external or internal linkage or a function with external or internal linkage, including function
templates and function template-ids but excluding non-static class members, expressed (ignoring parentheses)
as & id-expression, where the id-expression is the name of an object or function, except that the
& may be omitted if the name refers to a function or array and shall be omitted if the corresponding
template-parameter is a reference; or
[...]
to:
A template-argument for a non-type template-parameter shall be a converted constant expression (5.20) of
the type of the template-parameter. For a non-type template-parameter of reference or pointer type, the
value of the constant expression shall not refer to (or for a pointer type, shall not be the address of):
a subobject (1.8),
a temporary object (12.2),
a string literal (2.13.5),
the result of a typeid expression (5.2.8), or
a predefined func variable (8.4.1).
and a change of section 5.20 Constant expressions [expr.const]/p4 has the following paragraph on converted constant expressions, which starts out:
A converted constant expression of type T is an expression, implicitly converted to type T, where the converted
expression is a constant expression and the implicit conversion sequence contains only
and this in particular was added:
[...] and where the reference binding (if any) binds directly [...]
Note, the current head version of clang compiles your code in C++1z mode, see it live.
The updated version of the N4268 was the one applied and clang C++1z implementation status section indicates this paper was support from clang 3.6. This code only works in C++1z mode for clang 3.6 and greater.
Using the simplified wording introduced by N4268 (and now in the WD),
A template-argument for a non-type template-parameter shall be a
converted constant expression (5.20) of the type of the template-parameter. For a non-type template-parameter of reference […] type, the
value of the constant expression shall not refer to […]: […cases that don't apply…]
"converted constant expression" is defined in [expr.const]/4:
A converted constant expression of type T is an expression,
implicitly converted to type T, where the converted expression is a
constant expression and the implicit conversion sequence contains
only […] and where the reference binding (if any) binds directly.
Clearly, the reference binds directly. Are x and p constant expressions in this context?
[expr.const]/5:
A constant expression is either a glvalue core constant expression
whose value refers to an entity that is a permitted result of a
constant expression (as defined below), or […]
A permitted result of a constant expression is defined in the next paragraph as
…an object with static storage duration that is either not a temporary object or […]
x and p do refer to an object with static storage duration, but are they core constant expressions in the given context? The answer is yes: As long as their value (or the value of the object p refers to) is not examined by the expression, which it isn't, everything's fine, even for p:
A conditional-expression e is a core constant expression unless the evaluation of e […] would evaluate one of the following expressions:
— an id-expression that refers to a variable or data member of
reference type unless the reference has a preceding initialization and
either
it is initialized with a constant expression
x as the initializer of p is a constant expression (just as it is a valid template-argument for int&), hence p as the template-argument is a constant expression as well.
Note that Clang as of version 3.6 compiles your snippet fine.
I'm trying to understand the C++11 concepts.
The standard draft which I have says:
An xvalue (an “eXpiring” value) also refers to an object, usually near the end of its lifetime (so that its
resources may be moved, for example). An xvalue is the result of certain kinds of expressions involving
rvalue references (8.3.2). [ Example: The result of calling a function whose return type is an rvalue
reference is an xvalue. —end example ]
OK, so what exactly are the "certain kinds of expressions" that produce xvalues? This part of the spec does not detail a list of these expressions.
I understand lvalue and prvalue (at least I think, I understand).
There is a helpful non-normative note in the introduction to §5 (C++11 §5[expr]/6):
[ Note: An expression is an xvalue if it is:
the result of calling a function, whether implicitly or explicitly, whose return type is an rvalue reference to object type,
a cast to an rvalue reference to object type,
a class member access expression designating a non-static data member of non-reference type in which the object expression is an xvalue, or
a .* pointer-to-member expression in which the first operand is an xvalue and the second operand is a pointer to data member.
In general, the effect of this rule is that named rvalue references are treated as lvalues and unnamed rvalue references to objects are treated as xvalues; rvalue references to functions are treated as lvalues whether named or not. —end note ]
Searching through the rest of §5, this list appears exhaustive. The list is followed by an example:
struct A {
int m;
};
A&& operator+(A, A);
A&& f();
A a;
A&& ar = static_cast<A&&>(a);
The expressions f(), f().m, static_cast<A&&>(a), and a + a are xvalues. The expression ar is an lvalue.
There are two common ways to get an xvalue expression:
Use std::move to move an object. std::move performs a static_cast to an rvalue reference type and returns the rvalue reference.
Use std::forward to forward an rvalue. std::forward is typically used in a function template to enable perfect forwarding of a function argument.
If the argument provided to the function template was an rvalue, the parameter type will be an rvalue reference, which is an lvalue. In this case, std::forward performs a static_cast to an rvalue reference type and returns the rvalue reference.
(Note: If the argument provided to the function template was an lvalue, the parameter type will be an lvalue reference and std::forward will return an lvalue reference.)
Clause 5, which describes the syntax of valid expressions, lists for each expression syntax the conditions in which the expression is an lvalue, an xvalue, or a prvalue. The complete list of possible xvalues from clause 5 is:
5.2.2 paragraph 10: A function call is ... an xvalue if the result type is an rvalue reference to object type.
(In the technical language of the Standard, "object type" doesn't mean the same as "class type". "Object type" includes fundamental types, pointers, and arrays, and excludes only function types. An rvalue reference to function type is always treated as an lvalue, not xvalue.)
The most notable functions which return an rvalue reference are of course std::move and sometimes std::forward.
5.2.5 paragraph 4: If E2 is a non-static data member ... if E1 is an xvalue, then E1.E2 is an xvalue
(On the other hand, a data member lookup E1->E2 is always an lvalue.)
Similarly, if E1 is an xvalue, then the data member lookup E1.*E2 is an xvalue:
5.5 paragraph 6: The result of a .* expression whose second operand is a pointer to a data member is of the same value category (3.10) as its first operand.
For the various types of casts:
dynamic_cast<Type>(expr): 5.2.7 paragraph 2
static_cast<Type>(expr): 5.2.9 paragraph 1
reinterpret_cast<Type>(expr): 5.2.10 paragraph 1
const_cast<Type>(expr): 5.2.11 paragraph 1
(Type) expr: 5.4 paragraph 1
the expression is an xvalue if and only if Type is an rvalue reference to object type. The same is also true for Type(expr), since
5.2.3 paragraph 1: If the expression list [in parentheses following a type name] is a single expression, the type conversion expression is equivalent (in definedness, and if defined in meaning) to the corresponding cast expression (5.4).
(On the other hand, Type{expr} is always a prvalue.)
Section 5.16 on the conditional operator ends up saying that A ? B : C can sometimes be an xvalue if B and/or C is an xvalue. But the complete rules are difficult to summarize.
If an expression ends up calling a user-defined overloaded operator function, then section 5.2.2 applies to that expression, not the one that describes the built-in operator's behavior. (See the expression a + a in the example #James posted.)
As you mentioned,
An xvalue (an “eXpiring” value) also refers to an object, usually near the end of its lifetime (so that its resources may be moved, for example).
Focus: object, be moved, end lifetime
Here is an example:
void move_test(){
std::string s = "I'm here!";
std::string m = std::move(s); // move from <s> to <m>
// s is now in an undefined, but valid state;
std::cout << "s=" << s << "; &s=" << &s << std::endl;
}
By moving, we can convert a named value (an lvalue,here is s) to being an rvalue(that is std::move(s)). More specifically, since it can’t be a prvalue (it has a name! In other words, it has an identity), it ends up being an xvalue.
xvalue always serves C++ move semantics.
What I gather from what I've read is that calling something an xvalue is a fancy way of saying:
An xvalue is just an rvalue whose storage may have been deallocated, so using it means you have to verify its existence by yourself.
Generally, it's one or more levels of indirection away from an actual rvalue.
By contrast, an rvalue is guaranteed to have its storage space existing as long as it is in scope.
I may be wrong but this is what I've understood.
typedef decltype(true ? (long&&)0 : (long&&)0) T;
What should T be?
According to gcc (4.7), it's long. According to clang (trunk), it's long&&. This difference is causing clang to fail to compile code that uses gcc 4.7's libstdc++. Who is right?
UPDATE: As ildjarn points out, Clang is right, and as Richard Smith points out, the error libstdc++ is due to an error in the Standard. Here is the relevant GCC bug, and the relevant Defect Report.
Clang is right. N3337 §7.1.6.2/4:
The type denoted by decltype(e) is defined as follows:
if e is an unparenthesized id-expression or an unparenthesized class member access, decltype(e) is the type of the entity named by e. If there is no such entity, or if e names a set of overloaded functions, the program is ill-formed;
otherwise, if e is an xvalue, decltype(e) is T&&, where T is the type of e;
otherwise, if e is an lvalue, decltype(e) is T&, where T is the type of e;
otherwise, decltype(e) is the type of e.
The operand of the decltype specifier is an unevaluated operand.
§5/6:
[ Note: An expression is an xvalue if it is:
the result of calling a function, whether implicitly or explicitly, whose return type is an rvalue reference to object type,
a cast to an rvalue reference to object type,
a class member access expression designating a non-static data member of non-reference type in which the object expression is an xvalue, or
a .* pointer-to-member expression in which the first operand is an xvalue and the second operand is a pointer to data member.
In general, the effect of this rule is that named rvalue references are treated as lvalues and unnamed rvalue references to objects are treated as xvalues; rvalue references to functions are treated as lvalues whether named or not. —end note ]
I was wary earlier that a literal 0 may somehow prevent this from qualifying as an object type in this context, but §3.9/8 clarifies things:
An object type is a (possibly cv-qualified) type that is not a function type, not a reference type, and not a void type.
The conditional operator doesn't affect anything here – §5.16/4:
If the second and third operands are glvalues of the same value category and have the same type, the result is of that type and value category and it is a bit-field if the second or the third operand is a bit-field, or if both are bit-fields.
In this case both are of the same value category (xvalue), and xvalues are glvalues.
Given:
int main() {
int x = 0;
int y = x; // <---
}
Could someone please tell me which clause of the standard (2003 preferred) mandates the conversion of the expression x from lvalue to rvalue in the initialisation of the object y?
(Or, if I'm mistaken and no such conversion takes place, then I'd like to learn that too!)
I find it easier (if maybe not 100% precise) to think of lvalue-s as real objects and rvalue-s as the value stored in the object. The expression x is an lvalue expression that refers to the object x defined in the first line, but when used as the right hand side of an assignment to a type that is not a user defined type the actual value is read, and that is where the conversion from lvalue to rvalue is performed: reading the contents of the object.
As to the specific clause in the standard that dictates that conversion... well, the closest that I can think is 4.1 [conv.lvalue]/2 (Lvalue to Rvalue conversion):
The value contained in the object indicated by the lvalue is the rvalue result.
The requirement that the right hand side of the assignment is an rvalue is either implicit or missing from 5.17 [expr.ass], but that is the case or else the following expression would be an error since the rhs is an rvalue and there is no rvalue-to-lvalue conversion:
int x = 5;
EDIT: For initialization, 8.5 [dcl.init]/14, last bullet (which refers to fundamental types) states (emphasis mine):
Otherwise, the initial value of the object being initialized is the (possibly converted) value of the initializer expression. [...]
That value there means that the lvalue expression in your example is read (i.e. converted to an rvalue). At any rate the previous paragraph that referred to assignment could be applied here: if initialization required an lvalue rather than an rvalue, the expression int i = 0; would be ill-formed.
I do believe that this is intuitive to some degree (what others already said - the value is needed, so there is an obvious need to convert the object designator to the value contained therein). The best I could come up with, by 4p3:
An expression e can be implicitly converted to a type T if and only if the declaration "T t=e;" is well-formed, for some invented temporary variable t (8.5). The effect of the implicit conversion is the same as performing the declaration and initialization and then using the temporary variable as the result of the conversion. The result is an lvalue if T is a reference type (8.3.2), and an rvalue otherwise. The expression e is used as an lvalue if and only if the initialization uses it as an lvalue.
Note the "if and only if" at the end - the initializer therefor is used as an rvalue, because the initialization uses it as an rvalue (result of the conversion). So by 3.10p7
Whenever an lvalue appears in a context where an rvalue is expected, the lvalue is converted to an rvalue; see 4.1, 4.2, and 4.3.
EDIT: The paragraph for entering 4p3 can be found at 8.5p16, last bullet:
Otherwise, the initial value of the object being initialized is the (possibly converted) value of the initializer expression.
Also note the comments below.
Is this what you're looking for:
§3.10/7
Whenever an lvalue appears in a context where an rvalue is expected, the lvalue is converted to an rvalue; see 4.1, 4.2, and 4.3.
And I think when you write int y = x, it basically copies the value contained in the object x which is a lvalue, but the value itself is an rvalue, hence the context expects an rvalue.
§4.1/2 says,
The value contained in the object indicated by the lvalue is the rvalue result.
Maybe these two quotations clarify your doubt. Correct me if my understanding is wrong. I would like to learn new things.
#Tomalak's comment:
My problem with this is that int& y = x; is valid, so in this case of course x may not be an rvalue. I don't know how irrelevant the difference in my example makes that, though
Well int &y = x does NOT copy the value. It just creates an alias of the object itself. But as I previously said int y = x, basically copies the value which is an rvalue. Hence, the context expects an rvalue, as a copying is being done here.
The initializer has the follwing grammar:
initializer:
= initializer-clause
( expression-list )
initializer-clause:
assignment-expression
{ initializer-list ,opt }
{ }
In your example, x is an assignment-expression which follows this chain of grammar productions:
conditional-expression ==>
logical-or-expression ==>
logical-and-expression ==>
inclusive-or-expression ==>
exclusive-or-expression ==>
and-expression ==>
equality-expression ==>
relational-expression ==>
shift-expression ==>
additive-expression ==>
multiplicative-expression ==>
pm-expression ==>
cast-expression ==>
unary-expression ==>
postfix-expression ==>
primary-expression ==>
id-expression ==>
unqualified-id ==>
identifier
And an identifier "is an lvalue if the entity is a function or variable" (5.1/4 "Primary expressions").
So in your example, the expression to the right of the = is an expression that happens to be an lvalue. It could be an rvalue of course, but it doesn't have to be. And there is no mandated lvalue-to-rvalue conversion.
I'm not sure what the value in knowing this is, though.
3.10 Lvalues and rvalues
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
cvqualified class type—also refer to
objects.47)
3 [Note: some builtin operators and
function calls yield lvalues.
[Example: if E is an expression of
pointer type, then *E is an lvalue
expression referring to the object or
function to which E points. As another
example, the function int& f(); yields
an lvalue, so the call f() is an
lvalue expression. ]
[Note: some builin operators expect lvalue operands. [Example: builtin
assignment operators all expect their
left hand operands to be lvalues. ]
Other builtin operators yield rvalues,
and some expect them. [Example: the
unary and binary + operators expect
rvalue arguments and yield rvalue
results. ] The discussion of each
builtin operator in clause 5 indicates
whether it expects lvalue operands and
whether it yieldsan lvalue. ]
5 The result of calling a function
that does not return a reference is an
rvalue. User defined operators are
functions, and whether such operators
expect or yield lvalues is determined
by their parameter and return types.
6 An expression which holds a
temporary object resulting from a cast
to a nonreference type is an rvalue
(this includes the explicit creation
of an object using functional notation
(5.2.3)).
7 Whenever an lvalue appears in a context where an rvalue is expected,
the lvalue is converted to an rvalue;
see 4.1, 4.2, and 4.3.
8 The discussion of reference
initialization in 8.5.3 and of
temporaries in 12.2 indicates the
behavior of lvalues and rvalues in
other significant contexts.
9 Class rvalues can have cvqualified
types; nonclass rvalues always have
cvunqualified types. Rvalues shall
always have complete types or the void
type; in addition to these types,
lvalues can also have incomplete
types.
10 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 (9.3) can modify the object.
]
11 Functions cannot be modified, but
pointers to functions can be
modifiable.
12 A 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.
13 The referent of a constqualified
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 (7.1.5.1).
14 If an expression can be used to
modify the object to which it refers,
the expression is called modifiable. A
program that attempts to modify an
object through a nonmodifiable lvalue
or rvalue expression is illformed.
15 If 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
undefined48): — the dynamic type of
the object, — a cvqualified 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 cvqualified 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 subaggregate or contained
union), — a type that is a (possibly
cvqualified) base class type of the
dynamic type of the object, — a char
or unsigned char type.