Xref: utzoo comp.lang.c++:10335 comp.std.c++:417
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!mips!sgi!shinobu!odin!sgihub!dragon!xanadu.wpd.sgi.com!pal
From: pal@xanadu.wpd.sgi.com (Anil Pal)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: Re: const is not object-oriented
Message-ID: <1990Nov12.204557.13169@relay.wpd.sgi.com>
Date: 12 Nov 90 20:45:57 GMT
References: <1990Nov9.181408.23110@odin.corp.sgi.com> <13050@cadillac.CAD.MCC.COM> <1990Nov12.184240.23430@odin.corp.sgi.com>
Sender: news@relay.wpd.sgi.com ( CNews Account )
Reply-To: pal@sgi.com
Organization: Silicon Graphics, Inc.
Lines: 41

In article <1990Nov12.184240.23430@odin.corp.sgi.com>, linton@sgi.com (Mark Linton) writes:

|> If a compiler puts a static life-time const in read-only storage and
|> you use a cast to write into that storage, you'll get a memory fault
|> (speaking from experience here).

Page 109 of E&S states [emphasis added] that 

    "A const object of a type that *does not* have a constructor or a
    destructor may be placed in readonly memory" [...]

    "This implies that most const objects of C++ style class types may
    *not* be placed in readonly memory" [...]

    "The purpose of this distinction is to allow the use of readonly
    memory for large tables, while still enabling "constness" for class
    objects to be defined by the programmer through the definition of
    const member functions"

From this, I infer that the intent of "const" is for it to be semantic
and programmer defined.  The storage notion of const is therefore an
compiler feature, intended to prevent accidental update.  From the
language standpoint, therefore, const already has the semantics you
(and I, and others) want.

The issue then becomes what the compiler should do.

It appears impractical for the compiler to implement the programmer's
notion of const (how is this notion communicated?).  This leaves the
alternatives of doing nothing, or implementing the storage notion of
const, which the programmer can circumvent as necessary.  Are there
other alternatives?

I contend that the cases where storage const is overly restrictive are
few and can be well isolated, making them suitable candidates for
explicit casts.  I definitely prefer this situation to the alternative
where the compiler essentially punts on const enforcement.

-- 
Anil A. Pal,	Silicon Graphics, Inc.
pal@sgi.com	(415)-335-7279