🚀 go-pugleaf

In article <56514@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:

   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.

   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.

Might this not be more easily accomplished by public/private interfaces?  In
the private interface of the object, the value is defined as volatile (or
'none').  However, the public interface would have a function that returns a
'const pointer*' to the private member data.

Also, 'volatile' and 'const' seem to differ on the key point of compiler
optimizations (the first can't be, but the second one can be).  Doesn't the
(A) and (E) definitions hurt the 'const'ness of the object from the
compilation standpoint, so making the previous paragraph a more 'desirable
mode of operation?

I am one that believes 'const' should be constant and enforced as such by the
compiler.  Casting is not a valid trick for getting around this.
--
====================================================================
David Masterson					Consilium, Inc.
uunet!cimshop!davidm				Mtn. View, CA  94043
====================================================================
"If someone thinks they know what I said, then I didn't say it!"