>It would be a pity if the iostream hierarchy doesn't include something
>like strstreams, but using class string; this would mean that programs
>will have to continue using both kinds of strings, and do a fair
>amount of work to convert between them.

Not necessarily.  You can always derive your own string streams from
class ios and class streambuf.

    JdeBP

In article <Cu8sL4.Arw@borland.com> pete@genghis.interbase.borland.com
(Pete Becker) writes:

|> In article <MATT.94Aug7002700@physics2.berkeley.edu>,
|> Matt Austern <matt@physics.berkeley.edu> wrote:
|> >strstream, istrstream, and ostrstream allow formatted I/O to and from
|> >strings, instead of output devices.  They require a fairly complicated
|> >memory allocation protocol, though, which is related to the fact that
|> >the "strings" they use are C-style strings, i.e., arrays of chars
|> >terminated by '\0'.

|>  Actually, it's easy:

|>  char buf[256];
|>  ostrstream out( buf, sizeof buf );

|>  No need to mess with freeze() and unfreeze(). But if the results of
|> your manipulations of the stream exceed the buffer size, the output will be
|> truncated.

What happens in the following case:

 char            buf[ 5 ] ;
 ostrstream s( buf , sizeof( buf ) ) ;
 s << 12345 << ends ;

Is the result of s.str() still '\0' terminated?  I imagine not.  Which
means that instead of having to mess with freeze, et al., I have to
test the state of the stream, and write real error handling code.
--
James Kanze                                  email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue des Francs Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

strstream, istrstream, and ostrstream allow formatted I/O to and from
strings, instead of output devices.  They require a fairly complicated
memory allocation protocol, though, which is related to the fact that
the "strings" they use are C-style strings, i.e., arrays of chars
terminated by '\0'.

This makes sense if C-style strings are the only sort of strings we
have to work with, but it doesn't really make much sense if there's
any other alternative.  C-style strings are awfully low level in quite
a few ways.

My question, then: given that the C++ standard class library will
include a string class, will the standard include an iostream class
that uses these strings?

It would be a pity if the iostream hierarchy doesn't include something
like strstreams, but using class string; this would mean that programs
will have to continue using both kinds of strings, and do a fair
amount of work to convert between them.
--

                               --matt

In article <MATT.94Aug7002700@physics2.berkeley.edu>
matt@physics2.berkeley.edu (Matt Austern) writes:

|> My question, then: given that the C++ standard class library will
|> include a string class, will the standard include an iostream class
|> that uses these strings?

Yes.  (At least, I think so.)
--
James Kanze                                  email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue des Francs Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In article <MATT.94Aug7002700@physics2.berkeley.edu>
           matt@physics.berkeley.edu "Matt Austern" writes:
> strstream, istrstream, and ostrstream allow formatted I/O to and from
> strings, instead of output devices.  They require a fairly complicated
> memory allocation protocol, though, which is related to the fact that
> the "strings" they use are C-style strings, i.e., arrays of chars
> terminated by '\0'.

> It would be a pity if the iostream hierarchy doesn't include something
> like strstreams, but using class string; this would mean that programs
> will have to continue using both kinds of strings, and do a fair
> amount of work to convert between them.

Ideally the class library will replace 'strstream' with 'string', so that
string will understand operator<< just like ostream.

It'd also be nice if ostream had a

    virtual putchar(char c)

operator so you could write subclasses of it easily. (Incidently
why isn't it *virtual*? Efficiency reasons, I'd guess). The present
implementation requires you to write a subclass of streambuf, I tried and
gave up as I felt it was too complex. In the end I wrote my own
'OStream' class hierarchy which IMO is much easier to use and understand
than ostream (especially for subclassing). It's also got some good
functions for reading input, eg for implementing lexical analysers.

--
Phil Hunt

In article <MATT.94Aug7002700@physics2.berkeley.edu>,
Matt Austern <matt@physics.berkeley.edu> wrote:
>strstream, istrstream, and ostrstream allow formatted I/O to and from
>strings, instead of output devices.  They require a fairly complicated
>memory allocation protocol, though, which is related to the fact that
>the "strings" they use are C-style strings, i.e., arrays of chars
>terminated by '\0'.

 Actually, it's easy:

 char buf[256];
 ostrstream out( buf, sizeof buf );

 No need to mess with freeze() and unfreeze(). But if the results of
your manipulations of the stream exceed the buffer size, the output will be
truncated.

>
>This makes sense if C-style strings are the only sort of strings we
>have to work with, but it doesn't really make much sense if there's
>any other alternative.  C-style strings are awfully low level in quite
>a few ways.
>
>My question, then: given that the C++ standard class library will
>include a string class, will the standard include an iostream class
>that uses these strings?
>

 Yes.
 -- Pete