Irregular behaviour: C++ standard lib and file stream.

[bruce varley]

Hello,

I suspect a platform bug, but first I'd like to check whether the C++
standard library has changed the handling of streams in a way that creates
the
behaviour I'm observing. Hence this posting.

The following code fails when it's compiled with standard library, but
works without, refer to the commented sections. When failing, only the
first file open succeeds, subsequent ones generate an error. Is this
explainable 'within the rules?'

If anyone would like more information on specific platform details, email
me.

bx******@weqstn et.com.au
remove ecks and kyoo to email.

// works with this active
// *************** *************** *************
#include <iostream.h>
#include <fstream.h>
// *************** *************** *************

// Fails with this active
// *************** *************** *************
#include <iostream>
#include <fstream>
using namespace std ;
// *************** *************** *************

int main()
{
ifstream ifs ;
int i ;
char c ;
for (i = 0; i < 5; i++)
{
ifs .open ("TEST.TXT") ;
if (!ifs)
{
cout << "\nERROR" ;
return 1 ;
}
while (ifs) ifs.get (c) ;
ifs.close() ; // Strictly unnecessary, since stream has terminated.
// Removing makes no difference.
}
return 0 ;
}

[tom_usenet]

On Tue, 25 Nov 2003 21:50:01 +0800, "bruce varley"
<bx******@weqst net.com.au> wrote:

Hello,

I suspect a platform bug, but first I'd like to check whether the C++
standard library has changed the handling of streams in a way that creates
the
behaviour I'm observing. Hence this posting.

The following code fails when it's compiled with standard library, but
works without, refer to the commented sections. When failing, only the
first file open succeeds, subsequent ones generate an error. Is this
explainable 'within the rules?'
Yup, when a stream hits EOF it stays that way until you "clear" the
error state. See below.
#include <iostream>
#include <fstream>
using namespace std ;

int main()
{
ifstream ifs ;
int i ;
char c ;
for (i = 0; i < 5; i++)
{
ifs .open ("TEST.TXT") ;
if (!ifs)
{
cout << "\nERROR" ;
return 1 ;
}
while (ifs) ifs.get (c) ;

Add here:
ifs.clear(); //clears error state

Tom

C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

[Mike Wahler]

"bruce varley" <bx******@weqst net.com.au> wrote in message
news:3f******@q uokka.wn.com.au ...

Hello,

I suspect a platform bug, but first I'd like to check whether the C++
standard library has changed the handling of streams in a way that creates
the
behaviour I'm observing. Hence this posting.

The following code fails
Please define what you mean by 'fails'. Does it not compile?
Does it give unexpected behavior, and if so, what?
when it's compiled with standard library, but
works without, refer to the commented sections. When failing, only the
first file open succeeds, subsequent ones generate an error. Is this
explainable 'within the rules?'

If anyone would like more information on specific platform details, email
me.

bx******@weqstn et.com.au
remove ecks and kyoo to email.

// works with this active
// *************** *************** *************
#include <iostream.h>
#include <fstream.h>
Neither of these headers are, or ever have been, part of
standard C++, so I'll not comment further upon them.
// *************** *************** *************

// Fails with this active
// *************** *************** *************
#include <iostream>
#include <fstream>
using namespace std ;
// *************** *************** *************

int main()
{
ifstream ifs ;
int i ;
char c ;
for (i = 0; i < 5; i++)
{
ifs .open ("TEST.TXT") ;
if (!ifs)
{
cout << "\nERROR" ;
return 1 ;
}
while (ifs) ifs.get (c) ;
ifs.clear();
ifs.close() ; // Strictly unnecessary, since stream has terminated. // Removing makes no difference.
}
return 0 ;
}

Or put the definition of 'ifs' inside the 'if' loop body
(before the open), so it will be destroyed and recreated
with each iteration of the loop.

-Mike