Path: utzoo!utgpu!watmath!uunet!tut.cis.ohio-state.edu!ROCKY.OSWEGO.EDU!dl
From: dl@ROCKY.OSWEGO.EDU (Doug Lea)
Newsgroups: gnu.g++.lib.bug
Subject: libg++1.34 stream class doesn't conform to The Book
Message-ID: <8903181557.AA28394@rocky>
Date: 18 Mar 89 15:57:43 GMT
References: <8903171719.AA04623@prep.ai.mit.edu>
Sender: daemon@tut.cis.ohio-state.edu
Reply-To: dl@rocky.oswego.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 78


>>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