In article <4mltup$igb@engnews1.Eng.Sun.COM> clamage@Eng.Sun.COM (Steve
Clamage) writes:

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

Agreed so far.  But...

In practice, the only instantiaion types that are interesting are char
and wchar_t.  On the other hand, I need several variations of char: one
for ISO 8859-1, ISO 8859-2 ...

Is it intended that this variety on char be provided by the Traits
(although I don't see any member which would do it), or by imbue.

For that matter, can imbue be used to tell wistream that it is in fact
reading 8 bit ISO 8859-2.  This is actually three questions in one:
does the standard require this (almost sure, no)?  Does the standard
allow this?  And if the previous answers are no, yes, is it the intent
of the standard that this should be the case (for systems using Unicode,
at least)?
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article s8t@jabba.lehman.com, ajay@lehman.com (Ajay Kamdar) writes:
>In article <4m59bo$mv2@engnews1.Eng.Sun.COM>,
>Steve Clamage <clamage@Eng.Sun.COM> wrote:
>>
>>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;
>
>Was this a conscious decision (to require existing code using iostreams
>to change) or something that just slipped by?

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.

---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]