C++ Tips: IO - iostream miscellanea

[ben2ong2]

(Newsgroups: comp.std.c++)

Steve Clamage:

You will have to modify existing code to include the new standard
header <iosfwd> instead of forward declarations like
   class ostream;
The <iosfwd> header contains a set of declarations including
   typedef basic_ostream<char> ostream;

Ajay Kamdar: You are not allowed to view links. Register or Login

Was this a conscious decision (to require existing code using iostreams
to change) or something that just slipped by?


Steve Clamage: You are not allowed to view links. Register or Login (Steve Clamage), 7 May 96

It is the product of many years of work by many people, and is very
deliberate. The point was not to invalidate existing code, but to find an
acceptable solution to a serious problem. I can't possibly summarize all
the design tradeoffs that were investigated in 5 years of work and
thousands of pages of documents. (At least not in a netnews article --
it would take a book.)

The problem to be solved is that traditional iostreams are useful only for
8-bit localized character sets. Some change was necessary to accomodate
other character sets, particularly when we notice that much of the
world is moving from ASCII to Unicode. In addition, programs commonly
must work in multi-language environments. Leaving iostreams alone was
simply not an option.

Basing iostreams on wchar_t instead of char imposes an unacceptable
burden on programs and programmers using 8-bit character sets. Thus,
more than one kind of stream is necessary, at minimum char and wchar_t
streams. A program that reads or writes data should not always have to
know and care whether a stream is char or wchar_t (or perhaps something else).
Often you just want to write text to whatever the stream happens to be. The
underlying library takes care of any needed transformations, like wide chars
to multibyte or padding 8-bit chars to 16 or 32 bits.

We need some relationship among the stream classes so that you don't have
to write multiple sets of code to deal with different kinds of streams.
After a lot of work by a lot of people in America, Europe, and Japan
(especially Japan), the best solution found was to templatize iostreams,
providing a uniform method for writing iostream source code no matter what
the kind of stream or locale. That method also allows iostreams to be
extended to additional character sets with different characteristics without
needing to re-write client source code. (An implementation can simply supply
new specializations.)

To minimize the impact on existing code, some of the more arcane template
parameters default to whatever is normal for the implementation's environment.
For ASCII environments, the defaults make new iostreams look remarkably
like traditional iostreams. A program can be adapted to additional
enviroments by supplying more of the template parameters.

Some fundamental changes in iostream design were required to support the
additional functionality. Most of these could be hidden from simple uses
of iostreams. You cannot in general in C++ provide your own declarations
of standard library members; normally you must include a standard library
header. The stream classes are no longer an exception to that general rule.