tags:

views:

116

answers:

4

I have the following code, running on Suse 10.1 / G++ 4.1.0, and it doesn't write to the file:

#include <fstream>
#include <iostream>

int main(){
    std::ofstream file("file.out");
    file << "Hello world";
}

The file is correctly created and opened, but is empty. If I change the code to:

#include <fstream>
#include <iostream>

int main(){
    std::ofstream file("file.out");
    file << "Hello world\n";
}

(add a '\n' to the text), it works. I also tried flushing the ofstream, but it didn't work.

Any suggestions?

A: 

Does

file << "Hello world" << std::endl;

work?

endl inserts a newline and flushes the buffer. Is that what you were referring to when you said that you'd already tried flushing it?

Bryan Marble
+1  A: 

Don't know if this is what you tried but you should do:

file << "Hello World" << std::flush;

Update; I'm leaving this answer here because of the useful comments

Based on feedback, I'll modify my advice: you shouldn't have to explicitly call std::flush (or file.close() for that matter), because the destructor does it for you.

Additionally, calling flush explicitly forces an I/O operation that may not be the most optimized way. Deferring to the underlying iostreams and operating system would be better.

Obviously the OP's issue was not related to calling or not calling std::flush, and was probably due to attempting to read the file before the file stream destructor was called.

John Weldon
The `ofstream` destructor should automatically flush.
Omnifarious
@Omnifarious: That deserves a downvote? Is my answer *wrong*?
John Weldon
@John Weldon - It is wrong because it doesn't really address the OPs actual problem. It might be useful in debugging and figuring out what the real problem is (and should therefor be a comment), but isn't a solution in itself. If it is meant as a solution it suggests a cargo-cult style solution in which one inserts code without understanding why it needs to be there.
Omnifarious
Of course, nobody else really suggests a solution either. All the answers are basically debugging suggestions. But most of them are at least phrased as debugging suggestions. I wouldn't have downvoted if it hadn't had an upvote or if it had been phrased as a debugging suggestion instead of as a solution.
Omnifarious
@Omnifarious; wouldn't you agree that you *should* flush the stream before closing it, rather than relying on the destructor?
John Weldon
@John Weldon, no I wouldn't agree that you should do that. The flushing is an implementation detail. The conceptual model of the file is that you are writing to it with the `<<` operator. It is `ofstream`'s responsibility to maintain that model in all reasonable contexts. I should only have to reach in and fiddle with the implementation detail in specific cases where I need the actual file and the model presented by `ofstream` to match at a particular instant of time.
Omnifarious
@Omnifarious; I'll defer to you, I think your case is compelling.
John Weldon
It is wrong because it suggests the destructor of `ofstream` doesn't flush, when in fact it does.
Johannes Schaub - litb
+2  A: 

If you check your file doing a cat , it may be your shell that is wrongly configured and does not print the line if there is no end of line.
std::endl add a \n and flush.

Ugo
Yeah, try doing `cat file ; echo`. Don't mindlessly use `endl` though. I hate code that uses that stupid construct and I wish the standards people would remove it from the standard. Flushing is expensive, and should always be done consciously and with forethought.
Omnifarious
@Omnifarious I agree that flushing fstream is often useless but it seems to me that it is a must for standard output/error stream.
Ugo
The problem was the buggy editor used in my work that doesn't show the line if there is no '\n' at the end. Obviously, vi shows it right.Thanks.
kinslayer_e
+3  A: 

The destructor should flush and close the file.

I am pretty sure, the error is an another place, either

1) You do not check at the right point in time. At which point do you compare the content of the file, "after" the exits, or do you set a breakpoint before the program exits and then you check the files content?

2) Somehow the program crashes before it exits?

frunsi
Yeah, if the program as given runs and after it's completely finished and you get your prompt back it doesn't contain the data, there's a bug somewhere.
Omnifarious