const type qualifier after function name

[minseokoh]

Hi,

Could someone explain why "const" is located after the function name
and what it means?

inline unsigned char *access(int off) const {
if (off < 0)
abort();
return (&bits_[off]);
}

Thank you so much

Min

 

[Victor Bazarov]

Could someone explain why "const" is located after the function name
and what it means?

inline unsigned char *access(int off) const {
if (off < 0)
abort();
return (&bits_[off]);
}

Doesn't your favourite C++ book explain that? What book are you
reading that doesn't? I am specifically asking so that I can put
it in my black list of the never-recommend-those books.

'const' refers to the object for which it is called. Inside that
function 'this' pointer has the type 'T const * const' (as opposed
to the regular 'T * const').

Also, note that the keyword 'inline' is superfluous if the function
is defined inside the class definition (as it apparently is, here).

V

 

[James Kanze]

(e-mail address removed) wrote:

'const' refers to the object for which it is called. Inside that
function 'this' pointer has the type 'T const * const' (as opposed
to the regular 'T * const').

Just a very technical (and not very important) nit: the this
pointer is an rvalue (of non-class type), so top level
cv-qualifiers are ignored: the type of this is T* or T const*,
and the reason you can't modify it it because it is an rvalue,
and not because of const-ness.

 

[terminator]

Just a very technical (and not very important) nit: the this
pointer is an rvalue (of non-class type), so top level
cv-qualifiers are ignored: the type of this is T* or T const*,
and the reason you can't modify it it because it is an rvalue,
and not because of const-ness.

--
James Kanze (GABI Software) email:[email protected]
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

With all respect I should ask in what way it is an rvalue?

thanks in advance,
FM.

 

[Victor Bazarov]

With all respect I should ask in what way it is an rvalue?

You cannot take its address, you cannot modify it, you cannot initialise
a reference with it.

And, please don't quote signatures.

V

 

[terminator]

You cannot take its address, you cannot modify it, you cannot initialise
a reference with it.

rvalues are not none-modifiable:

f().g();//g modifies

I can initialize const refs(rvalue ref in next generation of
compilers)with rvalues:

class A f();
const A& ar=f();

probably the only thing I can`t do with an rvalue is taking its
address.So if we define an rvalue as an intrinsically none-addressible
object 'this' can be considered a const rvalue which
exceptionally ,does not initialize any kind of reference.But that does
not mean that 'this' is not 'const' ,ecause the only source of none-
modifiablity is constness.Further more ,do you mean that the following
does not compile?

class A{
void F(){
const A * const & c_to_cA_ptr_ref = this ;
};
};

I try to fancy that 'this' is a compiler defined function but it has
inconsistent syntax and looks more like a C# read-only property than
anything else.

thanks for clarification,
FM

 

[James Kanze]

With all respect I should ask in what way it is an rvalue?

Anything that is not an lvalue.

Seriously, it's hard to give a simple answer. In C++, the
result of an expression is either an lvalue or an rvalue---the
standard specifies for each operator which. Some operators
require lvalues, others rvalues, as operands. There is an
lvalue to rvalue conversion, so you can use an lvalue anywhere,
but an rvalue cannot be used where an lvalue is expected.

Intuitively, you can think of an lvalue as an expression that
designates an object in memory, and an rvalue as an expression
that just has a value, without an underlying object. Thus, to
assign *to* something, you need an lvalue---since you have to
modify the object, it must exist somewhere. But you can assign
from an rvalue; all you need is the value. (This is
historically where the names come from: an lvalue was something
that could appear to the left of an assignment, whereas an
rvalue could only appear to the right. But that is a radical
oversimplification in today's language.) Roughly speaking, if
the expression has an address, and would have one even if it
were of a primitive type, then it is an lvalue.

 

[James Kanze]

That's true for rvalues with built-in types (including this,
which always has a pointer type), but the issue becomes more
complicated for user defined (class) types.

rvalues are not none-modifiable:

f().g();//g modifies

I can initialize const refs(rvalue ref in next generation of
compilers)with rvalues:

class A f();
const A& ar=f();

You can do that today.

probably the only thing I can`t do with an rvalue is taking its
address.

