Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!samsung!uunet!cimshop!davidm From: cimshop!davidm@uunet.UU.NET (David S. Masterson) Newsgroups: comp.std.c++ Subject: Re: 'const' revisited Message-ID: Date: 14 Aug 90 21:19:16 GMT References: <26909@pasteur.Berkeley.EDU> <56514@microsoft.UUCP> Sender: davidm@cimshop.UUCP Organization: Consilium Inc., Mountain View, California. Lines: 30 In-reply-to: jimad@microsoft.UUCP's message of 13 Aug 90 18:11:41 GMT 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!"