Path: utzoo!attcan!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.std.c++
Subject: casting "const" to "non-const"
Message-ID: <56163@microsoft.UUCP>
Date: 30 Jul 90 18:17:52 GMT
References: <56159@microsoft.UUCP>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 27

Proposed:

That when a parameter [including the hidden "this" parameter] is declared 
"const", or when the object referenced by a parameter is declared "const",
than it is not legal to modify that which is declared "const" within the 
function. This is to say, the trick of casting to a non-const does not 
work on a parameter declared as "const."  Compilers can flag as an error 
these situations.

The reason I propose this restriction on the casting trick is to allow 
compilers to correctly optimize code when presented with independently
compiled libraries.  To be able to correctly optimize, compilers need to
be able to assume that "const means const" in those libraries.

The counter-position is that "const" means that an object appears unchanged
from the outside, but individual members of the object may be changed
[such as cached values.]  However, an optimizing compiler can enregister
one or more of those "const" values, such a hybrid, inconsistent object
results when the "const"-ness of a function is not correctly stated.
Thus if the counter-position is adopted, members of a object
cannot reasonably be enregistered across "const" functions.  Also, the 
possibility of placing "const" objects in read-only or write-once memory
is eliminated.

Let's let "const mean const" and deprecate the cast to non-const trick.

[disclaimer: the above represents the opinion of an individual C++ user]