Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!wuarchive!usc!rutgers!att!cbnewsm!gregk
From: gregk@cbnewsm.att.com (gregory.p.kochanski)
Newsgroups: comp.std.c++
Subject: Re: 'const' revisited
Summary: const volatile vs. volatile const.  Why not use binary?
Keywords: const access restrictions
Message-ID: <1990Aug14.125734.28015@cbnewsm.att.com>
Date: 14 Aug 90 12:57:34 GMT
References: <26909@pasteur.Berkeley.EDU> <56514@microsoft.UUCP>
Distribution: usa
Organization: AT&T Bell Laboratories
Lines: 37

AARGH!
One might as well use const(1) const(2) const(3) ... rather than
trying to express these things in terms of non-intuitive ordering
of const and volatile.  Unless the syntax is memorable, it will not be
used or used correctly.   There is such a thing as being excessively
parsimonius with keywords.

One can take this discussion further.  Imagine an object that contains
a pointer to some data (e.g. an array class):

class array	{
	double *data;
	...
	};
Now, we can distinguish (if we really want to) even more cases:
1) the array object is constant, and so is the data
2) the array object is constant, but the data could be changed
3)....
n+1) this function promises not to change the data, but it might
	change the array object
n+2) this function promises not to change the array object or the data
m+1) this function promises not to even think about changing anything
	which might, in the future, be used to calculate future values which
	might be placed in the data of this array object.

One can make this an arbitrarily complex situation by considering an
item which can reside on a linked list:
class ll	{
	ll *next;
	...
	};
Now, you can promise not to modify
this object, or the one it points to, or the next one,
but I might just modify the one after that.

To encode things like that is silly:
const volatile const const volatile const const const volatile ll(2);