TITLE: a brief history of iostreams

(Newsgroups: comp.lang.c++.moderated, 23 Jan 97)


MARIAN: marian
> 
> It occurs to me that I really do not understand iostreams.
> I use them.
> I look at a chart and see--oh, yes, this is the hierarchy, etc.
> I understand descriptions when I read about the classes in iostreams.
> 
> But I don't understand iostreams in a historical development sense.
> They have changed over time.  How?  In what way? Why?
> They are templatized.  Simply for efficiency? What are the
> ramifications of this?

  {See also the June C++ Report, which has an article by Klaus Kreft
  and Angelika Langer covering new-style vs. old-style IOStreams. -mod}


CLAMAGE: Steve Clamage <stephen.clamage@Eng.Sun.COM>

Stroustrup's "Design and Evolution of C++" has a brief (3-page)
discussion in chapter 8.

Original iostreams was from the days when C++ allowed only
single inheritance. Its purpose was to support device-independent
I/O, like stdio, but with type safety. The lack of
multiple inheritance made in/out streams difficult to use.
The design was not extensible to new kinds of I/O.

When multiple inheritance was added to C++, Jerry Schwarz
did a complete redesign of iostreams. I think the two main
enhancements were
 - using multiple inheritance to support in/out streams.
 - separating formatting from buffering and designing the
buffer classes support derivation.

Splitting formatting from buffering meant you could create a
new kind of buffering class to support different devices
or to perform data transformations independently of the
other iostream functionality. For example, instead of
wiring string and file I/O into the iostream classes,
string and files are handled just by deriving classes
from the basic buffer class.

As we entered the C++ standardizing process, it was pointed
out that C++ did not support internationalization (I18N).
The Japanese delegation in particular worked very hard to
find ways to fit, at a minimum, multibyte characters into
iostreams. (The Japanese have perhaps the most complicated
problems, since they routinely need to use different character
sets and encodings on a daily basis. Any solution that worked
for Japanese would probably work well for everyone else.)

None of the attempts to salvage existing iostreams was
ultimately successful. The Committee instead, in a design
decision reminiscent of the earlier iostream change,
separated I18N from I/O. That also allowed I18N concerns
to be fitted into strings and other library parts.

The version of iostreams in the draft standard keeps the
overall basic design of previou version of  iostreams, but
makes the streams dependent (via template parameters) on I18N
issues. The implementation must provide specializations
for the normal char type in the "C locale" so that traditional
C++ programs (e.g. "Hello, world!") will always work. In
addition, the implementation can provide specialiations for
other locales and character types. Iostreams would continue
to be used in pretty much the same way for these cases.