end of stream for std::cin

[Sanyi]

What is cin's streambuffer's state and content after the following
(using namespace std)?

string((istreambuf_iterator<char>(cin)),
istreambuf_iterator<char>()) );

I am trying to use this in a loop (to get a 'multiple cat'-like
behavior) and the second time around it returns an empty string
instead of waiting for more input. This makes me think that either the
end-of-stream stays in the buffer or cin or its buffer is in some bad
state. Either way, how can this be fixed to get more input?

Thanks,
S.

[Christopher]

On Feb 22, 7:20 am, Sanyi <[e-mail]:

What is cin's streambuffer's state and content after the following
(using namespace std)?

string((istreambuf_iterator<char>(cin)),
istreambuf_iterator<char>()) );

I am trying to use this in a loop (to get a 'multiple cat'-like
behavior) and the second time around it returns an empty string
instead of waiting for more input. This makes me think that either the
end-of-stream stays in the buffer or cin or its buffer is in some bad
state. Either way, how can this be fixed to get more input?

Thanks,
S.

What was wrong with using the get unformatted text methods (get or
getline) of cin?
Then checking the state via cin::bad(), cin::fail(), cin::eof(), and
cin::good()?

[James Kanze]

On Feb 22, 2:20 pm, Sanyi <[e-mail]:

What is cin's streambuffer's state and content after the following
(using namespace std)?

string((istreambuf_iterator<char>(cin)),
istreambuf_iterator<char>()) );

I am trying to use this in a loop (to get a 'multiple cat'-like
behavior) and the second time around it returns an empty string
instead of waiting for more input.

What else do you expect. The first time around, you read until
end of file. What do you expect to read further once you've
reached end of file?

This makes me think that either the end-of-stream stays in the
buffer or cin or its buffer is in some bad state.

Once you've reached end of file, you've reached end of file,
yes. And once a read has failed, the istream remains in failed
state until you clear the error.

Either way, how can this be fixed to get more input?

What more input do you expect? It's easy to clear the failbit:
cin.clear(). But you're still at end of file, and there is
nothing more to read.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Feb 22, 7:47 pm, Christopher <[e-mail]:

On Feb 22, 7:20 am, Sanyi <[e-mail]:

[...]

Moral of the story is stream buffer iterators differ from your
everyday iterator.

istreambuf_iterator is an input iterator. It fulfills all of
the requirements of an input iterator. It's not like a foreward
iterator, of course, but that's why there are different
categories.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Sanyi]

Thanks for all for the enlightening replies, and sorry if I made some
rash statements.

In your original problem, the behavior of the "underlying sequence" of a
stream buffer on which eof occurred is not defined by the Standard and I
believe it cannot be defined usefully, because it is more as the
sequence is the active piece here (that is, the agent that creates or at
least originally detects eof condition), rather than your C++ program.
In your case, when the user presses Ctrl-D, s/he instructs the terminal
(which is not a part of your program) to stop sending characters to your
process for good -- and I am not aware of a standard way for a program
to re-connect to any terminal again after this happened.

That pretty much clears everything up. I had the wrong idea that the
end-of-file is just another character in the input stream that can be
neglected by my program if it wishes. (The reason why I chose it as
terminator was that in a first version my chunk of text was indeed
piped in, and only later I wanted to extend it to a interactive multi-
chunk piece. Also it seemed to me that is an easy way to abstract some
differences btw linux and windows/dos.)
I see now, that I better use some other terminating sequence as
recommended below.

As for respecting unix conventions, I will remember next time. Given
the very limited user space, in this case it should have not been a
problem.

Thanks,
S.

What I believe you are trying to achieve is to implement some protocol
to allow the user to instruct the program to process the piece of data
s/he already entered and then wait for another piece. Ctrl-D will not
work for this and maybe it is not at all bad because, if it did, you
would have another problem -- how to notify the program that the user is
done-done. You need to introduce your own protocol.

This problem is not new either, so there used to be some "standards" in
UNIX (and not only) for this part of console user interface and some of
your older users may be comfortable if you use these standards. For
example I vaguely remember these (it was so long ago that I do not
remember what programs did it, one with dot was probably some primitive
mail client):

1. Enter a text line with a single dot character (these days, ClearCase
command-line tool does it, too)
2. Enter 2 empty lines in a row

