Why is this cin reading jammed?

Question

I\'ve singled out a failure on my program that prevents me from assigning a value to the variable addAntonymAnswer1. I\'ve tried running cin.clear()

Answer 1

cin >> ... reads from standard input until it finds a whitespace character. When you enter, say, 8 5 for the list of synonyms, 8 gets read into lineOfSyns and nothing more. When the program reaches cin >> addAntonymAnswer1, 5 gets read into addAntonymsAnswer1. Your program behaves unexpectedly since it expects yes or no but it got 5.

Look at using cin.getline() instead of >>. See, for example, sections 18.2 and 18.3 of this page.

Answer 2

In your program you ask the user:

Please write on a single line the ids for the synonyms of test
starting with its id, which is 8

For example, to define that the synonym of the word 'cute', which has an id 1, i
s'beautiful', which has an id 7, you should write: 1 7

In the case of test you should start with 8

Then you attempt to read in the line the user typed with

cin>>lineOfSyns;

However, this only reads up to the first whitespace. So the 2nd number typed in by the user is still in the cin buffer when the

cin>>addAntonymAnswer1;

line is executed, so that data gets read into the addAntonymAnswer1 string. The user never gets an opportunity to type in 'yes' or 'no' and your tests for those values fail.

You should consider changing to using the string overload for getline() to do your reads:

getline( cin, stringvar);

This would probably be better than using cin.getline(), as that does not have an overload that takes string - with that member function, you need to read into an array of chars, which is far less flexible than reading into a string.

Answer 3

It is "stuck" because it is waiting for input. cin is attached to the standard input handle for the program, you have to type something and hit enter.

Answer 4

cin.clear() doesn't clear the standard input. What it does is clearing error bits, like eofbit, failbit and others, and sets the stream into a good state. Maybe you expected it to clear out anything in it? If the user typed

yes no

Just before, and you

cin >> someStringVariable;

It will read up to no and the stream will still contain

 no

The call to clear then clears any error bits being active. Then, your

cin>>addAntonymAnswer1;

Will read the no that wasn't eaten by the previous read, and the action immediately returns, not waiting for new input. What you should do is doing a clear followed by an ignore, up to the next newline. You tell it the amount of characters it should ignore maximally. That amount should be the highest number possible:

cin.clear();
cin.ignore(std::numeric_limits<std::streamsize>::max(), '\n');

Doing that will make the stream empty, and a following read will wait for you to type something in.

---

Another problem arises if you have got a cin >> followed by a getline: The cin will leave any whitespace (also newlines) after its read token, but getline will stop reading after it hits such a newline. I see you have put clear after nearly everything. So i want to show you when you need it and when not. You don't need it when you sequence multiple cin >>. Assume you have in your buffer: "foo\nbar\n". Then you do the following reads

cin >> a; // 1
cin >> b; // 2

After the first, your buffer will contain "\nbar\n". That is, the newline is still in. The second cin>> will first skip all whitespace and newlines, so that it can cope with \n being at the front of bar. Now, you can also sequence multiple getline calls:

getline(cin, a);
getline(cin, b);

Getline will throw away the \n that it reads at the line end, but won't ignore newlines or whitespace at the begin. So, after the first getline, the buffer contains "bar\n". The second getline will correctly read "bar\n" too. Now, let's consider the case where you need the clear/ignore:

cin >> a;
getline(cin, b);

The first will leave the stream as "\nbar\n". The getline then will see immediately the \n at the begin, and will think it read an empty line. Thus, it will immediately continue and not wait for anything, leaving the stream as "bar\n". So, if you have a getline after a cin>> you should first execute the clear/ignore sequence, to clear out the newline. But between getline or cin>>'s, you should not do it.