And what is the this pointer in g(), above, in your first
example, if not the address of an rvalue? If I overload
operator& to return this in a class type, even something like:

A* pa = &f() ;

becomes legal. The distinction for class types is very, very
tenuous.

So if we define an rvalue as an intrinsically none-addressible
object 'this' can be considered a const rvalue which
exceptionally,

The point of my initial posting is precisely that this is *not*
const, because top-level const doesn't apply to rvalues of
non-class type.

does not initialize any kind of reference.

You can use this to initialize a reference:

class DontDoThisEvenIfItIsLegal
{
public:
void f()
{
DontDoThisEvenIfItIsLegal* const& rp( this ) ;
} ;
} ;

is perfectly legal (albeit useless, and rather confusing).
Formally, it creates a temporary of type
DontDoThisEvenIfItIsLegal*, initializes it with this, and then
binds the reference to the temporary.

But that does not mean that 'this' is not 'const', because the
only source of none- modifiablity is constness.

Not really. The only source of non-modifiablity is what the
standard says isn't modifiable. In C, for example, string
literals are not const, but you still aren't allowed to modify
them.

Further more, do you mean that the following
does not compile?

class A{
void F(){
const A * const & c_to_cA_ptr_ref = this ;
};
};

Of course it does. You can use an rvalue to initialize a
reference to a const.

I try to fancy that 'this' is a compiler defined function but
it has inconsistent syntax and looks more like a C# read-only
property than anything else.

It's a keyword: an rvalue expression which has a specific type
and value in a given context. That's really all you can say
about it.

 

[terminator]

That's true for rvalues with built-in types (including this,
which always has a pointer type), but the issue becomes more
complicated for user defined (class) types.


You can do that today.

yesterday I could do this to:

A& ar=f();

so,today we are much more limited.

And what is the this pointer in g(), above, in your first
example, if not the address of an rvalue? If I overload
operator& to return this in a class type, even something like:

A* pa = &f() ;

becomes legal. The distinction for class types is very, very
tenuous.

I meant intrinsic addressing, not using a member to extract the
address from inside scope to global.

The point of my initial posting is precisely that this is *not*
const, because top-level const doesn't apply to rvalues of
non-class type.


You can use this to initialize a reference:

class DontDoThisEvenIfItIsLegal
{
public:
void f()
{
DontDoThisEvenIfItIsLegal* const& rp( this ) ;
} ;
} ;

is perfectly legal (albeit useless, and rather confusing).
Formally, it creates a temporary of type
DontDoThisEvenIfItIsLegal*, initializes it with this, and then
binds the reference to the temporary.


Not really. The only source of non-modifiablity is what the
standard says isn't modifiable. In C, for example, string
literals are not const, but you still aren't allowed to modify
them.


Of course it does. You can use an rvalue to initialize a
reference to a const.


It's a keyword: an rvalue expression which has a specific type
and value in a given context. That's really all you can say
about it.

I know.But I assume it to be an auto defined member.

