operator! and lvalue

operator! and lvalue

[Shriramana Sharma]

In Thinking in C++ chapter on overloading operators, Bruce Eckel gives
the following code:

For a non-member operator:

int operator!(const Integer& a) {
   cout << "!Integer\n";
   return !a.i;
}

For a member operator:

Byte operator!() const {
   cout << "!Byte\n";
   return Byte(!b);
}

My question is: why is there no "const" before Integer and Byte at the
head of the function? There's all that stuff about when temporaries are
returned they are automatically const, but throughout the examples in
this chapter, only operator! is not explicitly specified to have a const
return value whereas in all other relevant cases we have the "const"
specified explicitly.

Shriramana Sharma.

Re: operator! and lvalue

[Glynn Clements]

Shriramana Sharma wrote:

> In Thinking in C++ chapter on overloading operators, Bruce Eckel gives
> the following code:
> 
> For a non-member operator:
> 
> int operator!(const Integer& a) {
>    cout << "!Integer\n";
>    return !a.i;
> }
> 
> For a member operator:
> 
> Byte operator!() const {
>    cout << "!Byte\n";
>    return Byte(!b);
> }
> 
> My question is: why is there no "const" before Integer and Byte at the
> head of the function?

Huh? The only "Integer" which isn't preceded by "const" is in the
string literal.

> There's all that stuff about when temporaries are
> returned they are automatically const, but throughout the examples in
> this chapter, only operator! is not explicitly specified to have a const
> return value whereas in all other relevant cases we have the "const"
> specified explicitly.

Why would you want to make the return value "const"?

The situation is different if you're referring a reference or pointer,
but there's no point in making a copied value "const".

BTW, this list is specifically about C programming on Linux; generic
C/C++ questions aren't really on-topic here. The comp.lang.c and
comp.lang.c++ newsgroups (and their *.moderated counterparts) might be
better places to ask such questions; certainly, they are likely to
have many more active users.

-- 
Glynn Clements <glynn@gclements.plus.com>