ngo@tammy.harvard.edu (Tom Ngo) (02/20/91)
Background information to this posting was in a very recent summary.
Explicit removal of the const attribute from a variable originally
declared const was generally looked at as a necessary evil. Nobody
thought such casts should be disallowed, because of existing code that
would be broken. Also, there may be applications of cast-from-const
that would not be served by the ~const proposal as it presently
stands. I would be interested in hearing of such applications.
Jim Adcock <jimad@microsoft.UUCP> gave the most precise opinion of
what should happen to cast-from-const. I agree with it in every
detail, so I will attempt to summarize in the remainder of this
message.
There is a difference between "supporting" a feature and merely
"enabling" it. Cast-from-const enables the use of member variables
for caching purposes, but does not support it. ~const would permit
supporting such constructs in an implementation-independent manner.
Jim would make cast-from-const a "deprecated, strictly
implementation-dependent construct", allowed but subject to compiler
warnings. He proposed a change to the ARM, which I have further
edited slightly:
ARM 5.4, ear the end of the section [regarding cast-from-const]:
A pointer [or reference] to an object of a const type can be cast
into a pointer [or reference] to an object of non-const type....
The result of attempting to modify that object through such a
pointer or reference is strictly implementation dependent.
Possible results include acting as if the object had originally
been declared non-const, or causing an addressing exception or
other undesired behavior.
Deprecating cast-from-const in this way would permit compilers to do
meaningful optimizations on const member functions invoked on const
parts of const objects.
Finally, a change to the conditions for placing an object in readonly
memory. Again, I've made slight changes to Jim's changes...
ARM 7.1.6:
A const object of a type that does not have a constructor or a
destructor might be placed in readonly memory. The const parts of
any object that does have a constructor might be placed in
DISCARDABLE [write-once] memory unless the class contains any
~const member function. Discardable memory is virtual memory that
is paged to disk only the first time it is faulted out after
construction. Thereafter, the effect of any write operation to
any const part of any such object is undefined.
--
Tom Ngo
ngo@harvard.harvard.edu
617/495-1768 lab number, leave message