ansaurus

Question

Return value of ifstream.peek() when it reaches the end of the file

Answer 1

+2 A:

EOF is for the older C-style functions. You should use istream::traits_type::eof().

Edit: viewing the comments convinces me that istream::traits_type::eof() is guaranteed to return the same value as EOF, unless by chance EOF has been redefined in the context of your source block. While the advice is still OK, this is not the answer to the question as posted.

Mark Ransom 2010-09-14 20:01:49

that's strange, I tried that and it still goes on forever

jwaffe 2010-09-14 20:06:34

`::eof()` returns `EOF` for `char_traits<char>`, which is the one of `istream`.

Johannes Schaub - litb 2010-09-14 20:09:20

Even though T.E.D helped me a lot, Mark answered the question at the top of the page, so I'm choosing him as the accepted answer. Thanks for your help guys!

jwaffe 2010-09-14 20:17:06

@jwaffe please note that he did not answer your question. His attempt at solving your problem failed because `EOF` is always equal to `istream::traits_type::eof()`. This is an instance of http://meta.stackoverflow.com/questions/64308/try-xyz-answers . (I'm a retard, but I'm ok with that).

Johannes Schaub - litb 2010-09-14 20:19:10

@Johannes, is it a requirement that eof() return EOF, or is it just a common convention?

Mark Ransom 2010-09-14 20:21:53

@jwaffe, you are not required to select an answer, especially if none of the answers actually solved your problem. It might not be too late to unclick my answer, because I'm convinced that it didn't really help.

Mark Ransom 2010-09-14 20:23:21

The Standard says "The member eof() returns EOF" (for the `char` version) and "The member eof() returns WEOF" (for the `wchar_t` version).

Johannes Schaub - litb 2010-09-14 20:24:04

In Mark's defense (I'm actually his one upvote), I could easily see where, due to unfortunate `#include`'s or something, `EOF` could have ended up `#define`'d to something else. That's what my first bullet was getting at. So his advice is good IMHO.

T.E.D. 2010-09-14 20:25:21

@T.E.D. sure I think it's good to advice to use `eof()`, I do agree. But really the answer reads to me as "This fails because you use EOF. You need to use istream::traits_type::eof() which has the correct value"

Johannes Schaub - litb 2010-09-14 20:35:42

So EOF is synonymous with istream::traits_type::eof()?

jwaffe 2010-09-14 20:38:17

Answer 2

+2 A:

Things that come to mind (without seeing your code).

EOF could be defined differently than you expect
sourcefile.peek() doesn't advance the file pointer. Are you advancing it manually somehow, or are you perhaps constantly looking at the same character?

T.E.D. 2010-09-14 20:08:13

I found the problem, it actually didn't have anything to do with my while loop, the very last read was looking for '/n', but it didn't find it because it was actually the end of the file. I should have put something in there to stop it in case it was the end of the file.

jwaffe 2010-09-14 20:13:11

Answer 3

+1 A:

Consulting the Standard,

Returns:traits::eof() ifgood()isfalse. Otherwise,returnsrdbuf()->sgetc().

As for sgetc(),

Returns: If the input sequence read position is not available, returns underflow().

And underflow,

If the pending sequence is null then the function returns traits::eof() to indicate failure.

So yep, returns EOF on end of file.

An easier way to tell is that it returns int_type. Since the values of int_type are just those of char_type plus EOF, it would probably return char_type if EOF weren't possible.

As others mentioned, peek doesn't advance the file position. It's generally easiest and best to just loop on while ( input_stream ) and let failure to obtain additional input kill the parsing process.

Potatoswatter 2010-09-15 02:07:07

ansaurus

tags:

views:

answers:

Return value of ifstream.peek() when it reaches the end of the file

related questions