Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!jarthur!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.std.c++
Subject: Re: casting "const" to "non-const"
Message-ID: <56265@microsoft.UUCP>
Date: 2 Aug 90 20:22:22 GMT
References: <56159@microsoft.UUCP> <56163@microsoft.UUCP> <1913@ux.acs.umn.edu>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 50

In article <1913@ux.acs.umn.edu> hopper@ux.acs.umn.edu (Nils  McCarthy) writes:
>
>	I don't agree with the illegalization of this construct. I think it
>is against the spirit of the language to illegalize a cast.
>
>	In C, and C++ a cast is supposed to always work, no matter what
>object you're casting. I think that it should be legal for compilers to
>preform optimizations based on the information given by declaring a const
>parameter, but programmers should be allowed to cast if they feel it
>neccesary.

Okay, lets enumerate some choices about how compilers can choose to handle 
this problem.  I'm assuming that the language definition needs to be such
that the traditional separately compiled modules, standard linkers with
"type safety" via name mangling is used.

1) Never optimize when calling functions with const parameters.  [Pessimistic
approach]

2) A function with a const parameter which is cast to a non-const is flagged
with a error when it is compiled.

3) A function with a const parameter which is cast to a non-const is flagged
with a warning when it is compiled.

4) A function with a const parameter which is cast to a non-const is not
flagged when it is compiled, just silently accepted, leading potentially to
optimization errors when it is used.

---

I'd reject option #1 because I believe C++ code needs to be highly optimized
in order to get C-like performance.

I'd reject option #4 since compilers can then generate bad [erroneous] code
without giving the user any hint that anything is going on.

Option #3 has the "advantage" of letting people write functions that will 
work in some calling sequences, and fail in other calling sequences.  These
failures would be hard to track down, and impossible to fix -- other than
turning optimization off.

So I'd prefer to just see option #2.  Option #3 [warning] would be acceptible
in compilers that don't do much optimizations.  A compiler with a flag to
turn optimization on and off could switch the level from warning to error --
but this is a poor "solution" given that the "const" function can be compiled
with the optimization flag off, and the calling function can be compiled with
optimization on.

[standard disclaimer]