Bug 000277

When Created: 03/19/1999 20:00:02
Against DJGPP version: 2.02
By whom:
Abstract: clear the state of cin after eof
please help with the following little problem.  I'd like to use "eof" as a
sentinel for some simple test programs as follows:  
#include <iostream.h>

int main() {     
  int q; 
  while(cin >> q)
       cout << " echo of q: " << q << " ";
  cin.clear();  // clears the cin stream eof flag so
                // we can use cin again     
  cout << "another input loop\n";
  while(cin >> q) 
      cout << " echo of q: " << q << " "; 
  return 0; 

I expect this code to give the following output (Control-Z is the "eof" marker
on PCs; it's Control-D with Unix):  

echo of q: 9 7
echo of q: 7 ^Z
another input loop  
echo of q: 1 2
echo of q: 2 ^Z

which it does under Turbo C/C++ 3.0 for DOS.  (although I've learned an odd
thing, the code as written does not work if the cout statement which prints
the line "another input loop" is removed.  even though the cin object's state
has been cleared, the second while loop does not execute unless something --
even just sending an "endl" -- is sent to the cout object.)

my foremost question then is why does this code not work using DJGPP, v2.02?
I've read the "info" under iostream -- there's a section on "Checking the
state of a stream", and it seems to say that the above should work, just as
it does under Turbo C/C++ -- well, hopefully it will work better than in Turbo C++, since Turbo C++ seems to be buggy as well.

I've had a chance to look at the MS VC++ 6 documentation and it essentially says the same regarding ios::clear() as does the DJGPP iostream info -- that is, and I quote from the DJGPP info docs:

- Method: void ios::clear (iostate STATE)
    Set the state indication for this stream to the argument STATE.
    You may call `ios::clear' with no argument, in which case the state
    is set to `good' (no errors pending).

I think this is a bug in the DJGPP compiler.

BTW, MS VC++ works just fine with the sample code in my original message.  I've also verified that the sample works as I expect under Linux with the egcs c++ compiler (version egcs-1.0.3).

what am I missing here?  thanks in advance.

Note added: 04/19/1999 09:00:17
By whom:
I think this is either a bug in the C++ library or some subtle feature
that the programmer didn't know about: it seems that cin.clear()
doesn't call clearerr() (I put a breakpoint there, and it was never
hit), and hence the EOF flag is not cleared from the stdin stream.

What this does is that the second time through the loop, the first
cin operation gets EOF and exits the loop.

In contrast, the following C program, which does roughly the same,
*does* work:

#include <stdio.h>                                                              
int main (void)                                                                 
  int c;                                                                        
  puts ("First loop");                                                          
  while ((c = getchar ()) != EOF)                                               
    putchar (c);                                                                
  clearerr (stdin);                                                             
  puts ("Second loop");                                                         
  while ((c = getchar ()) != EOF)                                               
    putchar (c);                                                                
  return 0;                                                                     

But if you remove the call to clearerr(), it shows exactly the same
behavior as the C++ program in the original report.

Could someone who knows C++ please look into what cin.clear() *should*
do, and then see if the latest libstdcxx.a indeed does that?

See the work-around, if you *really* need that C++ code to work RIGHT NOW.

Workaround added: 04/19/1999 10:00:41
By whom:
The work-around is to call cin.seekg(0, ios::end) before the second
loop.  This causes the stream to get past the offending ^Z character
which is stuck in the buffer, and all's well after that :-).

Of course, this could cause trouble if the program repositions the stream
after that and hits the ^Z again...

Closed on 04/22/1999 11:00:41: This bug is in the C++ library, not in DJGPP.
By whom:

Note added: 07/01/2004 02:37:17
By whom:
kindly help me for this( but this is a very simple programs)


main() {
  char name[80];
  char add[80];

cout << "Enter name: ";
cout << "Enter address: ";

return 0;

note i think this is a bug in c++ library

  webmaster     delorie software   privacy  
  Copyright 2010   by DJ Delorie     Updated Jul 2010