What is the status of the standard with respect to the C++ stream
library?  I recall hearing at some point that it was going to be
redesigned, and I would like to know whether there is any consensus as
to what differences there will be for people deriving types of streams
or streambufs.  I would also like to know when I can expect to see the
standard library defined.

There are a number of different types of derived streams that I would
find useful; streams that keep track of the current line number,
ostreams that do not produce output (to allow selective printing of
information), ifstreams that read from multiple files, istreams that
ignore lines that match a particular regexp, "tstreams" that print to
multiple streams and so forth.

I have implemented some of these using the current streams library, but
if future changes are going to render such classes obsolete, I will wait
for the changes before writing the others.

Thanks.
                         Jak Kirman                        jak@cs.brown.edu
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Vi is a piece of wombat do.
                            -- Title of 1985 European UNIX User Group debate

In article <JAK.93Mar29003853@aruba.cs.brown.edu>, jak@cs.brown.edu (Jak Kirman) writes:
|> What is the status of the standard with respect to the C++ stream
|> library?  I recall hearing at some point that it was going to be
|> redesigned, and I would like to know whether there is any consensus as
|> to what differences there will be for people deriving types of streams
|> or streambufs.  I would also like to know when I can expect to see the
|> standard library defined.
|>

The standards committee started with the AT&T library as a
"base".  The committee has so far accepted a subset of that base
containing

 ios, istream, ostream, streambuf, filebuf, ifstream, ofstream,
 strstreambuf, istrstream, ostrstream.

What I call the "protected interface" to streambufs (i.e. the
interface for the virtuals) is largely unchanged.   However all the
"allocation" related functions (allocate, doallocate, unbuffered)
have been removed.

The requirements on streampos have been loosened to allow implementation
on "non-unix-like" systems which require more than an integer to
remember a file position. Implementations that use an integral type can
continue to do so, and implementations must provide
a way for derived streambufs to use integral values. (E.g. seeking
in strstreams is still done in terms of integral values).

The stream classes have no virtual functions.  Derivation
from them is supported via the "infinite arrays" of iword and
pword.   This interface here has been modified slightly (to avoid
a union) but not in a way that should impact "defined" usage.

Several new types have been introduced to improve the type safety
of the library and to allow vendors needed flexibility for environments
where sizeof(int)!=sizeof(long) and where int's are not 32 bits.

 ios::fmtflags: the type of the ios flag component
                 (formerly "long")

 ios::streamsize used in functions that require a size
   (formerly "int")

 ios::iostate formerly (enum io_state)
        ios::openmode   formerly (enum open_mode)
        ios::seeekdir formerly (enum seek_dir)

There are many other changes, but a high priority has been
to preserve existing code, including code that derives new
streambufs or streams.  In general I expect vendors to make
every effort to preserve their customer's existing code.

The committee is still considering changes to accomodate
multi-byte character sets and to incorporate stream classes
that use a "String" class.

Let me emphasize that the above is only a snapshot of the
committees deliberations and is still subject to change.

  -- Jerry Schwarz