std::fstream fail() anomaly?

I've been testing out some code I wrote on a test program. Although GDB doesn't catch anything and it runs fine, it's supposed to generate output files. It did that at first, but after debugging various other aspects of the test program, it doesn't generate any files at all. Extensive debugging of that yielded nothing.

The strange part is I started another test -- copy/pasted/compiled the fstream example from cplusplus.com and even *that* didn't generate files. I added a simple "cout << filestr.fail() << endl;" statement and the compiled example always outputs a 1.

I'm running these tests with root privileges, plenty of memory, and 92 GB of free disk space. The fact that not even a simple C++ code snippet from a reference site generates files is eerie. This is the said snippet, with the failbit check I added and a test I/O operation:

Code:

---

#include <iostream>
#include <fstream>
using namespace std;

int main () {

  fstream filestr ("test.txt", fstream::in | fstream::out);
  cout << filestr.fail() << endl;

  filestr << " dsgesvsvds";

  filestr.close();

  return 0;
}

---

I don't think fstream::in and fstream:: out are right. Try to replace them with std::ios::in and std::ios:: out.

Quote:

---

Originally Posted by EVOEx

I don't think fstream::in and fstream:: out are right. Try to replace them with std::ios::in and std::ios:: out.

---

Okay, just tried that. I have the same result.

Quote:

---

Originally Posted by Chris87

Okay, just tried that. I have the same result.

---

Hmmm you're right, they're the same anyway. It seems that it works perfect though, except that the file is not created. Try creating the file yourself, it should work then.

Well, that solved it or simple text output, but my real code needs to be able to create the file as well, because it deals with binary format stream and I don't think an empty file would work...

Then you need to check if the file exists, and if not, create the file first.

Well it's easy, but considering my program involves creating/rewriting cache files, that could be cumbersome. I need to find a way to programmatically create the file.

Of course you can do it programatically. I didn't suggest otherwise.
Try opening with std::ios::in only. If the file doesn't exist, it will fail. If it fails, then open with std::ios::out to create the file.
If you don't care about the file contents, you can truncate it by opening it with out first and then opening with in and out.

Thanks, I'll take that into consideration. I think I figured out the problem... I wanted to have both input/output open whereas my prior method was opening and closing the file stream and I was using variables to save the buffer position and all. It seemed like more of a hassle than I needed, so I switched to both I/O being open, which is my likely guess when these anomalies happened.

I'd just like to point out that you don't need to pass openmodes at all in this case. fstream automatically assumes you want a stream that goes in both directions.

Code:

---

std::fstream filestr ( "test.txt" );
if ( filestr.is_open ( ) ) {

// i/o stuff

}

---

It is far easier to let the type of stream assume what kind of thing you want to use. The only time I have to pass anything in myself for openmodes anymore is when I need to work with binary files.

So passing just the binary flag would work too? Does fstream assume I/O with just that?

>> So passing just the binary flag would work too? Does fstream assume I/O with just that?
fstream will assume you are working with a text file and that you want to use a bidirectional stream. If I were using a binary file I would have to do something like

Code:

---

std::fstream ( "test.bin", ios::in | ios::out | ios::binary );

---

Even though personally I do not see much of a point in a bidirectional stream for binary like this. (I'd pick reading or writing not incorporate both.) Reading a binary file is complex enough without worrying about file positions and what's being read. It comes down to wanting a single object for file handling, I guess.

edit: In fact, let's just link the page for fstream constructors.