Intuitively, you can think of an lvalue as an expression that
designates an object in memory, and an rvalue as an expression
that just has a value, without an underlying object. Thus, to
assign *to* something, you need an lvalue---since you have to
modify the object, it must exist somewhere. But you can assign
from an rvalue; all you need is the value. (This is
historically where the names come from: an lvalue was something
that could appear to the left of an assignment, whereas an
rvalue could only appear to the right.

general speaking 'const' objects can not appear to the left side of
assignment(except for some odd classes that do define it on const
objects).should we consider every const an rvalue then?

But that is a radical
oversimplification in today's language.) Roughly speaking, if
the expression has an address, and would have one even if it
were of a primitive type, then it is an lvalue.

rvalues used to be either literals or function return values in C. But
you mean that since the declaration of C++ 'this' has formed a single-
membered categury of rvalues. That looks odd to me ,I can fancy 'this'
as a pointer-return member function that results in an rvalue but that
is not consistent with function call syntax in C++.


Finally, I should ask if there is any practical distinction between R
& L in C++ today?

regards,
FM.

 

[James Kanze]

yesterday I could do this to:

A& ar=f();

If by yesterday, you mean roughly 20 years ago, yes. This was
banned somewhere around the time CFront 2.0 was released, I
think (before I started using C++, at any rate), because
experience showed it to be far too error prone.

The circumstances have changed significantly since then. If it
were a question of banning it today, it wouldn't stand a chance
of passing, because it would break existing code. Back in the
late 1980's, however, there was a lot less existing C++ code,
and it was more or less understood that the language was still
evolving---there wasn't an ISO standard, or even a committee to
create one.

so,today we are much more limited.

Yeh. There's a large category of errors we cannot make.
(Seriously, there are times when the rule is limiting, as well
as times when it saves you. But it's certainly not a new rule,
and it's hard to imagine anyone today having to deal with code
which was written before it existed.)

I meant intrinsic addressing, not using a member to extract the
address from inside scope to global.

I was addressing the more fundamental issue. For built-in
types, and lvalue *must* have an address; an rvalue typically
doesn't. (It will be in a register, or embedded in an
instruction.) For class types, at least class types with member
functions, even an rvalue must have an address (at least until
the "as if" rule kicks in). The distinction between lvalue and
rvalue is much more tenuous, or at least, harder to associate
with some more fundamental characteristic.

[...]

I know. But I assume it to be an auto defined member.

You assume wrong. It's a keyword, which designates an
expression. In many ways, it's more like a literal, e.g. 42, or
3.14159, except that it's value depends on context.

That's according to the standard, of course. As I said when I
brought the point up, it's really a nit. If you want to think
of it as a predefined, preinitialized local variable (not a
member), I don't think that that's a big problem, as long as you
consider it const. The effect would probably be about the same.
But that's not the way the standard defines it.

general speaking 'const' objects can not appear to the left side of
assignment(except for some odd classes that do define it on const
objects).should we consider every const an rvalue then?

I said "historically". As far as I know, the term lvalue was
first used by Kernighan and Richie, and that's the justification
they gave for its name. At the time, of course, there was no
const. But the & operator also required an lvalue. That's why
I put the comment in parentheses, and added:

rvalues used to be either literals or function return values
in C.

Not only. Something like "&a" or "(double)i" is also an
rvalue, even though there is no literal nor any function in the
expression.

But you mean that since the declaration of C++ 'this'
has formed a single-membered categury of rvalues.

No. Even in C, each expression is defined as resulting in
either an lvalue or not an lvalue (an rvalue). There are no
"categories". In both standards, unless an expression is
explicitely stated to result in an lvalue, it results in an
rvalue. Thus, in the C standard, we have "An identifier is a
primary expression, provided it has been declared as designating
an object (in which case it is an lvalue) or a function (in
which case it is a function designator)." And nothing in §6.5.4
(Cast Operators) which says that the results are an lvalue, so
they are an rvalue.

And in the C++ standard, we have "The keyword this [...]. The
expression is an rvalue." In the section concerning primary
expressions; there is no legal use of "this" outside of an
expression.

That looks odd to me ,I can fancy 'this' as a pointer-return
member function that results in an rvalue but that is not
consistent with function call syntax in C++.

Finally, I should ask if there is any practical distinction
between R & L in C++ today?

Practically: for built-in types, yes. For class types, it
mainly affects whether you can bind to a non-const reference or
not. Formally: it plays a role anytime built-in operators are
used (but that's rarely the case for class types, since most
built-in operators don't apply to them).