From 5393147346125976256 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,f9d03435d36a70ff X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1990-08-15 13:51:36 PST Path: gmdzi!unido!mcsun!uunet!seismo!dimacs.rutgers.edu!rutgers!news-server.csri.toronto.edu!utgpu!watserv1!watmath!att!dptg!ulysses!andante!alice!shopiro From: shopiro@alice.UUCP (Jonathan Shopiro) Newsgroups: comp.std.c++ Subject: Re: 'const' revisited Summary: Supporting higher level abstractions requires a more liberal view of const. E&S 7.1.6 defines when const can be safely cast aside. Keywords: const access restrictions Message-ID: <11194@alice.UUCP> Date: 15 Aug 90 20:51:36 GMT References: <26909@pasteur.Berkeley.EDU> Organization: AT&T Bell Laboratories, Murray Hill NJ Lines: 34 Posted: Wed Aug 15 21:51:36 1990 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