No, why? The
fflush function, as well as all "flush" methods are only for write-only or read/write streams/files, they write (commit) all unwritten data from the buffer to the file; this is related to buffering; in other words, after the call, the data written to the file is synchronized with the buffer. This is totally unrelated to read operations.
Your "does that space compensate the enter key?" is not clear. The space has nothing to do with "enter". Your code sample also does not imply any "enter". You press enter when you complete entering data. I must say that all "scan" methods of reading are pretty delicate; you need to have in your actual stream some data written exactly as expected by your format string(s); moreover, it's apparent that the result of any read operation depends on what was done by the previous
scanf. Perhaps you need to experiment with it a bit and, if something is still unclear, describe what exactly you want to achieve, the structure of data to be achieved, or the sequence of the operations on entering data.
But I would give you one simple practical advice. I would not mess with
scanf at all. We have other questions here on CodeProject, many people have been much confused, by a good reason. Instead, I would simply enter data by single lines: prompt-enter, prompt-enter… On each step, you get a whole line entered. You write prompts "Enter this and that", and call
gets_s. The use enters the whole line and presses "Enter". Then you can parse the string obtained using
sscanf_s. Handle the problems, and so on. I think such sequence is much easier to understand and maintain.
Please see:
http://en.cppreference.com/w/c/io/gets[
^],
https://msdn.microsoft.com/en-us/library/t6z7bya3.aspx[
^].
Also, be sure to use
security-enhanced variants of all those functions. For example, don't use
gets or
scanf, use
gets_s and
scanf_s, and so on. Please see:
https://msdn.microsoft.com/en-us/library/8ef0s5kh.aspx[
^].
Now, some more on interactive input. Perhaps you really need to lean it all. But I would not take it too serious. If you look at existing really useful console-only applications, such as system utilities, they rarely use interactive input. The relatively rarely used class of such interactive console-only applications usually provides fully-fledged command interpreter behavior. All other applications are much simpler: they accept all the input at once, in the
command line. If some portions of data are too big for writing in a command line, one or more parameters are file name, so the use adds more complicated data in a file and uses the file for entering data. The interactive input like yours is too inconvenient to the users; one mistake may cause the user to start over, and so on. Try not to get sunken in it.
—SA
Submit an article or tip