Path: utzoo!attcan!uunet!fernwood!lia!jgro From: jgro@lia (Jeremy Grodberg) Newsgroups: comp.std.c++ Subject: Re: X3J16/90-0091 typos and comments Message-ID: <1990Nov13.222700.1194@lia> Date: 13 Nov 90 22:27:00 GMT References: <58861@microsoft.UUCP> Reply-To: jgro@lia.com (Jeremy Grodberg) Lines: 131 In article <58861@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes: > >TYPOS, COMMENTS, AND A QUICK REVIEW ON X3J16/90-0091 > >[The following are my opinions only] > >[...] >5-8 "A pointer to an object of const type can be cast into a pointer > to a non-const type....The result of attempting to modify that > object through such a pointer will either cause an addressing > exception or be the same as if the original pointer had referred > to a non-const object. It is implementation dependent whether > the addressing expection occurs. > > In my opinion, this section is oxy-moronic. A standard should not > sanctify two bipolar implementation choices that so differ that no > reasonable strictly-conforming program can make use of both > behaviors. Either ONE behavior for const objects should be > codified, or the entire issue should be left implementation > dependent. It is silly to insist that compilers accept cast- > from-const constructs, where that construct is just going to cause > a runtime error later, because on that machine consts are write- > protected. My recommendation is that the entire issue of cast > from const be implementation dependent. In particular, on > machines where consts go in read-only memory, compilers should > not allow cast from const. And highly-optimizing C++ compilers > may wish to prohibit cast-from-const to allow efficiencies by > making const-ness assumptions part of the function calling > protocol. [IE enregistered const parameters need not be reloaded > over function call boundaries.] I disagree strongly on this point. By specifying exactly 2 options for compiler writers, ANSI gives a needed degree of freedom while minimizing the difficulty for programmers. Under the proposal, people who want ultra-clean code will avoid casting away const, just as they will under Jim's proposal. However, under the ANSI proposal, programmers will be able to write portable code which takes advantage of casting away const and works portably across all machines that allow it (which I expect to be the majority of them), while (with judicious use of #defines) they could preserve a second version fairly easily that did not rely on casting away const. For example, a class might be designed which caches results of common operations in private members of the object. Even if the object is semantically const, it should be legal for the object to update these caches, and could be accomplished by casting "this" from const. It would not be hard to write such classes so that caching (and casting from const) could be turned off with a #define. I interpret the spec to say "Well, lots of people want const to be an artificial limitation, to make programs easier to debug, but lots of other people want to write ROMable code and use const to tell the compiler it is okay to put this variable in ROM. Since we don't want to add still one more keyword, we will just let compiler writers choose which one they want to implement, since the customers of a particular compiler will likely agree on which choice is better." Also note that the spec doesn't say that a compiler either has to do it one way or another. It would not be unreasonable to have the compiler always generate the same code (which allows casting away const), and have the address exception only occur when the program is executed from ROM. I expect the result of the ANSI proposal will be that most compilers would allow casting away const (in a portable way), while only compilers that were being used to develop embedded code that would actually live in ROM would not allow casting away const. Compilers could also be written to support both options, with a command-line option or pragma to select between them. >8-11 8.4.3 'A variable declared to be a T&, that is "reference to type > T" (&8.2.2), must be initialized by an object of type T or by > an object that can be converted into a T." > > In my opinion, null references should be explicitly allowed, thus > maintaining the general symmetry between pointers and references. > Also, it seems silly to prohibit such in the language spec when > compilers can't detect such usages. IE we should explicitly > allow: > > int& r = *(int*)0; And I suppose you then would write: if (&r == 0) cerr << "r is null"; This strikes me as too error prone. In general, a reference is just another name for a real object. If you want to allow for there not being an object, then use a pointer. >9-4 "Nonstatic data membres of a class declared without an intervening > access-specifier are allocated so that later members have higher > addresses within a class object." > > In my opinion, this statement is silly and outside the scope of > a language definition and instead is the business of compiler > implementators. [...] I would like to see the stronger statement that would provide for strict correspondance between C++ class data members and ANSI-C structs. Perhaps that was what was intended by this requirement, although it appears in fact to be too weak to have much of any usage. >9-7 "A union may be thought of as a structure whose member objects > all begin at offset zero and whose size is sufficient to contain > any of its member objects." > > A union CAN be thought of like this, or any other way you might > choose, but if this isn't meant to be a constraint on how > compilers are allowed to implement unions, then it'd be best to > leave the statement out. [...] I think a little clarification and explanation can remain in the spec, even if it isn't a strict requirement. If it is not made explicit elswhere, then I would agree that this statement should be expanded into a requirement on how unions are implemented. >16-4 "An implementation may impose a limit on the depth of #include > directives within source files that have been read while > processing a #include directive in another source file." > > A sensible lower bound should be stated that all conforming > implementations must be able to meet. What does ANSI-C call out? I agree. People are already reporting to comp.lang.c++ problems caused by one compiler's limit of 11 levels of #include nesting. -- Jeremy Grodberg "I don't feel witty today. Don't bug me." jgro@lia.com