Thread: fflush(stdout)

Unless you use a very old compiler, then no.
If the buffer needs to be flushed, the libraries will do it for you.
Otherwise you could just test.

Like Elysia said, it depends on the compiler (or perhaps more accurately, the runtime library that the compiler is using). printf(), etc, are not GUARANTEED to write the data out immediately. Most runtime libraries flush when you switch to reading input, and often also whenever there is a newline in the output, so most code will work just fine without.

If you are writing something like a progress measure [on the same line over and over, or one "dot" at a time], then it's most likely a good idea to put a fflush(stdout) after each update.

In older runtime libraries, you may also need a fflush() when reading data immediately after writing something without a newline, e.g.

Code:

   printf("Enter your name:")
   fgets(name, sizeof(name), stdin);

could end up reading the name without having shown the prompt for the name - which make the app look like it's hung, and you don't realize it's waiting for input... Turbo C typically needed this.

--
Mats

>Each time I print something to the screen (printf, puts, putchar.....) ?
As with most answers, it depends. You don't need to force a flush if the last character printed was a newline, such as with puts. You don't need to force a flush if it isn't needed, but the usual issue is this one:

Code:

printf ( "Enter some input: " );
fgets ( input, sizeof input, stdin );

The implementation could choose to block for input before flushing stdout's buffer. In that case, the user would see a blank screen and not know what to do. I haven't seen this happen on Windows systems, but I have seen it on Unix, so it's not a theoretical issue. Forcing a flush guarantees that the prompt will be visible before blocking for input:

Code:

printf ( "Enter some input: " );
fflush ( stdout );
fgets ( input, sizeof input, stdin );

I'd recommend using fflush in such cases for portability reasons. Not to mention extra l33t points for knowing obscure problems and solutions in the standard stream library.

>If the buffer needs to be flushed, the libraries will do it for you.
Yes, but the library's need and the programmer's need are two different things. The library is only required to flush a buffered output stream when the buffer becomes full, a newline is written, or fflush is called. Relying on the library doesn't guarantee a solution to the above problem unless you get lucky and the buffer fills up with your prompt.

Implementations can choose to work around the problem for programmer convenience, but it's not a requirement. It's easier not to apply a workaround, so you shouldn't expect your implementation to do so.