Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!m2.csc.ti.com!bmk
From: bmk@m2.csc.ti.com (Brian M Kennedy)
Newsgroups: comp.lang.c++
Subject: Re: Help needed in c++ (const-ness)
Message-ID: <1991Jun24.151911.1651@csc.ti.com>
Date: 24 Jun 91 15:19:11 GMT
Sender: bmk@csc.ti.com (Brian M Kennedy)
Organization: TI Computer Science Center, Dallas
Lines: 104

>>>=marina=>
>>>Does anybody know the meaning of this const postfix ??

>>=mattel=>
>> The const postfix notation indicates that the method (f) does NOT modify the
>> object for which it is messaged (this).
>>
>> What do other people think of using this notation?  Is it useful?

>=markr=>
>I have one small gripe about the const postfix.
>[...example deleted...]
>What I am trying to say is, I would prefer the const postfix to mean that the
>programmer doesn't mind that function being called on a const object, rather
>than meaning that no members may be changed by that function.  This would
>seem to me to make more sense since the notion of a constant object is not as
>simple as the notion of a constant integer or float.  An object is, after all,
>an abstraction over finer-grained data inside, so shouldn't the notion of what
>makes an object constant/nonconstant also be abstracted?

>Protecting the bit pattern of a const object's allocated space is IMHO
>over-protective.

=bmk=>
For a class with a user-defined constructor or destructor, the const postfix
does mean what you want it to, Mark.  For such a class, the const postfix 
implies that the member function can be freely called on a const object of 
that class.  Within the member function you are guaranteed that you can cast
away the const-ness and it will behave as if it was never const.  Requiring
such casts may be overprotective, but it is much better than not providing
any protection.  The compiler cannot infer the "meaning" of a class to enforce
meaningwise const-ness, so it simply enforces bitwise const-ness and provides
a mechanism for you to override it.  For a large number of cases bitwise
const-ness and meaningwise const-ness are the same thing.


>=markr=>
>But if I declare
>operator->() as a const member function, it cannot assign to "address"

=bmk=>
Yes, you can:

	((smartPtr*)this)->address = ...;

This is guaranteed to work if class smartPtr has a user-defined constructor
or destructor.


>=benson=>
>You can argue till the cows come home as to whether this is
>"legitimate." The argument in favor is that the private contents of an
>object are no one's business but the object's, and if it chooses to
>modify them in a "const" method that's its business. The anti-
>argument is that const on a member function is a statement about
>storage integrity -- a const object, in this theory, can be stored in
>a ROM.

=bmk=>
There is no argument -- it is well-defined (though not necessarily well-
described in many of the texts; see the end of this note for a reference).
If the class has a user-defined constructor or destructor,
then it is legal.  Const objects of such classes are "meaningwise const".
If the class has no user-defined constructors or destructor,
then it is illegal.  Const objects of such classes are "bitwise const"
and may be placed in ROM.


>=benson=>
>In the real world, do the following. Decide which of the positions to
>believe.

=bmk=>
No, decide which kind of const-ness you want for your class.  If you want
meaningwise const-ness, then define at least one constructor or destructor
for it.  Then you may cast-away-const at will and you are guaranteed that
it will behave as if the object was never const.


Now to return to this question:

>>=mattel=>
>> What do other people think of using this notation?  Is it useful?

=bmk=>
It is a *necessary* part of programming in C++.
If you are defining abstract types, then you must use this notation to 
describe which operations can be invoked on const objects of that type.
If you do not use this notation then you essentially disallow the use
of const objects of that type, and in effect toss one of the best features
of C++ -- strong typing.  I consider any code that does not use const where
appropriate to be broken.

REFERENCE
One final note to those that are confused or surprised by the above discussion:
I highly recommend reading the pair of articles by Jonathan Shopiro that 
appeared in Feb 1991 and Mar/Apr 1991 issues of JOOP (J. Object-Oriented
Programming) titled "The semantics of const" -- but most importantly, the
second part.

== Brian M. Kennedy <bmk@csc.ti.com> ==
== Computer Systems Laboratory ========
== Computer Science Center ============
== Texas Instruments ==================