Path: utzoo!attcan!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.std.c++
Subject: Re: 'const' revisited
Keywords: const access restrictions
Message-ID: <56514@microsoft.UUCP>
Date: 13 Aug 90 18:11:41 GMT
References: <26909@pasteur.Berkeley.EDU>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 57

I think the idea of using 'volatile' with 'const' to help resolve some
of const's multiple meanings is a good idea -- but I'm not sure the 
other suggestions follow.  One problem I see is that there are [at least]
two reasonable interpretations that one can put on 'volative' + 'const'

1) A read-only access permission to something that can be changing.  A
read-only access permission to a clock register, for example.  One might
not want to grant read/write permission to such a register because then
anyone can change the time.

2) A statement that the internals of an object might change, but from the
public interface to the object, the object looks unchanged.  An example 
would be a routine that modifies cached values in an object, such that those
values can be accessed faster in the future, but otherwise the state of
the object appears unchanged from the outside world.  This is the traditional
case where people want to cast away from const in a routine whose parameters
are declared const.

One possibility is to overload the meaning of 'const' + 'volatile' depending
on the order of the two:

const volatile vs
volatile const

I think this word ordering is enough hair splitting to cause people a 
lot of trouble remembering, but yet I am loath to introduce yet-another key
word.  So I have mixed feelings about this.  Restating, and expanding the
original matrix, I get:

A) volatile const.  An object that appears const to the outside world that
may be changed internally.  An example might be an object that caches certain
values for faster access in the future.

B) const.  A strictly read-only object that doesn't change.

C) volatile.  A read/write object that may change 'of its own accord.'  
This could include changes made via non-portable coding hacks.
A compiler shouldn't apply optimizations that assume the object is going 
to stay the same.

D) none.  A read/write object that the compiler can apply reasonable optimi-
zations to.  The object doesn't change except via legitimate accesses
within the language.  A compiler can assume that non-portable coding hacks
are not being used.

E) const volatile.  Read-only permissions to an object that may be changing
of its own accord.  A example might be a clock register to which write 
permissions need to be denied, because people shouldn't be allowed to change
the time.  Compilers can't optimize.

"Safe" conversions that could be applied implicitly are:

D to B, C, E, A
B to E
C to A, E
A to C, E
E to none-of-the-above