Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!csc.ti.com!ti-csl!m2.csc.ti.com!bmk
From: bmk@m2.csc.ti.com (Brian M Kennedy)
Newsgroups: comp.std.c++
Subject: const is definitely object-oriented
Message-ID: <1990Nov15.181026.24113@csc.ti.com>
Date: 15 Nov 90 18:10:26 GMT
Sender: bmk@csc.ti.com (Brian M Kennedy)
Distribution: usa
Organization: TI Computer Science Center, Dallas
Lines: 53

I do not find any problem with the C++ definition of const.  It is fairly
simple and allows me the flexibility of defining what const means for new
types that I write.

For built-in types and structs/classes without user-defined constructors,
const means that the bit representation of the object doesn't change.  So,
a compiler can place such a const in ROM or compile it out of existence (ie.
hard-code it into immediates).

For new user-defined types, classes with user-defined constructors, const
means that the abstract object doesn't change.  The bit pattern may change.
Thus, the compiler cannot place such a const in ROM.  Furthermore, casting
away const-ness on such an object *is* well-defined and portable.

The compiler will enforce bitwise const-ness in const member functions of
user-defined types -- but that is just a programmer aid.  The programmer
simply responds "Yes, I know what I'm doing" by casting away the const-ness
of the this pointer.  Note that this is only valid for classes with user-
defined constructors or destructors.  Other classes are assumed to have
compiler-defined (i.e. bitwise) constness and may be in ROM.


MYTH: The "const" keyword in C++ specifies a property of storage, and
      as such is not particularly useful in an object-oriented program.

   The const keyword says nothing about storage for classes with user-
   defined constructors.  So, when you define a new object class, you
   have complete control over the meaning of const.  For built-in
   types, the bit representation *IS* the object.  So, saying a const int
   cannot change bit representation is just as object-oriented as saying
   a const int cannot change its abstract value.

MYTH: casting away const is non-portable

   This may be true for built-ins and classes without constructors,
   but is FALSE for classes with user-defined constructors.

MYTH: compilers are free to place const objects in ROM

   This may be true for built-ins and classes without constructors,
   but is FALSE for classes with user-defined constructors.

MYTH: cfront's behavior concerning const is the C++ definition of const

   cfront does *not* handle const correctly/understandably in 
   all cases.  Read Ellis & Stroustrup -- it describes const-ness
   rather clearly.

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