I don't agree it's a good practice. If printf isn't guaranteed to display the contents because of the lack of newline, then it's flawed and should be avoided with other functions instead.
There's fputs, fprintf too, though I don't know how they perform.
Isn't that the same philosophy that new programmers use respecting practices concerning bad usage of the language?
It works for me. So then is it good.
Again. Ugly philosophy. Just because it works for a particular compiler doesn't mean is appropriated to do or not do. Learning correct C language is beyond any specific compiler behaviour.
Don't encourage the opposite of what you are trying to preach.
Well fputs and fprintf are going to have the same "flaw". This has nothing to do with the functions themselves; it is simply the way buffered streams work.
Entirely different things! Defines/Macros != functions. Incorrect use of functions can cause runtime problems, crashes, security issues, etc. But macros do NOT.
I try to encourage avoiding flushing, simply because buffering is a good thing.Again. Ugly philosophy. Just because it works for a particular compiler doesn't mean is appropriated to do or not do. Learning correct C language is beyond any specific compiler behaviour.
Don't encourage the opposite of what you are trying to preach.
Then if it will sidestep them problem, I recommend putting a \n to ensure flushing does not need to be done.
Calling fflush() on stdout before a printf() prompt that contains no '\n' is good practice.
C++ IO causes the output buffer to flush when input functions are invoked. In addition, everytime std::endl is used, it causes an automatic flush of the output buffer, so "works for me" from a C++ programmer is useless in this regard.
You're limited by the human user. He has to see what is on the screen in order to respond, so you have to flush the buffer. I'm not sure why you would think that is a wasted action. Sure, if the user could wait until the buffer is full, that would be great, but that's not realistic in many programs that require user input.
Most C runtime libraries will flush stdout before reading stdin, but I know for a fact that in the old days [e.g. 1980's] fflush was necessary if you wanted input directly after a prompt, because printf would not flush the buffer until a newline appeared, and a call to fgets() or similar would not flush the buffer either.
So if the OP uses for example Turbo C, then it would be necessary. For a compiler produced in the last few years, it's most likely not necessary.
--
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 believe some people have posted before about this. I thought I saw a Linux example where it was needed, but I could be mistaken.
I would still recommend manually fflush(stdout)ing to guarentee the flush actually happens for prompts. Portable code and all that stuff. I'd rather not rely on these types of compiler extensions for something so trivial that barely demands more typing, but is important to the user.