TITLE: iostream miscellanea (Newsgroups: comp.std.c++) Steve Clamage: You will have to modify existing code to include the new standard header instead of forward declarations like class ostream; The header contains a set of declarations including typedef basic_ostream ostream; Ajay Kamdar: ajay@lehman.com Was this a conscious decision (to require existing code using iostreams to change) or something that just slipped by? Steve Clamage: clamage@Eng.Sun.COM (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.