eichin@ATHENA.MIT.EDU (Mark W. Eichin) (03/16/89)
I've discovered two significant incompatibilities between the libg++ stream class and the description in Stroustrup's book. 1) istream.get(char*,int,char) is of type File, rather than type istream. This has the unpleasant effect of making a following >> not function, but not be flagged as an error. 2) operator>>(char&) doesn't ignore whitespace, yet this behavior is explicit in the description in the book (in fact, there is even a code sample, of how to define this operator...) If I wanted to read whitespace, I would use istream.get(char&). I'd also like to note that the Regex class is missing any way of using the registers (\(\) pairs) even though the code is there. In fact, both libg++ and OOPS use slightly different version of the GNUemacs regexp code anyway... having the superset here would be nice. Mark Eichin <eichin@athena.mit.edu>
mdt@YAHI.STANFORD.EDU (Michael Tiemann) (03/18/89)
Date: Fri, 17 Mar 89 13:20:57 +0000 From: Gordon Joly Statistics UCL <gordon%stats.ucl.ac.uk@nss.cs.ucl.ac.uk> Perhaps there should be a clarification of the relationship between G++ and the Stroustrup Standard? Is this in existing documentation? Some of the differences are documented in the file g++.texinfo, under the headings of "incompatabilities" and "extensions". Can Stroustrup be regarded as the final word? It certainly is the final word for users of his compiler. Gordon Joly. Michael
dl@ROCKY.OSWEGO.EDU (Doug Lea) (03/18/89)
>>Perhaps there should be a clarification of the relationship between >>G++ and the Stroustrup Standard? Is this in existing documentation? G++ and libg++ do conform less to Stroustrup's text than do AT&T CC and libC. I suppose I should say a few things about libg++ versus libC. Warning: This mostly off the top of my head. You will find a bit more about these in the libg++.texinfo file. The Book references, as being part of the `standard library' the classes `complex', `istream', and `ostream', and `task'. There is not yet a `task' library in libg++. The versions of the other three are different in libg++ than in libC. Class Complex contains, to the best of my knowledge, only thoroughly innocuous differences and extensions: Capitalization of the class name (as now seems conventional in C++), a few operators that return values instead of `void', additional explicit functions for mixed mode calculations, ... things like that. The istream and ostream classes were written over a year ago, when there were only a few dozen people using g++. At that time I asked myself and others what kinds of changes from the libC version might be nice. In retrospect, I suppose I should have done this differently, and extended, rather than modified libC capabilities in the majority of cases. In fact, i/ostreams will be revised with this philosophy sometime after the AT&T version 2.0 streams are released, since changes probably ought to be made in order to support any useful AT&T 2.0 stream extensions anyway. (No, I don't know very much about AT&T 2.0 streams, (like even if they are fully compatible with 1.X) except that they might be structured more similarly to libg++ streams than to AT&T 1.X streams). Anyway, the most obvious difference between current libg++ streams and those described in The Book are based on the fact that libg++ streams are entirely parasitic on the C stdio library. This is both for better (e.g., more power and flexibility for many operations; guaranteed compatibility and consistency with C code) and for worse (e.g., lack of a `streambuf' class, which causes hardship for those few people trying to port code using such things written for use with CC; and lack of a means for programmers to establish their own bufferring regimens). Two other differences are more superficial but more commonly encountered. Since g++ can discriminate a `char' from an `int', the libg++ ostream operator << (char), as in cout << '\n', outputs an ascii `newline' rather than `10'. Nobody ever seems to complain about this. Not so about the fact that istream operator >> (char), as in char ch; cin >> ch; uncontrollably does not skip white space. Even though some people prefer this behavior, this arbitrary difference was probably a mistake, since it has been the source of several annoying porting problems. This will finally be changed in the next release. You can get the same op >> effect right now via the quick-and-dirty modification to stream.h (a slightly better version that requires a few more changes will be in the next release): inline istream& istream::operator>>(char& c) { *this >> WS; get(c); return *this; } Header files for C compatibility are also different. The ones in libg++ appear more portable, but are less structured (e.g., the vast majority of useful declarations are in `std.h'). This is made pretty much transparent by the fact that various other include files just in turn include `std.h'. These kinds of incompatibilties will eventually be greatly reduced: Between ANSI, the (hopefully) forthcoming GNU libc library, and other cooperative efforts, compatibility for header files across C, AT&T C++ and GNU C++ should someday scarcely ever be a problem, I hope. I guess that the overall summary is that libg++ provides classes and C++ programming support in ways that are not guaranteed to be perfect clones of AT&T versions, but at the same time, minimize arbitrary, gratuituous incompatibilities. -Doug