Re: A small game
On Sep 18, 1:46 am, Juha Nieminen <nos...@thanks.invalid> wrote:
James Kanze wrote:
That's simply not true. Except for small, Unix type filter
programs, I don't think I've ever output where there wasn't a
need to flush. It's the rule, rather than the exception.
You have never written a program which opens a file for writing,
writes a bunch of data to it, and then closes the file?
Sure. My Unix filters, for example. Of course, the files they
deal with tend to be fairly small, so performance is really not
an issue.
I'm sure that there are applications which open a file, then
write tons of data to it in one go. And that in some of these
applications, replacing the std::endl with a '\n' in the tight
loop will make a significant difference. But I don't think that
such applications are that frequent, and it's easy to "optimize"
them once the performance problem has been spotted. In the mean
time, lots of applications output data from input or based on
external events, and it's much easier to figure out where they
went wrong if all of the data they'd written actually was
written.
Do you mean you always keep files open for the entire
execution of the program?
It depends on the program, but most of the time, yes. In most
programs, my files are open for the entire execution of the
program, or at least for a very long time. (Some of the
programs run for years, and the logs are rotated when the become
too big.)
I don't believe that.
And yet, it's true. (In one application, we kept our
persistency files open in permanence. And the application ran
for years on end.) But that doesn't really have much to do with
the issue here. If your outputting a very large amount of data,
in a tight loop, flushing after each line end can slow things up
somewhat; in such cases, you optimize by using '\n'. But
normally, it won't slow things up that much unless the files are
opened in synchronizing mode (which isn't possible with
ofstream), and if they're synchronized, it's precisely because
you need the flush, and you need it to really work.
(Persistency is a good example here: you can't send the
acknowledgement to the request until you are 100% sure that the
updated data is actually physically on disk.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34