When and why does ios::badbit get set on an input or output operation on a file with an ifstream or ofstream?
I did a little Googling to try to answer this on my own, but didn't really find anything explaining in detail when and why this happens.

Thanks in advance.

EDIT: Hmm...it looks like one of the reasons is hardware failure. I hope that doesn't indicate there's something wrong with my computer... :)

01-14-2011

tabstop

Whenever something bad has happened, that's when badbit gets set. End of file. Matching failure (i.e. trying to read a number when the next thing in the file is a letter). File not existing.

01-14-2011

Programmer_P

Quote:

Originally Posted by tabstop

Whenever something bad has happened, that's when badbit gets set. End of file. Matching failure (i.e. trying to read a number when the next thing in the file is a letter). File not existing.

Ok, so say a getline(input_stream, buffer_str) operation had a matching failure...what could I do to fix that?

01-14-2011

tabstop

getline doesn't match, it just gets bytes. If getline fails, that's because the file is empty, at end of file, or could not be read.

01-14-2011

Programmer_P

Quote:

Originally Posted by tabstop

getline doesn't match, it just gets bytes. If getline fails, that's because the file is empty, at end of file, or could not be read.

And let's say it couldn't be read...
What are some of the reasons that might happen?

01-14-2011

tabstop

Quote:

Originally Posted by Programmer_P

And let's say it couldn't be read...
What are some of the reasons that might happen?

1) You never bothered to open the file.

2) You don't have permissions to read the file. (The open should have failed in that case.)

3) Bad fs.

4) Aliens.

5) End of file/empty file.

6) You misspelled the filename or specified the wrong directory.

01-14-2011

Programmer_P

Quote:

Originally Posted by tabstop

1) You never bothered to open the file.

2) You don't have permissions to read the file. (The open should have failed in that case.)

3) Bad fs.

4) Aliens.

5) End of file/empty file.

6) You misspelled the filename or specified the wrong directory.

Hehe. :D I meant reasons beyond the obvious.
Obviously, I opened the file, therefore 2 and 6 don't apply either, and the file is definitely not empty. And I know for a fact it didn't get to the end of the file when badbit was set, which rules out 5 as well.

And why would a filestream be bad? I wont even bother to ask about the aliens... :p

01-14-2011

tabstop

Quote:

Originally Posted by Programmer_P

Hehe. :D I meant reasons beyond the obvious.
Obviously, I opened the file, therefore 2 and 6 don't apply either

Did you check that the open succeeded? Are you reading any part of the file?

01-14-2011

Programmer_P

Quote:

Originally Posted by tabstop

Did you check that the open succeeded? Are you reading any part of the file?

Indeed. I'm reading most of the file, but it stops somewhere after line 1052. The file has 1115 lines.

EDIT: Nevermind. Its reading the whole file now.
It seems like it was a temporary thing, now its gone.

01-14-2011

tabstop

Are you using anything other than getline? What operation is the last successful one, what operation is the first unsuccessful one? Are you using the C-string version of getline, or the std::string version? getline will set failbit if you try to overflow your buffer (i.e. read more characters than can be stored safely).

01-14-2011

Programmer_P

Quote:

Originally Posted by tabstop

Are you using anything other than getline?

No, not for input operations.

Quote:

What operation is the last successful one, what operation is the first unsuccessful one?

I can't answer that, because its reading the whole file now. The problem appears to be gone. badbit is no longer being set.

Quote:

Are you using the C-string version of getline, or the std::string version? getline will set failbit if you try to overflow your buffer (i.e. read more characters than can be stored safely).

I'm using a std::getline version, which doesn't allow you to specify a buffer_size.

01-14-2011

whiteflags

I recall someone giving you advice in ancient times, that you have ensure success rather than assume things worked in programming by checking return values and other things, which you casually ignored because you were too new or something. You would be able to tell us much more about how your program is actually working if you followed through on that advice.