Xref: utzoo comp.lang.c++:10289 comp.std.c++:402
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!decwrl!sgi!shinobu!odin!sgi.com!linton
From: linton@sgi.com (Mark Linton)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: const is not object-oriented
Message-ID: <1990Nov9.181408.23110@odin.corp.sgi.com>
Date: 9 Nov 90 18:14:08 GMT
Sender: news@odin.corp.sgi.com (Net News)
Reply-To: linton@sgi.com (Mark Linton)
Organization: sgi
Lines: 78

The "const" keyword in C++ specifies a property of storage, and
as such is not particularly useful in an object-oriented program.
Declaring a parameter or a member function as const requires
knowledge about the implementation of a class.  Consider
a class IntVector with a member function sum:

    class IntVector {
    public:
	IntVector(unsigned int size);
	~IntVector();

	int get(unsigned int i);	// return element i
	void set(unsigned int i, int v);// set element i to v
	int sum();
    private:
	int* data;
	unsigned nelements;
    }

The function "sum" is to return the add up all the elements in
the vector.  One might think it would be natural to define sum as
a const member function, which would allow a call to sum
on a const IntVector object (such as a const IntVector parameter).
After all, computing the sum of the elements of a vectors
doesn't "change" the vector.  Suppose, however, that sum will be
called many times before the vector is modified.  Because you know
the vector is only modified by set, you could add two members
to the private section:

    int current_sum;
    boolean sum_is_valid;

The set member function would set sum_is_valid to false, and sum
would check the flag to determine whether it needs to compute the sum
or simply use the previously computed value.

If you implement this caching strategy, you can no longer make sum
a const member function!  The great irony is that you could define
set as a const member function because it modifies data pointed at
by the vector object, not the vector's own structure.

So, I claim that const is a pretty useless concept in class interfaces
because it depends on the class implementation.  I can see the use
of const for concrete types (const char*), or perhaps in very special
cases for optimization (like for helping a vectorizing compiler
handle a parallel program).

There is one place where the notion of consts confuses compiler writers.
Cfront, for example, generates a warning if you pass a temporary
to a non-const ref parameter.  For example,

    class A {
    public:
	A(int);

	int f(A&);
    };

    A* a;

    a->f(A(4));

This call will generate a warning from cfront.  I believe this warning
is out-right wrong because it will confuse programmers into believing that
they should change the declaration of f to "int f(const A&)".  However,
if the function f is implemented using caching, they can't do it.
So the code must be split up:

    A tmp(4);
    a->f(tmp);


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.