Then, to actually "disconnect" of your program user would have to enter
Ctrl-D or maybe enter 2 dot-only lines in a row or whatever you decide.

Hope this will help
-Pavel

[Sanyi]

Thanks for all for the enlightening replies, and sorry if I made some
rash statements.

In your original problem, the behavior of the "underlying sequence" of a
stream buffer on which eof occurred is not defined by the Standard and I
believe it cannot be defined usefully, because it is more as the
sequence is the active piece here (that is, the agent that creates or at
least originally detects eof condition), rather than your C++ program.
In your case, when the user presses Ctrl-D, s/he instructs the terminal
(which is not a part of your program) to stop sending characters to your
process for good -- and I am not aware of a standard way for a program
to re-connect to any terminal again after this happened.

That pretty much clears everything up. I had the wrong idea that the
end-of-file is just another character in the input stream that can be
neglected by my program if it wishes. (The reason why I chose it as
terminator was that in a first version my chunk of text was indeed
piped in, and only later I wanted to extend it to a interactive multi-
chunk piece. Also it seemed to me that is an easy way to abstract some
differences btw linux and windows/dos.)
I see now, that I better use some other terminating sequence as
recommended below.

As for respecting unix conventions, I will remember next time. Given
the very limited user space, in this case it should have not been a
problem.

Thanks,
S.

What I believe you are trying to achieve is to implement some protocol
to allow the user to instruct the program to process the piece of data
s/he already entered and then wait for another piece. Ctrl-D will not
work for this and maybe it is not at all bad because, if it did, you
would have another problem -- how to notify the program that the user is
done-done. You need to introduce your own protocol.

This problem is not new either, so there used to be some "standards" in
UNIX (and not only) for this part of console user interface and some of
your older users may be comfortable if you use these standards. For
example I vaguely remember these (it was so long ago that I do not
remember what programs did it, one with dot was probably some primitive
mail client):

1. Enter a text line with a single dot character (these days, ClearCase
command-line tool does it, too)
2. Enter 2 empty lines in a row

Then, to actually "disconnect" of your program user would have to enter
Ctrl-D or maybe enter 2 dot-only lines in a row or whatever you decide.

Hope this will help
-Pavel

[Sanyi]

Thanks for all for the enlightening replies, and sorry if I made some
rash statements.

In your original problem, the behavior of the "underlying sequence" of a
stream buffer on which eof occurred is not defined by the Standard and I
believe it cannot be defined usefully, because it is more as the
sequence is the active piece here (that is, the agent that creates or at
least originally detects eof condition), rather than your C++ program.
In your case, when the user presses Ctrl-D, s/he instructs the terminal
(which is not a part of your program) to stop sending characters to your
process for good -- and I am not aware of a standard way for a program
to re-connect to any terminal again after this happened.

That pretty much clears everything up. I had the wrong idea that the
end-of-file is just another character in the input stream that can be
neglected by my program if it wishes. (The reason why I chose it as
terminator was that in a first version my chunk of text was indeed
piped in, and only later I wanted to extend it to a interactive multi-
chunk piece. Also it seemed to me that is an easy way to abstract some
differences btw linux and windows/dos.)
I see now, that I better use some other terminating sequence as
recommended below.

As for respecting unix conventions, I will remember next time. Given
the very limited user space, in this case it should have not been a
problem.

Thanks,
S.

What I believe you are trying to achieve is to implement some protocol
to allow the user to instruct the program to process the piece of data
s/he already entered and then wait for another piece. Ctrl-D will not
work for this and maybe it is not at all bad because, if it did, you
would have another problem -- how to notify the program that the user is
done-done. You need to introduce your own protocol.

This problem is not new either, so there used to be some "standards" in
UNIX (and not only) for this part of console user interface and some of
your older users may be comfortable if you use these standards. For
example I vaguely remember these (it was so long ago that I do not
remember what programs did it, one with dot was probably some primitive
mail client):

1. Enter a text line with a single dot character (these days, ClearCase
command-line tool does it, too)
2. Enter 2 empty lines in a row

Then, to actually "disconnect" of your program user would have to enter
Ctrl-D or maybe enter 2 dot-only lines in a row or whatever you decide.

Hope this will help
-Pavel

[Sanyi]

I am sorry for the triple(!?) reply.