Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!wuarchive!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.std.c++
Subject: Re: 'const' revisited
Keywords: const access restrictions
Message-ID: <56734@microsoft.UUCP>
Date: 20 Aug 90 17:12:16 GMT
References: <56514@microsoft.UUCP> <1990Aug14.125734.28015@cbnewsm.att.com> <56586@microsoft.UUCP> <2648@dataio.Data-IO.COM>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Distribution: usa
Organization: Microsoft Corp., Redmond WA
Lines: 69

In article <2648@dataio.Data-IO.COM> bright@Data-IO.COM (Walter Bright) writes:
|In article <56586@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
|<4) Leave things the way they are now -- a muddle where people cast away from
|<const, leading either to compilers that can't optimize on const, or compilers
|<that do optimize on const, with "quasi-const" routines that break the
|<caller's code.
|
|This is the best solution. There are cases where the user needs to cast
|away from const, even though he never changes the contents (such as in
|interfacing to an existing library which doesn't use pointers to const).
|

[memchr example]

|(Note that, in ANSI C, you can use functions like memchr() to get rid
|of the 'constness' of a pointer even if you disallowed the cast!
|Therefore, disallowing the cast would require 2 versions of memchr(), one
|for const void* and the other for void*, yeech. The ripples of this
|problem go on and on...)

Why?  Why is this not exactly the solution people should be using --
Make a const and a non-const version of a routine, and thus avoid the
const-hacking?  Why allow the memchr code you suggest when, at best,
its non-portable?

Note:  In an optimizing compiler its easy to imagine 
situations where the memchr example is going to bust caller code --
even if memchr *doesn't* change the value of the thing cast from const.
Again, the problem is that calling a routine that violates its const'ness
contract changes the optimization that can be performed in the caller's
environment -- but in the face of separate compilation there's no way
for the compiler to know that!

|Casting a void* to a const void* requires an explicit cast, and so the user
|is presumed to know what he's doing (just like in the rest of C).

Even though what s/he's doing is potentially busting someone else's code
that uses this separately compiled module?  The problem is it's the
calling sequence that gets busted when const'ness is violated -- not
the called code!

|The optimizer can presume that the contents of non-volatile const
|variables do not change. If a user, by playing tricks, changes the variable,
|he loses. This is similar to the case:
|
|	int a,b,*p;
|
|	b = 4;
|	p = &a;
|	c = b * 3;
|	p[1] = 5;		/* changes b! */
|	d = b * 3;		/* 12 is stored in d by an optimizing compiler,
|				   15 by a non-optimizing one, though both
|				   compilers are ANSI conforming.	*/


I don't think the examples are very similar.  In the case given here,
a programmer busts his/her own code.  In the cast from const case, a 
programmer [potentially] busts someone else's code.  And it might
be a long time for that bug to show up in a definative manner.  Chances are,
programmer's would instead blame the compiler.  And then compiler writers
will pessimize, rather than optimize, on const.  This to me is the bottom
line.  If compiler's cannot trust a function's const-ness on a contractual
basis, compiler writer's will not create compilers that optimize on a 
function's const'ness.

So again, in the particular case where a cast from const violates a 
functions implied contract, I think it deserves an error message,
not a warning.