Path: utzoo!attcan!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.std.c++
Subject: Re: 'const' revisited
Keywords: const access restrictions
Message-ID: <56741@microsoft.UUCP>
Date: 20 Aug 90 17:53:34 GMT
References: <26909@pasteur.Berkeley.EDU| <11194@alice.UUCP>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 24

In article <11194@alice.UUCP> shopiro@alice.UUCP (Jonathan Shopiro) writes:
|
|Our compromise partitions the set of types.  Meaning-wise const types
|are those with constructors or destructors or arrays of these.  (Note
|that a type with a member or base that has a constructor or destructor
|automatically has one).  The rest are bit-wise const.  An implementation
|may not put a const instance of a meaning-wise const type into
|read-only memory, and a programmer may cast const aside from a pointer
|to a meaning-wise type and be assured that the program will work as if
|the pointer and its referent had never been declared const in the
|first place.  E&S says only that const instances of bit-wise const
|types may be put into read-only memory, but I think it would be
|reasonable for X3J16 to extend this interpretation so that an
|implementation would be allowed to assume that a const pointer to a
|bitwise const type points to memory that will not change.  (Const
|volatile would tell the implementation not to make this assumption).

Such an interpretation prevents the enregistering of members across a 
"const" member function.  This puts C++ at a competitive disadvantage
to other OOPLs that maintain function calls on a contractual basis.
Eventually C++ would become know as "that slow OOPL", not "that fast OOPL."
I think this would be a mistake.  Const should mean const.  Casts from
const should be at best implementation defined when they violate a
function's implied contract.