is it string's getline or just me?

[algorithm]

Hi,

I've a simplified program snippet in which getline behaves in a way, which
at least I find odd:

// File: getline_example.cpp
#include <iostream>
#include <string>
using namespace std;

int main()
{
int one;
if (cin >> one)
{
cout << "one: " << one << endl;

string two;
if (getline(cin,two))
{
cout << "two: " << two << endl;

string three;
if (getline(cin,three))
{
cout << "three: " << three << endl;
}
else
{
cout << "third error." << endl;
}
}
else
{
cout << "second error." << endl;
}
}
else
{
cout << "first error." << endl;
}
}

Using g++ 3.4.2 with the following input results in the following:
$ g++ getline_example.cpp
$ ./a.exe
42
one: 42
two:

I.e. I start program and it is waiting for input.
I enter 42 and hits return.
As expected the program outputs what I just inputed.
However, the program outputs "two:" as well!?!?!?

This is very odd to me since I have only entered one data input (42). I
was expecting that the program was awaiting a second set of indata but no
- it just goes on and instead it is waiting for a third set of data!?!?

I have no idea what or why the statement getline(cin,two) did! But I do
know that it did not wait for my second set of indata :-(

Is it me or is it g++ who gets this wrong. (I do not think that g++ should
get this trivial case wrong, so...)

Thanks in advance!

PS. Do not advise me to add advanced error-checking and resetting a state
flag or the like because that should really not be nescessarry. (State is
checked in the if statements.)

[Julián Albo]

algorithm wrote:

This is very odd to me since I have only entered one data input (42). I
was expecting that the program was awaiting a second set of indata but no
- it just goes on and instead it is waiting for a third set of data!?!?
I have no idea what or why the statement getline(cin,two) did! But I do
know that it did not wait for my second set of indata :-(

getline reads to the next end of line. If you have an ureaded end of line in
the stream (and you have it, because the operator >> stops reading after
the last digit) the result will be an empty string.

If you expect data separated in lines, will be better to always read with
getline, and decode the content of each line separately, using a
istringstream, for example.

--
Salu2

[red floyd]

Julián Albo wrote:

algorithm wrote:

This is very odd to me since I have only entered one data input (42). I
was expecting that the program was awaiting a second set of indata but no
- it just goes on and instead it is waiting for a third set of data!?!?
I have no idea what or why the statement getline(cin,two) did! But I do
know that it did not wait for my second set of indata :-(

getline reads to the next end of line. If you have an ureaded end of line in
the stream (and you have it, because the operator >> stops reading after
the last digit) the result will be an empty string.

If you expect data separated in lines, will be better to always read with
getline, and decode the content of each line separately, using a
istringstream, for example.

More specifically, after you do cin >> one, and have read the number 42,
there is still a newline pending on cin, so that cin >> two will read to
the end of line (the very next character), and set the variable "two" to
an empty string (since there was no other data before the newline).

[algorithm]

> after you do cin >> one, and have read the number 42,

there is still a newline pending on cin, so that
cin >> two will read to the end of line

ah - i didn't think of that...
thanks!