From -1748509959710719238 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,8fe125a4c11ad8a,start X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1990-11-06 14:53:37 PST Path: gmdzi!unido!mcsun!uunet!microsoft!jimad From: jimad@microsoft.UUCP (Jim ADCOCK) Newsgroups: comp.std.c++ Subject: X3J16/90-0091 typos and comments Message-ID: <58861@microsoft.UUCP> Date: 6 Nov 90 22:53:37 GMT Reply-To: jimad@microsoft.UUCP (Jim ADCOCK) Organization: Microsoft Corp., Redmond WA Lines: 186 Posted: Tue Nov 6 23:53:37 1990 TYPOS, COMMENTS, AND A QUICK REVIEW ON X3J16/90-0091 [The following are my opinions only] 1-1 "February 1990" Should be updated. 2-1 "tokens, that is, a file" Looks like a misuse of commas, but I can't figure out how to fix it. 2-2 keywords Shouldn't this include a list of preprocessor directives and "defined" ? 5-5 5.3.3"The type-specifier-list may not contain const, volatile, class declarations, or enumeration declarations." It would seem that allowing const and/or volatile would not be harmful, and might make for better type calculus, especially when using the placement operator: const volatile ClockReg* pread_only_clock_reg = new(0x12345678) const volatile ClockReg; or consider: #define ROClockReg const volatile ClockReg // .... ROClockReg* proClockReg = new(0x12345678) ROClockReg; 5-7 5.4 "A yet undefined class may be used in a pointer cast, in which case no assuptions will be made about class latices." Actually, in this situation it seems to me that a LOT of assumptions ARE made! Perhaps it would be better to state what those assumptions are? To wit: in such a situation, a pointer remains bitwise equivalent, and no pointer adjustments are made? Or what? 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.] 7-5 7.1.6 "Volatile" Exact meaning of volatile needs to be codified. "A hint to the compiler not to be overagressive" is insufficient. 7-8 "it is recommended that the spelling be taken from the document defining that language, for example Ada (not ADA) and FORTRAN (not Fortran) Recommendations have no place in a standard. Its either a requirement or its not. Make this a requirement. 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; 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. In the language, the only connotation of ordering of addresses is the ordering of elements of an array. Therefor, it is not possible to write a strictly conforming program that makes use of the above constraint. Individual compilers can still choose to follow the above constraint, and programmers can then write non-strictly conforming programs that make use of those compilers' "features." So what is the point of making ALL compilers forever-more conform to a constraint that NO STRICTLY-conforming program can use !? All this constraint does is confuse customers about what kinds of pointer hacks are strictly conforming, and what aren't. Among other things, this unnecessary constraint has a negative impact on compilers striving for speed, compactness, incremental compiles, schema evolution, etc... 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. In particular, it is easy to imagine on some machines "offset zero" might refer to left packed objects, but that machine might prefer to right pack objects into a union, leading to a "not offset zero" implementation. Consider the following trivial example: union { long l; char c; } U; Are both l and c constrained to be at "offset zero" ? I think not. 10-1 "The commentary sections at the end of this chapter discuss the run-time mechanisms necessary to implement inheritence." The commentary is gone, and so should this statement. 13-2 "Note that only the second and subsequent array dimensions are significant in argument types." I think this is bad. Arrays of fixed dimension should always be considered of certain type, but be coercible to uncertain type implicitly. The rules for array parameters go the wrong way, allowing the below kind of silly-ness: double power(double d[1][3]) { return d[0][0]*d[0][0] + d[0][1]*d[0][1] + d[0][2]*d[0][2] ; } void doSomething() { double M3x3[3][3]; double pow = power(M3x3); // oops, we silently sliced // off 2 rows! } .... or even worse. Implicit coercion of arrays of definite type to arrays of indefinite type is bad enough. Implicit coercions of arrays of indefinite type to arrays of definite type must be the weakest point in the C++ type system! 13-5 typo: numbers [1]-[5] are duplicated. 13-6 13.4 "The following operators cannot be overloaded" As I have argued before, I believe operator dot, and operator dot star, should be overloadable analogous to operator->() and operator->*() 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?