🚀 go-pugleaf

The meaning of const has been discussed quite a bit around here.  I
used the term "bit-wise const" to mean that the storage may not be
changed, and "meaning-wise const" otherwise.  It is clear that both
interpretations of const are meaningful and useful, and that neither
subsumes the other.  The higher-level abstractions that C++ was
particularly designed to support require the meaning-wise
interpretation of const, but effective use of read-only memory (which
has traditionally been an important issue at AT&T) requires the
bit-wise interpretation.

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).

On a separate topic, I have heard there is some confusion about
Sh[ao]piro.  Jonathan Shapiro (shap@sgi.com) is a friend of mine and a
C++ expert (so we usually agree), but he is not me.
-- 
		Jonathan Shopiro
		AT&T Bell Laboratories, Warren, NJ  07060-0908
		research!shopiro   (201) 580-4229