is it string's getline or just me?

A

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.)
 
?

=?ISO-8859-15?Q?Juli=E1n?= Albo

algorithm said:
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.
 
R

red floyd

Julián Albo said:
algorithm wrote:




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).
 
A

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!
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top