12 ms·

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 pre

by topspin 11y 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 11y 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 11y 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.

by topspin 11y ago

lomnakkus 11y 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 11y 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.