Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!apple!motcsd!hpda!hpcuhb!hpcllla!hpclisp!hpclscu!shankar From: shankar@hpclscu.HP.COM (Shankar Unni) Newsgroups: comp.lang.c++ Subject: Re: Some comments on Lippman's Message-ID: <1000024@hpclscu.HP.COM> Date: 11 Sep 89 04:37:31 GMT References: Organization: Hewlett-Packard Calif. Language Lab Lines: 109 > p. 16 Is "long float" allowed? No. It's a silly archaism from yore. (Don't send me flames about those strange floating-pt sizes on VAXen). > p. 18 Octal char constants, but no hex ones? Hex constants are legal. Probably an oversight from the book. > p. 18 Still no lexical concatenation of strings? (i.e. # and ## in the > preprocessor should not be used?). The preprocessor section needs to be ANSI-C-ified. I'm sure it will be high on the list of things to do for the ANSI C++ committee. > p. 24 "volatile","asm", "handle" are listed as reserved words, but > never mentioned thereafter. "volatile" is supposed to be handled correctly (AT&T's 2.0 doesn't handle it at all; it should have). "asm" is simply passed on untouched to the C source by the translator (it's supposed to be "implementation-defined"). "handle" is gone from the AT&T 2.0 documentation: it has been replaced by "catch", which is also not described. > p. 24 "signed" is no included in the table of reserved words. Oversight. It's there in the AT&T 2.0 doc. > p. 41 an array has dimension 1 when it should be 0; no zero length > arrays yet? What exactly do you want a "zero-length array" to be? Should indexing work for this? Maybe. What else? Any restrictions? > p. 41 mention that ".cc" is also a common extension. Not the scope of a language description. This is more of an implementation detail. I've seen ".C", ".cc", ".cpp", ".cxx" and even ".c" (AT&T). > p. 72 it should be mentioned that char is guaranteed to be 1 byte > (hopefully) otherwise "byte" is never defined exactly. That's right. Who says that a byte must be exactly 8 bits long? The ANSI C std., for instance, only implies >= 8 bits. > p. 157 The rule for promotion of "unsigned short" is quite bizarre. > p. 175 Restricting foreign linkage to file scope is bizarre and ought to > be rationalized. I wouldn't call them bizarre. Of course, I have heard from the school of thought that claims that X3J11 erred grievously in changing the promotion rules: I presume that you belong to that camp. There is another side to that question, too. I won't debate it here. As to foreign linkage: I entirely agree with that restriction. Why on earth would you want a block-scope declaration with foreign linkage? At the very least, it's a stylistic error. > p. 218 Rule that member functions bodies can reference not yet > declared data members means that one pass compile is impossible. As > far as I can tell it is the only case in C++/C where use can > precede declaration (whether this is implicit or explicit). What's > so wrong with declaring all data members before the functions that > use them? I don't see why. There is no parsing problem with this. The only problem was if you wanted to do some processing like find out the type and size of the member. But this situation will arise only for inline member functions. You can do all your struct consistency checking at the end of the definition of the struct - this will include detecting such illegal usages in the bodies of member functions. > p. 227 Is it really true that the (un)signedness of bit fields is > honored, which is a (welcome) departure from C? The 2.0 doc does not say anything either way, but I'm sure that in spirit they are supposed to be honored. Of course, it you declare the bit field as plain "int" or "short" or whatever, the implementation is free to choose whether it is signed or not. > unabridged. The discussion of the new streams if very cursory; a detailed > discussion, like the one of the standard io library in K&R, with entry > point declarations etc... would be useful (or do you want us to buy AT&T's > product perforce?). I entirely agree. Ploughing through the man pages is pretty painful. I wish that this topic had been covered in much deeper detail, with lots of examples. > Overall the impression from the book is that 2.0 is *very* > different from 1.2, and in very subtle ways as well, above and > beyond what my perceptions had been before (from hints dropped > here in there in this forum, in Stroustrup's papers, etc...). True. C++ has not been, by any stretch of imagination, a stable language, and even major changes and rolls are only to be expected. Of course, once the ANSI C++ committee is constituted, the language will be stabilized. Expect to see still more changes before that happens. BTW, 2.0 is pretty much what will be used as a starting point of any standard. ----- Shankar Unni E-Mail: Hewlett-Packard California Language Lab. Internet: shankar@hpda.hp.com Phone : (408) 447-5797 UUCP: ...!hplabs!hpda!shankar Disclaimer: These statements reflect my personal opinions and do not necessarily reflect those of my employer.