Thread: infinit loop on istream test

The following code loops forever once I enter the failbit test.

Code:

    int ival;
    while (cin >> ival, !cin.eof()) {
        if (cin.bad())
            throw runtime_error("Corrupted IO Stream.");
        if (cin.fail()) {                        
            cerr << "bad data, try again...";    
            cin.clear(istream::failbit);
            continue;
        }
        /* ... */
    }

After some reading I entered cin.ignore() before the continue statement and even tried to pass gcount() to ignore() first argument. To no avail. Also, literal integers passed to ignore() seem to have the effect of only working if I match the exact lenght of the string introduced...

What should be done?

The comma in the if is really odd.

Instead of

Code:

   while (cin >> ival, !cin.eof()) {

Did you mean

Code:

   while (cin >> ival && !cin.eof()) {

No. I meant to evaluate eof() only, while still taking cin input. The comma operator evaluates both expressions but takes only the rightmost as the result.

Code:

int i = 0;
while (i++, i != 6) {
   cout << i;  //outputs 12345
}

I could probably place my code inside a do statement and not do that comma thing, but the result will be the same. The problem seems to be that when continue executes the stream still contains whatever input was there and that caused the failbit to be set.

Hence my tries with ignore() and gcount(). Ignore() works when I feed it with a literal integer representing the exact size of the input that causes the failbit.

Code:

($ is my prompt)

$ 1
//works fine
$ bord
// works fine if I introduce cin.ignore(4); just before continue.
//for some reason I cannot understand, it doesn't when i pass cin.gcount() as an argument to ignore()

Well, there are two problems here. The first is what Daved pointed out, that you need to discard what's left on the buffer after the cin.clear() by using cin.ignore(), perhaps with numeric_limits from <limits>. The next problem lies with your use of cin.clear(istream::failbit). This actually sets the stream's status to istream::failbit, hence entering an infinite loop. What you actually want to do is use cin.clear(istream::goodbit), or more simply, cin.clear().

The loop will only break if std::cin has a problem entering a number into ival or if you simulate EOF on your keyboard.

No, the loop will only terminate if the stream is in an EOF state after the read, which in this means simulating EOF as you have mentioned. The reason for this is that the comma operator returns the latter of the arguments passed, hence !cin.eof() is in question.

I didn't remember testing the value of gcount(), which is really silly of me. It returns 0.

The documentation I have, describes gcount() as returning the number of characters read by the last input operation. It seemed a good argument to pass to ignore(). However, judging by that return value, it is far from it. I'll be reading on the web about this member function...

It is working now. Thank you all. My use of ignore() was a joke

Only one thing I didn't understand...
I thought clear(istream::failbit) would reset failbit to a valid state. Failbit was ON when clear() was called, correct? So why didn't it reset when I requested specifically for that bit to be reset? Or... better yet, how can I gain fine grain access to condition states both to set and clear their respective bits?

You are right. Thanks Kurt.

That information is actually on my source (Herbert Schildt's C/C++ Programmers Reference, Osborne - McGraw-Hill). I didn't read it carefully enough.

It is actually a very poor reference book, if my opinion matters.

- The STL is honored with a whooping 6 pages,
- Some inconsistencies like C++ Strings and Exceptions being dealt in the... same chapter(!),
- Confusing structure like Standard C I/O functions being discussed 4 chapters before we being yet again introduced to it with chapters devoted to old style and new style C++ IO.
- Some important omissions. There's no discussion on <limits> for instance or not describing all existing overloads for getline().

Oh well, I should have know better... 344 pages can't possibly constitute a reference to both C and C++