5 ms·

Don’t optimize prematurely, especially since debugging time is a factor here. If a long-running program crashes, a missing flush can be the difference between

Don’t optimize prematurely, especially since debugging time is a factor here. If a long-running program crashes, a missing flush can be the difference between seeing or not seeing an important detail that preceded the crash. Instead of going straight to the cause, you might be wasting time exploring something that happened a bit earlier, or you may be forced to rerun the long program again to see the same issue with better logging. Then there’s the inconsistency aspect; if you become used to "\n", and see it “work” all the time for streams that happen to go to the terminal, you will be confused when “the same” thing does not have the same behavior for a file stream. Use the abstraction ("endl") until you know you need it to be different.

topspin 10y ago
Working around a broken API is not premature optimization. Stroustrup et al. point out the same problem with std::endl[1] and advise the same remedy as the presentation linked here. Conflating EOL with flush() was a mistake the moment it was first written. Systems programming languages aren't about easy troubleshooting. C/C++ APIs should be performant by default because when they are not we end up working around them, often badly. If I want the stream flushed I'll configure it to behave as such or I'll call flush explicitly. Any other mindset belongs in Python, Java or some other higher level language. [1] https://github.com/isocpp/CppCoreGuidelines/issues/357#issuecomment-153515258 https://github.com/isocpp/CppCoreGuidelines/issues/357#issue...
- lomnakkus 10y ago
  > If I want the stream flushed I'll configure it to behave as such or I'll call flush explicitly. Any other mindset belongs in Python, Java or some other higher level language. This is a bit unfair to HLLs, IMO. Flushing to disk can add unacceptable overhead even for, say, Python. (Particularly on spinning rust, but...). The short and long of it is that "endl" should probably be deprecated in the standard and a good replacement created. ("std::newline"? Maybe we could just specify it as "\n" and get rid of the whole text/binary distinction that another poster on this topic was rightly complaining about.)
- makecheck 10y ago
  I’m not defending the implementation (I hate most of std::iostream), just that "\n" is not exactly equivalent so switching to that may cause surprising behavior and create problems. Auto-flush has its uses. If the main purpose of a program is to generate output then it ought to know what it’s doing anyway and know how to avoid poor performance. For most programs, I’d say that Unix rules of thumb apply: if you are already trying to be “silent on success”, your program will either print nothing or maybe an error or two and not have to worry about print performance. If your program might only print one error and that doesn’t even show up because a flush didn’t happen before a crash, there is a big problem.

topspin 10y ago

Working around a broken API is not premature optimization. Stroustrup et al. point out the same problem with std::endl[1] and advise the same remedy as the presentation linked here. Conflating EOL with flush() was a mistake the moment it was first written. Systems programming languages aren't about easy troubleshooting. C/C++ APIs should be performant by default because when they are not we end up working around them, often badly. If I want the stream flushed I'll configure it to behave as such or I'll call flush explicitly. Any other mindset belongs in Python, Java or some other higher level language. [1] https://github.com/isocpp/CppCoreGuidelines/issues/357#issuecomment-153515258 https://github.com/isocpp/CppCoreGuidelines/issues/357#issue...

lomnakkus 10y ago
> If I want the stream flushed I'll configure it to behave as such or I'll call flush explicitly. Any other mindset belongs in Python, Java or some other higher level language. This is a bit unfair to HLLs, IMO. Flushing to disk can add unacceptable overhead even for, say, Python. (Particularly on spinning rust, but...). The short and long of it is that "endl" should probably be deprecated in the standard and a good replacement created. ("std::newline"? Maybe we could just specify it as "\n" and get rid of the whole text/binary distinction that another poster on this topic was rightly complaining about.)
makecheck 10y ago
I’m not defending the implementation (I hate most of std::iostream), just that "\n" is not exactly equivalent so switching to that may cause surprising behavior and create problems. Auto-flush has its uses. If the main purpose of a program is to generate output then it ought to know what it’s doing anyway and know how to avoid poor performance. For most programs, I’d say that Unix rules of thumb apply: if you are already trying to be “silent on success”, your program will either print nothing or maybe an error or two and not have to worry about print performance. If your program might only print one error and that doesn’t even show up because a flush didn’t happen before a crash, there is a big problem.