-3

Flush happens in the following cases:

  • std::cerr
  • std::cin
  • program termination
  • in many implementations, standard output is line-buffered, meaning "\n" flushes anyway

So it seems in most regular programs, std::endl is basically unnecessary, but it's used almost everywhere.

user5282870
  • 21
  • 2
  • 2
    What do you suppose the user needs to do with those implementations where `\n` doesn't flush anyway? – user541686 Aug 30 '15 at 22:42
  • Nothing. The cases in which explicit flushes are required are rare. – user5282870 Aug 30 '15 at 22:48
  • 1
    @user5282870: No, they aren't rare. Basically any time you are putting debugging output to std::cout you should use std::endl so that if the program crashes right after that and terminates abnormally the diagnostics will already have been flushed. – Chris Beck Aug 30 '15 at 22:51
  • When do you justify using std::cout for debugging information? – user5282870 Aug 30 '15 at 22:52
  • 1
    Maybe you have different debugging info going out on std::cerr and you are piping the streams into two separate log files, so as not to make the logs unreadable with formatting, and putting time stamps in the logs. – Chris Beck Aug 30 '15 at 22:53
  • Here's another example. Suppose you want to make a function that outputs a diagnostic to a given `std::ostream &`, to make it all more configurable. If it turns out it's `std::cerr` , or a stringstream or something, then you don't need to flush, but if it turns out its `std::cout` then it might not flush. So you should use `std::endl` in a generic context with `ostream`'s. – Chris Beck Aug 30 '15 at 22:57
  • Your logic is circular. Basically you're saying just flush anytime ostream is involved (this will apply to fstream, cout, ...) – user5282870 Aug 30 '15 at 22:59
  • It's not circular -- its because the standard doesn't guarantee that ostream will flush when I write to it, and indeed on many real platforms it doesn't. So when the stream could be `std::cout`, if it's important that it get flushed, `std::endl` is pretty convenient. It's as simple as that. – Chris Beck Aug 30 '15 at 23:03
  • I listed in my questions times when it is flushed. Again, you're saying "because it's not always flushed, flush everywhere". – user5282870 Aug 30 '15 at 23:04
  • User prompt didn't get flushed. Program waiting for user input. User gets no feedback, goes for coffee to give program time to get sorted out, comes back, swears at programmer, kills stalled program. – user4581301 Aug 30 '15 at 23:05
  • 3
    No. When you want a `\n` *and* you want to flush, use `std::endl`. It really is that simple. – juanchopanza Aug 30 '15 at 23:07
  • Any operation with std::cin will flush... so your hypothetical scenario wouldn't happen. – user5282870 Aug 30 '15 at 23:08
  • @juanchopanza There is no need to be so patronizing. I already know what std::endl does, thanks. – user5282870 Aug 30 '15 at 23:19
  • 1
    Then I can't understand why you ask if it is redundant. – juanchopanza Aug 30 '15 at 23:22
  • @user5282870 Please don't get aggressive on experts comments! That's neither professional, nor constructive to get concise answers. – πάντα ῥεῖ Aug 30 '15 at 23:42
  • I'm done with this site. Good bye. – user5282870 Aug 30 '15 at 23:45
  • @user5282870 Stupid kind of rage quit. You don't get the responses you expect? Your question has been answered and you didn't even received downvotes or close votes? Please go back on reading the tour and more material available from the help center. I can't understand your behavior or attitude. – πάντα ῥεῖ Aug 30 '15 at 23:56

2 Answers2

11

std::cerr

But what if I do not want to write to stderr, but rather stdout?

std::cin

But what if I just want to give the user some status update and do not want any input?

program termination

As above, what if I want to tell the user something before the program is done?

in many implementations, standard output is line-buffered, meaning "\n" flushes anyway

But what about the platforms that don't? Regardless of whether or not such a platform currently exists, I want my code to work as intended as defined by the standard, not as by "meh, will probably be fine on all implementations".

If all of the above apply (the fourth point actually always applies), you need to flush "by hand". If the flush gets handled by one of the first three, you don't.

Baum mit Augen
  • 49,044
  • 25
  • 144
  • 182
  • "I want my code to work as intended as defined by the standard" Implementation specific behavior is defined by the standard. But what I'm asking "is it redundant", "it's defined by the standard" doesn't answer that. – user5282870 Aug 30 '15 at 23:02
  • @user5282870 No, implementation specific behavior is either defined by the implementation or not at all, not by the standard. The standard merely allows it to exist in certain cases. There is no reason to write non-portable code just because the compiler (in that exact version) you use generates code that does what you want. – Baum mit Augen Aug 30 '15 at 23:06
  • 2
    Besides, std::endl is a good idiom. Those, who read your code should understand it as "here I want to output a newline char and flush the output". If you write just '\n', it could be (perhaps) seen as "I need a newline, and I don't care about flush". – Mikhail Maltsev Aug 30 '15 at 23:13
  • I think you're confused. The standard "allows" undefined behavior to exist but doesn't "define" it. Implementation-specific behavior follows from a set of allowable behaviors but the compiler is required to document it. – user5282870 Aug 30 '15 at 23:14
  • @user5282870 You should notice, that _"undefined behavior"_ is the wrong term. It's not in play for what you're asking about. – πάντα ῥεῖ Aug 30 '15 at 23:49
4

So it seems in most regular programs, std::endl is basically unnecessary, but it's used almost everywhere.

No it's not redundant, since implementation of flushing along '\n' isn't mandated by the standard. That's just an implementation specific behavior, while the behavior of std::endl is always clearly defined.

πάντα ῥεῖ
  • 1
  • 13
  • 116
  • 190
  • The only response that addresses the question directly without self-aggrandizing fluff. Thanks. – user5282870 Aug 30 '15 at 23:22
  • 3
    @user5282870 _"without self-aggrandizing fluff"_ Well, I can't see that so much on the other answer. Primary reason I'm straight may be I'm a bit limited in typing from my tablet ;-) ... – πάντα ῥεῖ Aug 30 '15 at 23:33