Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!swrinde!ucsd!pacbell.com!att!cbnews!cbnewsm!gregk
From: gregk@cbnewsm.att.com (gregory.p.kochanski)
Newsgroups: comp.lang.c++
Subject: Re: const is not object-oriented
Summary: better than const?
Message-ID: <1990Nov15.032726.7757@cbnewsm.att.com>
Date: 15 Nov 90 03:27:26 GMT
References: <1990Nov9.181408.23110@odin.corp.sgi.com> <BILL.90Nov14133604@hcx2.ssd.csd.harris.com>
Distribution: usa
Organization: AT&T Bell Laboratories
Lines: 59

In article <1990Nov12.184240.23430@odin.corp.sgi.com> linton@sgi.com (Mark Linton) writes:
> 
>    It seems clear that const doesn't provide the semantics that many programmers
>    (including me) want.

Here's a possible extension of 'const' which is powerful, not too klugey,
but perhaps a bit too far off to get into ANSI C++:

Const can be split into a storage-description intent:
const int x = 3;

and a intent to describe the interface to a function:
int foo(const int& x, int& y).

First, seperate these meanings.  Use 'const' for the first, and replace
the second meaning with 'condensed function prototypes' (like condensed
soup or condensed books).  In the above simple case, you could
write:
prototype int foo(int& x, int& y) {y=0;}

Which would be shorthand for the fact that foo() modifies 'y', but not 'x'.
Big deal, so you say.  Well, so would I, but in more complex cases, it
works really nicely.  Take the recent discussions on cacheing:

class array_with_cached_sum	{
	double *data;
	double sum_cache;
	public:
	double sum() { ...... }
	};

Here we have a class that is hard to add-up, so we store a sum.
Now, array_with_cached_sum::sum() is declared as follows:
prototype double sum() {sum_cache=0;} // It doesn't change the data...

Functions which just look at the array are declared like this:
prototype double lookie_here(array_with_cached_sum& a) {;} // change nothing

// Only calls sum() on the data.
prototype double lookie_sum(array_with_cached_sum& a) {a.sum();}

And, a function that modifies the data could be
prototype double changit(array_with_cached_sum& a) {*a.data=0;}

or, just
prototype double changall(array_with_cached_sum& a) {a=0;}

So, now compilers have all necessary information to optimize to
their heart's content, users can specify functions that change
only part of an object.
Best of all, if we have a linked list of pointers to objects,
we can now distinguish between
* functions that just look at the list,
* functions that change objects without adding or removing any,
* functions that add or subtract objects from the list, but don't 
	change the objects, and
* functions that do everything imaginable to the list.

Greg Kochanski