Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!umich!umeecs!msi-s0.msi.umn.edu!cs.umn.edu!ux.acs!hopper From: hopper@ux.acs.umn.edu (hopper) Newsgroups: comp.std.c++ Subject: Re: casting "const" to "non-const" Message-ID: <1920@ux.acs.umn.edu> Date: 31 Jul 90 22:39:12 GMT References: <56159@microsoft.UUCP> <56163@microsoft.UUCP> <1913@ux.acs.umn.edu> <1990Jul31.161942.1938@eagle.lerc.nasa.gov> Reply-To: hopper@ux.acs.umn.edu (Eric Hopper) Organization: Omnifarious Software Lines: 33 In article <1990Jul31.161942.1938@eagle.lerc.nasa.gov> fsset@bach.UUCP (Scott E. Townsend) writes: >In article <1913@ux.acs.umn.edu> hopper@ux.acs.umn.edu (Nils McCarthy) writes: >>In article <56163@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes: >>>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. >>> . . . >> 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 > >I disagree with the statement "In C ... a cast is always supposed to work.." >In fact, it does not always work, although you are always allowed to try >without the compiler getting too upset. For instance, casting a pointer Small terminology mistake. I meant that it was always supposed to compile, NOT always supposed to work. Sorry 'bout that, UUCP: rutgers!umn-cs!ux.acs.umn.edu!hopper (Eric Hopper) __ /) /**********************/ / ') // * I went insane to * / / ______ ____ o // __. __ o ____. . _ * preserve my sanity * (__/ / / / <_/ / <_<__//__(_/|_/ (_<_(_) (_/_/_)_ * for later. * Internet: /> * -- Ford Prefect * hopper@ux.acs.umn.edu /**********************/