TITLE: Some history and current state of IO streams


RESPONSE: rlogan@axysdev.nwest.mccaw.com (Ron Logan)

Because of these peculiarities with DOS text files (I assume), DOS  
IOStreams have a special "binary" flag that you can turn on to indicate  
that you don't want that carriage-return/newline translation to take  
place.  You do this by specifying ios::binary when you open the file....  


RESPONSE: mwt@lightside.com (Mark Thompson)

This flag doesn't seem to work in Unix, so if you use it,  
you're compromising your portability.


RESPONSE: kit@delphi.bsd.uchicago.edu (Kit Transue)

This flag appears in Steve Teale's _C++ IOStreams Handbook_; the closest I  
have to a formal specification of IOStreams.  This flag shouldn't DO  
anything in Unix, but I sure would hope that its use wouldn't break  
anything.  I don't have an Unix IOStreams library available to test, but  
has anyone experienced such problems?

 ...

BTW--I'm very glad to have Teale's book, but it seems to get me in a bit  
of trouble sometimes.  For example, streams with assignment have been  
removed from the proposed standard (according to James Kanze), but my  
compiler seems to provide an implementation very close to that described  
in Teale, so testing doesn't provide a check.  Is there a source of  
corrections and updates along the lines of that for Stroustroup?  Should I  
buy the working paper?  


RESPONSE: clamage@Eng.Sun.COM (Steve Clamage), 13 Sep 94

These are good questions and observations. Here's some background.

The original IOstreams came with Cfront 2.0 and was written for Unix systems;
it has a fair amount of Unix-specific stuff in it. In particular, Unix 
supports the notion of a "file descriptor" as a small integer, and makes
no distinctions among types of files. These assumptions are not true on
all systems.

When IOstreams was ported to systems that distinguished between text and
binary files (that is, every system in the world except Unix), the
implementors needed to add a flag to indicate binary mode, text being
the default. Some spelled it "bin", some chose "binary". Unix systems
meanwhile got along nicely without the flag. Some implementors (like me) who
supported multiple platforms provided a binary-mode flag, and ignored it in
the Unix-specific part of the implementation.

The only thing resembling a standard for IOstreams was the original Cfront
documentation, so there was nowhere to turn for an "official" version of
the things not part of that release. This made (and still makes) life
unpleasant for programmers trying to write portable code.

Streams in general could not be copied (operator= or copy ctor) because it
wasn't clear what it should mean to copy a stream object -- what about
multiple versions of state flags and multiple copies of input buffers?
No one could figure out a way to get the standard streams cin, cout, cerr
initialized if streams could not be copied, however, so these streams were
derived from a hack called istream_withassign and ostream_withassign.
Streams you create are not ordinarily derived from the "withassign" streams
because you normally do not want to copy a stream object. (Copying the
thing the stream object represents -- such as a file -- is a separate notion,
and is of course supported.)

The library subcommittee has been working for years now on a standard
definition of iostreams, nearly all the early work having been done by Jerry
Schwarz, the developer of the original IOstreams. The new definition
attempts to:
 - address the various problems known to exist with IOstreams;
 - track language changes like templates, exceptions, booleans;
 - address internationalization concerns like wide chars;
 - fit with other new library classes, like string and standard exceptions.
This is a huge effort, partly because of the thousand small details in
IOstreams, and largely because language changes require iostream changes.

In particular, the issue of copying streams has been addressed, and
semantics have been defined. There is no need any more for the "withassign"
classes, which were only a hack anyway.

An additional problem cropped up when the iostream proposal in its then-
existing form was incorporated into the rest of the C++ Committee working
paper. The iostream proposal was not in the proper format and did not use
wording consistent with Standards requirements and the rest of the working
paper. (It was also written in TeX while the working paper uses -- ready? --
troff.) The iostream proposal was reworked, but was changed semantically in
the process, and had to be re-written yet again.

I hope this doesn't make the Committee members involved sound like the Keystone
Cops, because that is certainly not the case. A lot of very smart, very
experienced people have worked on this for long hours as a volunteer effort.
Mistakes happen.

So the answer to your last question is "NO, don't get the working paper
just for an iostream reference." It is not in its final form. Because the
details have changed three times per year, there has been no reasonable
way for a library implementor to try to track all the changes. (Anyone
who tried to would be shot by users, and with good reason.)

But all is not nearly as hopeless as it may sound.

The intent of the revisions is to allow most existing code using IOstreams
to continue to work without change when moved to a standard-conforming
implementation. In addition, vendors will certainly do their best (to
avoid being shot) to provide backwards-compatibility versions to ease the
transition process.

If you do "advanced" iostream stuff, some rewrites may be necessary, but
I expect these to be highly localized. For example, if you derive new kinds
of stream classes and use the macro form of manipulator defintions, you may
need to modify the implementation and header files. The code using your new
features probably will not need to change.