And what will happen to this more compact code when stdin will be redirected to read from file and actually hits the EOF?
Getting code shorter by adding more bugs is not a good way to program
Printable View
where in his code is he redirecting stdin to read from a file (unless you mean waiting for the EOF to to be hit via the terminal)? His objective was to get the junk out of the input buffer and clean it up. To that end he can read up to the '\n' after each input. Sure he could add the EOF to that as well to that macro, just seems like overkill IMHO.
I agree whole heartedly, the objective on my part wasn't to offer a quick fix and forget potential future issues, it was to generate compact code for the task at hand. Why declare a long, when a int with do?Quote:
Getting code shorter by adding more bugs is not a good way to program
The redirection can happen from the terminal/console/command prompt, not just the code.Quote:
Originally Posted by caroundw5h
vart's point is about correctness. It might be a little paranoid, but the "overkill" will have no impact on performance anyway, and remains readable.Quote:
Originally Posted by caroundw5h