My guess is that the results are printed in bunches of (say) 4KB, which means that each result is about 12 characters (4096 / 300 = 13.6 characters).Originally Posted by MK27
--
Mats
My guess is that the results are printed in bunches of (say) 4KB, which means that each result is about 12 characters (4096 / 300 = 13.6 characters).
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
I'll try with fflush and then I let you know...
Anyway thank you very much
To control writing behavior to the output file you can use the setvbuf() call on the standard output stream. This can control the write frequency by using a custom buffer size instead of the default BUFSIZ used on Unix platforms.
That's correct. But to the programmer, it often offers MORE control to use fflush(), as it allows a flush to happen exactly where the programmer wants it. If you set a small buffer size with setvbuf(), the risk is that a large number of consecutive writes are being flushed individually, when an fflush() at the end of the sequence allows all of the writes to be done to the internal buffer, and then be flushed as one single write operation. Hence my suggestion to use fflush().
In this particular case, I have a feeling it matters very little, but it's generally a better idea to flush() when some output is complete.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
I suggested setvbuf() only as an alternative since the OP wanted to see the simulation results before the process writes 300 times to the internal buffer. setvbuf() fits better where the op roughly knows how many records or characters to output before moving onto the next iteration. Both routines have their pros and cons though methinks in this case fflush() may very well be the way to go.
