IOStreams

[Guest]

There are two methods of snagging a 'line' from a stream (with an attached
streambuf that reads/writes from a socket).
One is the std function "getline" and the other is the "getline" method of
the stream itself. Silly the stream only takes a char_type buffer when the
'std::getline()' takes a bonafide string reference!
I prefer the one that takes the basic_string ref. Here's the dilema with
this approach, I don't know how to test for EOF. Using the iostreams
getline method it returns '0' or something to that effect on EOF. Please
advise!

This is a little less related to IOStreams themselves but since I've
encountered this within the same context I hope this goes over at least
midly well.
This is a problem that is only happening to me on the Windows platform (try
not to think of this as a Windows specific issue -- I'm trying to understand
C++ techniques for C practices.). I'd like to know a C++ programmer accepted
way of removing the trailing '\r' from the result of one of the getline
formats. I don't want to assume the '\r' is there so I'd appreciate some
options. I have heard that it's supposed to be handled by the CRT of the
platform if I open the stream in text mode. Well I see only a binary mode
setting for the stream.

I'm still working through "Standard C++ IOStreams and Locales" so perhaps
the answers are there. I'd still appreciate any pointers.

ty~

 

[John Harrison]

There are two methods of snagging a 'line' from a stream (with an attached
streambuf that reads/writes from a socket).
One is the std function "getline" and the other is the "getline" method of
the stream itself. Silly the stream only takes a char_type buffer when the
'std::getline()' takes a bonafide string reference!

I think this is because iostream is older than string.

I prefer the one that takes the basic_string ref. Here's the dilema with
this approach, I don't know how to test for EOF. Using the iostreams
getline method it returns '0' or something to that effect on EOF. Please
advise!

Same return for both cases.

This is a little less related to IOStreams themselves but since I've
encountered this within the same context I hope this goes over at least
midly well.
This is a problem that is only happening to me on the Windows platform
(try
not to think of this as a Windows specific issue -- I'm trying to
understand
C++ techniques for C practices.). I'd like to know a C++ programmer
accepted
way of removing the trailing '\r' from the result of one of the getline
formats. I don't want to assume the '\r' is there so I'd appreciate some
options. I have heard that it's supposed to be handled by the CRT of the
platform if I open the stream in text mode. Well I see only a binary mode
setting for the stream.

If you don't open in binary mode then you are opening in text mode. IOW text
mode is the default. If you want to be sure then some simple string
manipulation can look for and remove a trailing '\r'. I don't think there is
any particular accepted method of doing this.

john

 

[Jon Bell]

There are two methods of snagging a 'line' from a stream (with an attached
streambuf that reads/writes from a socket).
One is the std function "getline" and the other is the "getline" method of
the stream itself. Silly the stream only takes a char_type buffer when the
'std::getline()' takes a bonafide string reference!
I prefer the one that takes the basic_string ref. Here's the dilema with
this approach, I don't know how to test for EOF. Using the iostreams
getline method it returns '0' or something to that effect on EOF. Please
advise!

If the stream (let's call it 'instream') behaves in a standard-conforming
fashion you should be able to process it with getline() the same way you
would with istream::getline():

string line;
while (getline (instream, line))
{
// process the line
}

// now find out why the input loop terminated

if (instream.eof())
{
// loop terminated because end of stream was encountered
}
else
{
// loop terminated because of an input error
}

 

[Guest]

I think this is because iostream is older than string.


Same return for both cases.

This is what I thought. (I swear it should work this way.) It's not... the
string being returned via std::getline() is returning the string with a size
of 0 and a buffer of "" -- no characters.

If you don't open in binary mode then you are opening in text mode. IOW text
mode is the default. If you want to be sure then some simple string
manipulation can look for and remove a trailing '\r'. I don't think there is
any particular accepted method of doing this.

I'm not opening it in binary mode but I started looking at the code... will
istream.wide( '\n' ) affect how the CRT on this platform looks at the 'new
line' sequences?

 

[Guest]

there

I'm not opening it in binary mode but I started looking at the code... will
istream.wide( '\n' ) affect how the CRT on this platform looks at the 'new
line' sequences?

Ok so I've discovered if I use the 'std::getline()' method the trailing
i'\r' is chopped, but if I use the 'istream.getline()' method the '\r'
remains! There's got to be somewhere I can get understanding.

 

[John Harrison]

Ok so I've discovered if I use the 'std::getline()' method the trailing
i'\r' is chopped, but if I use the 'istream.getline()' method the '\r'
remains! There's got to be somewhere I can get understanding.

If true that's a bug pure and simple. Could you post a program that
demonstrates this? I could test it out on a couple of different compilers.

john

 

[Guest]

If true that's a bug pure and simple. Could you post a program that
demonstrates this? I could test it out on a couple of different compilers.

john

I'm using a very basic basic_iostream with an attached basic_streambuf
implementation using a very basic network socket reader and writer. Using
std::cin I don't have the same problem so perhaps there's something wrong in
my 10 lines of streambuf code.

Though that still doesn't explain (to me) why std::getline( istream,
stringref ) works over istream::getline().

Doing more 'research' (re: stepping through many many lines of the compilers
code) I've found that at least on the windows side the conversion for the
'new line' sequence for cin is done way down in the filebuf class method
'uflow'.

So now here's another piece of my question (required for me to understand
this puzzle)... are the uflow() and underflow() method calls only used for
'formatted' input? Like if I adjust these calls will this affect me using
more 'binary' like methods?

ty!

 

[John Harrison]

I'm using a very basic basic_iostream with an attached basic_streambuf
implementation using a very basic network socket reader and writer. Using
std::cin I don't have the same problem so perhaps there's something wrong
in
my 10 lines of streambuf code.

Though that still doesn't explain (to me) why std::getline( istream,
stringref ) works over istream::getline().

Doing more 'research' (re: stepping through many many lines of the
compilers
code) I've found that at least on the windows side the conversion for the
'new line' sequence for cin is done way down in the filebuf class method
'uflow'.

So now here's another piece of my question (required for me to understand
this puzzle)... are the uflow() and underflow() method calls only used for
'formatted' input? Like if I adjust these calls will this affect me using
more 'binary' like methods?

ty!

I can't say about your system but on mine the conversion is done because the
filebuf class is implemented using the C stdio library and these routines
perform the translation.

uflow and underflow are used for all input, not just formatted input.

john

 

[Guest]

I can't say about your system but on mine the conversion is done because the
filebuf class is implemented using the C stdio library and these routines
perform the translation.

uflow and underflow are used for all input, not just formatted input.

Ok so I won't handle it that way then. I was following a call to getline()
on cin() and it ended up inevitably following through filebuf's uflow() then
onto plain read().

Any idea why this would be different for a stream? Or what I might need to
do to get it to translate properly?

 

[Guest]

What I think I'll end up doing is testing if the stream is in 'binary' mode
and then converting 'new' line pairs. I've read enough newsgroup postings
and web pages to know this is how the libraries do it and how even ANSI has
standardized it.