Path: utzoo!mnetor!tmsoft!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!snorkelwacker.mit.edu!hsdndev!husc6!ngo From: ngo@tammy.harvard.edu (Tom Ngo) Newsgroups: comp.std.c++ Subject: Responses to ~const 1.6: Fate of cast-from-const Message-ID: Date: 19 Feb 91 16:35:19 GMT Sender: news@husc6.harvard.edu Distribution: comp Organization: Harvard Chemistry Department Lines: 56 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 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