Xref: utzoo comp.lang.c++:10362 comp.std.c++:423 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!mintaka!think.com!samsung!uakari.primate.wisc.edu!uflorida!travis!bill From: bill@ssd.csd.harris.com (Bill Leonard) Newsgroups: comp.lang.c++,comp.std.c++ Subject: Re: const is not object-oriented Message-ID: Date: 14 Nov 90 18:36:04 GMT References: <1990Nov9.181408.23110@odin.corp.sgi.com> <13050@cadillac.CAD.MCC.COM> <1990Nov12.184240.23430@odin.corp.sgi.com> Sender: news@travis.csd.harris.com Followup-To: comp.lang.c++ Organization: Harris Computer Systems Division Lines: 64 In-reply-to: linton@sgi.com's message of 12 Nov 90 18:42:40 GMT In article <1990Nov12.184240.23430@odin.corp.sgi.com> linton@sgi.com (Mark Linton) writes: It seems clear that const doesn't provide the semantics that many programmers (including me) want. We can (1) continue to abuse its meaning as many are already, using casts to circumvent compiler attempts to enforce the meaning (2) change the meaning of const to remove the storage semantics (3) find another way to do what we want Being rather new to C++, I feel I haven't quite understood all the discussion about "const". However, as a compiler writer, I definitely sense something missing. The discussion appears to have focused on two aspects of "const": 1) Whether const objects are placed in some particular type of storage (like ROM); 2) Whether the compiler should "enforce" the prohibition against updates that const implies. Much of the arguments have been about whether "casting away const" achieves the desired behavior, but ignored in all this has been the compiler's freedom to optimize in the presence of const. Let's take an example. Suppose procedure "foo" is declared: int foo (const int * a) ; and suppose the following code: int x, y ; x = 1 ; foo (&x) ; y = x + 1 ; Since foo has claimed that it does not modify the storage pointed to by its parameter, the compiler is free (I believe) to substitute the value 1 for x in the assignment to y. If foo "casts away" this const-ness and modifies the storage anyway, you will get unexpected behavior. Perhaps I don't properly understand the C++ specification (yes, I know it's not a standard yet), but I am pretty sure this is the ANSI C model. Casting away const could really be dangerous and unpredictable if you are using an optimizing compiler (and why would you want to use anything else? :-). _I_ certainly would never use a cast to non-const unless I knew exactly what the compiler was going to do with it (which, of course, makes my code non-portable). I strongly support the notion of const, especially this interpretation of freedom to optimize. As a programmer, I want to give the compiler every opportunity to optimize my program. As a compiler writer, I want to discourage people from subverting this goal, because the non-portable aspects of it can go unnoticed for years. -- Bill Leonard Harris Computer Systems Division 2101 W. Cypress Creek Road Fort Lauderdale, FL 33309 bill@ssd.csd.harris.com --------------------------------------------------------------------------- "You may have the reins in your hands, but the wagon only goes when the horses do." ---------------------------------------------------------------------------