pcg@thor.cs.aber.ac.uk (Piercarlo Grandi) (09/06/89)
I have just gone thru a cursory reading of Lippman's "A C++ primer". It is somewhat stodgy, but invaluable because it documents the new 2.0 features; the only other source I know of are the official AT&T cfront manuals... Here are some very preliminary notes, some on the book, some on the language: p. 16 Is "long float" allowed? p. 18 Octal char constants, but no hex ones? p. 18 Still no lexical concatenation of strings? (i.e. # and ## in the preprocessor should not be used?). p. 23 the reserved word "handle" is also part of a proposed extension, not just "template" p. 24 "volatile","asm", "handle" are listed as reserved words, but never mentioned thereafter. p. 24 "signed" is no included in the table of reserved words p. 35 no mention is made of the fact that a reference is always "const", e.g. "int &i = 10;" and "int &const i = 10;" are the same thing. p. 41 an array has dimension 1 when it should be 0; no zero length arrays yet? p. 41 mention that ".cc" is also a common extension. p. 72 it should be mentioned that char is guaranteed to be 1 byte (hopefully) otherwise "byte" is never defined exactly. p. 96 "while"s are designed to ensure that a condition does not exist (predicate falsifiers), not to "check" it. 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. p. 179 The rule that a class is only defined at the closing brace seems to make use of static const members defined within it impossible. This is regrettable (even if the new rule that enum's are local to a class offers, for integer constants, an escape). 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? p. 227 Is it really true that the (un)signedness of bit fields is honored, which is a (welcome) departure from C? p. 229 That constructed classes cannot be passed to ellipses is new. Explain why, also the problem with destructors if calle-initializes is done. p. 239 That "delete 0" be a no-op and not an error looks bizarre. Why? p. 240 That you need fully qualified name for an explicit destructor is ugly. p. 241 The rule for class array initialization has changed a bit; previously only the parameterless initializer was used. p. 249 The "const" in the signature of a constructor for initialization is now mandatory or not? p. 259 Why ever the "=", "[]", "()", "->", (and "->*", but is not mentioned) operators *must* be member functions? p. 271 No mention is made of the newly overloadable "," operator. It would be interesting to see cases in which it is useful. p. 292 The notion that the two syntaxes for a cast, "TYPE(expr)" and "(TYPE) expr", are non equivalent in one case strikes me as funny. p. 319 No mention is made of the syntax used to selectively change the visibility of inherited memembers. There are some general observations; the list of differences between 1.2 and 2.0 is incomplete (see some points above), as well as that between C and C++ 2.0; the version numbers have no reason to be typeset in the constat width font, that is used for code excerpts. Other quick notes; the book is over 400 pages long, and is a primer just like Stroustrup's is (but without the reference section). A lot of the extra pages are because of the bizantine subtelties of multiple inheritance, such as the long discussion of visibility rules. This is an area where the language is a bit more complicated than desirable, and the book presents the complexity 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?). 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...). I hope that Tiemann finishes converting G++ to 2.0 (expecially the new class local scope rule for enums!), etc... 2.0 solves many outstanding problems. Well, enough for now. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
jima@hplsla.HP.COM (Jim Adcock) (09/08/89)
// >Grandi: No mention is made of the newly overloadable "," operator. It would
// >be interesting to see cases in which it is useful.
//----------------------------------------------------------------
//Quick example of using <operator,> to make lists:
#include <stdio.h>
// This list class is really bogus -- its just a quick example!
class list
{
const char *s;
const list *l;
const list *r;
public:
list() {s=0; l=0; r=0;}
list(const char *S){s=S; l=0; r=0;}
list(const list& L, const list& R){s=0; l=&L; r=&R;}
void print() const;
list& operator,(const list& that){return *(new list(*this,that));}
};
void list::print() const
{
if (l) l->print();
if (s) printf("%s ",s);
if (r) r->print();
}
void inline nextline(){putchar('\n');}
void main()
{
list shoppinglist = (
(list)
"apples",
"oranges",
"celery",
"bananas",
"bread",
"newspaper"
);
shoppinglist.print();
nextline();
((list)"apples","oranges","celery","bananas","bread","newspaper").print();
nextline();
}jima@hplsla.HP.COM (Jim Adcock) (09/08/89)
/ hplsla:comp.lang.c++ / jima@hplsla.HP.COM (Jim Adcock) / 11:08 am Sep 7, 1989 /
// >Grandi: No mention is made of the newly overloadable "," operator. It would
// >be interesting to see cases in which it is useful.
//----------------------------------------------------------------
// Quick example of overloading <operator,> in order to turn C++ into
// a concurrent language, where semicolons continue to indicate processes
// are to be executed in sequence, and colons indicate processes are to
// be executed simultaneously. [Too bad C++ insists that the un-overloaded
// comma operator evaluate left-to-right including side effects. This
// unfortunate restriction is not applied to the more common usage of comma
// in function argument lists! If this context dependent restriction could
// be relaxed then C++ could naturally be applied to multi-processing CPUs,
// with semicolon continuing to mean sequencing, and comma indicating
// parallelism.]
// [Probably requires a 2.0 compatible compiler]
#include <stdio.h>
// bogus process classes -- just a quick example!
class multiprocess
{
friend class process;
const process *p;
const multiprocess *l;
const multiprocess *r;
public:
multiprocess() : p(0), l(0), r(0) {}
multiprocess(const process& P):p(&P),l(0),r(0) {}
multiprocess(const multiprocess& L):p(0),l(&L),r(0){}
multiprocess(const multiprocess& L, const multiprocess& R): p(0), l(&L)
{printf("simultaneously "); r=&R;}
const multiprocess& operator,(const multiprocess& that) const
{return *(new multiprocess(*this,that));}
};
class process
{
friend class multiprocess;
const char *s;
public:
process(const char *S):s(S){}
const process& operator()() const {printf("%s() ",s); return *this;}
const multiprocess& operator,(const multiprocess& that) const
{return (multiprocess(*this)).operator,(that);}
};
void inline nl(){putchar('\n');}
void main()
{
process do_this("do_this");
process do_that("do_that");
process and_do_the_other_thing("and_do_the_other_thing");
//semicolons indicates executing processes in sequence:
do_this(); nl();
do_that(); nl();
and_do_the_other_thing(); nl();
nl();
//whereas commas indicate executing processes simultaneously:
do_this(), do_that(), and_do_the_other_thing();
nl();
}jima@hplsla.HP.COM (Jim Adcock) (09/09/89)
>Grandi: >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? Well, AT&T's release notes pg. A-5 points out that the 2.0 compiler has "known problems" in some cases where names are used before declared. ...Nothing like a few compiler bugs to keep a programmer honest! :-)
shankar@hpclscu.HP.COM (Shankar Unni) (09/11/89)
> 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.