Xref: utzoo comp.lang.c++:10302 comp.std.c++:406
Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!apple!mips!sgi!shinobu!odin!sgihub!dragon!xanadu.wpd.sgi.com!pal
From: pal@xanadu.wpd.sgi.com (Anil Pal)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: Re: const is not object-oriented
Message-ID: <1990Nov9.210404.29139@relay.wpd.sgi.com>
Date: 9 Nov 90 21:04:04 GMT
References: <1990Nov9.181408.23110@odin.corp.sgi.com>
Sender: news@relay.wpd.sgi.com ( CNews Account )
Reply-To: pal@sgi.com
Organization: Silicon Graphics, Inc.
Lines: 89

In article <1990Nov9.181408.23110@odin.corp.sgi.com>, linton@sgi.com (Mark Linton) writes:
|> 
|> The "const" keyword in C++ specifies a property of storage, and
|> as such is not particularly useful in an object-oriented program.
|> 
|> [ example of caching result of expensive computation that does not affect
|>   object state ; this prevents member function being declared "const" ]
|> 
|> So, I claim that const is a pretty useless concept in class interfaces
|> because it depends on the class implementation.

I would disagree with the claim that const is useless in class
interface definition.  The distinction you note (between "logical"
constness and "bitwise" const) is a valid one, and has come up on this
group before.

My position is that use of const in an interface definition indicates
intent, i.e. the logical or behavioral const.  I contend that this
information is useful to users of the class.

Since the translator cannot, with current technology, enforce a purely
logical const it seems reasonable for it to enforce the more
restrictive bitwise const notion instead, since the class implementor
can circumvent this when necessary.

I will concede that this is a mismatch, but claim that the answer is
not to take const as a storage specifier and throw it away (thereby
losing the interface benefits it provides).

Rather, I would suggest that const be used in the behavioral sense to
specify interfaces, and, where necessary, the translator's more
restrictive notion of storage const can be circumvented in the
implementation.

|> 
|> Cfront, for example, generates a warning if you pass a temporary
|> to a non-const ref parameter.
|>     a->f(A(4));
|> I believe this warning is out-right wrong[...] [because]
|> if the function f is implemented using caching, they can't [ declare the
|> parameter const]

I assume you mean that the function f is implemented using calls to
member functions of the parameter that use caching, rather than that
the function caches values in a; in the latter case, there is no
problem with declaring the parameter const.

The restriction now is that the member functions invoked on the
parameter be declared const, even if they involve caching.  This is
possible, although it requires that the constness be circumvented
within the function.  I will concede that this can be ugly (const cast
away warnings and all that), but it could also be done indirectly (by
having a pointer to the cached value, for example).  In any case, I
contend that the constness of the reference parameter and the constness
of the member function are important parts of the interface definition,
and should be included.

There is, of course, some work involved here, but I believe it is
(appropriately) confined to the implementor of the class.

|> 
|> The bottom line is if you are defining a C++ class, especially
|> for a library, do not use const parameters or const member functions.
|> Const means storage, not behavior, so it is by definition
|> an implementation/representation concept.  If you are a compiler writer,
|> do not generate this bogus warning when a temporary is passed
|> to a non-const ref parameter.
|> 

Again, I have to disagree.  I believe that const should be used in
interfaces, in the behavioral sense.  The fact that the translator is
limited to treating it as a storage concept imposes an implementation
cost, but I contend that the benefits of having tightly specified
interfaces outweigh that cost.  This is particularly true for
libraries.  I have had lots of problems with libraries that do not
declare parameters const, because I am never sure whether I can safely
pass a constant (a string literal, for example), a computed temporary
expression, etc.

On my previous project, we moved a fairly large program (25K lines)
from C++ 1.2 to 2.0, and decided to tighten up the interfaces with
const.  It turned out to be a much larger underatking than we
anticipated, because of the very stringent restrictions that storage
const implies.  However, the result was definitely a much cleaner and
more understandable program.

-- 
Anil A. Pal,	Silicon Graphics, Inc.
pal@sgi.com	(415)-335-7279