Member Avatar for fesago90

Well, I read that endl 'flushes' the output buffer as opposed to \n.
Now what does that mean (In what way could that be useful)?

  • 9 Contributors
  • 11 Replies
  • 623 Views
  • 4 Years Discussion Span
  • Latest Post Latest Post by seanwalsh1984

Dani AI

Generated

Quick, practical primer and when to care.

std::endl does two things: it inserts a newline and then forces the stream to flush. Writing a newline character (the logical '\n') just inserts the newline and leaves flushing to the stream’s normal rules. As pointed out, flushing is extra work and can be costly if done repeatedly; also highlighted valid cases where flushing a file stream helps reduce data-loss risk. The claim that '\n' is “not portable” (noted by ) is mistaken: text-mode streams perform any platform newline translation for the programmer (CR, LF, CRLF), so '\n' is the correct, portable way to express a newline in C++ source.

When to use a flush:

  • Immediate, interactive feedback (prompts shown before non-standard input, or when the program is reading input from something other than std::cin).
  • Critical logs that must be visible immediately (but remember: flush moves data to the OS kernel buffers; it does not guarantee data is on disk—use an OS-level fsync/FlushFileBuffers for durability).
  • Debugging/diagnostics during crashes or abnormal termination.

Best-practice patterns:

  • Prefer '\n' for normal output and avoid std::endl inside hot loops.
  • Use std::flush (or temporarily std::unitbuf) when an explicit flush is required.
  • If maximum throughput is needed, std::ios::sync_with_stdio(false) and careful use of ties (cin.tie(nullptr)) can help, but avoid mixing C stdio (printf) and C++ streams after turning sync off.

Example usage:

std::cout << "Enter value: " << std::flush;
std::cin  >> value;   // cin is tied to cout by default, so prompts usually appear anyway

Bottom line: prefer '\n' for efficiency; use explicit flushes only where immediate visibility or data-safety demands them.

Recommended Answers

All 11 Replies

Member Avatar for Ravalon

Well, I read that endl 'flushes' the output buffer as opposed to \n.
Now what does that mean (how could that be useful)? Does it make it less or more efficient?

endl calls the flush() method of the stream. That means more work done per use, and it's a sure bet that endl is less efficient than '\n'. It's also a nearly sure bet that the difference isn't enough for you to care. ;)

The poor man's theory behind stream flushing is that you prompt the user to do something and then ask for input. But on some systems the prompt isn't shown until the stream is flushed, ie. all unwritten characters are written to the output device, and then the user doesn't know what to do.

That's the theory, but it doesn't apply in C++ because cin and cout are tied together and any request for input on cin will automatically flush cout. Cool stuff. :) In fact, most of the time you want to flush a stream, it gets flushed for you automatically anyway, and it's redundant to use something that explicitly flushes the stream for you.

commented: thanks ;) +1
Member Avatar for Ancient Dragon

>>In fact, most of the time you want to flush a stream, it gets flushed for you automatically anyway, and it's redundant to use something that explicitly flushes the stream for you.

That may be true of console screens but probably not of file-based streams. That behavior is os dependent -- when the operating system's buffer(s) get flushed to the file system may not occur until the file is closed or when flush() is called. There are a few rare occasions when a file is intentially left open for long periods of time, and calling flush() occasionally helps reduce the possibility of losing data if the os crashes or keeps the file up-to-date in case another process wants to read it.

But I agree that endl should normally be avoided.

Member Avatar for jwenting

no, endl should be the standard way to do things.
\n is not portable, it's a throwback to C.

Member Avatar for ~s.o.s~

no, endl should be the standard way to do things.
\n is not portable, it's a throwback to C.

LF or newline is a character which belongs to the ASCII character set. Is priting out characters using streams non portable ? Cit any one situation which showcases its non portability....

Member Avatar for Infarction

LF or newline is a character which belongs to the ASCII character set. Is priting out characters using streams non portable ? Cit any one situation which showcases its non portability....

Newlines on some systems are done with \r, \n, or \r\n (I forget which goes with which). Hence, non-portable.

Member Avatar for Ene Uran

Take you pick:
Unix OS is '\n'
Windows is '\r\n'
Mac OS is '\r'

Member Avatar for Ravalon

>>In fact, most of the time you want to flush a stream, it gets flushed for you automatically anyway, and it's redundant to use something that explicitly flushes the stream for you.

That may be true of console screens but probably not of file-based streams. That behavior is os dependent -- when the operating system's buffer(s) get flushed to the file system may not occur until the file is closed or when flush() is called. There are a few rare occasions when a file is intentially left open for long periods of time, and calling flush() occasionally helps reduce the possibility of losing data if the os crashes or keeps the file up-to-date in case another process wants to read it.

But I agree that endl should normally be avoided.

I fell into the trap of summarizing something very complex. :) The point is that most of the time you don't need to care. When you do need to care, you probably know that you need to care and how to best use the tools you're given. One person is not the best metric, but I can count the number of times I've needed to flush the stream manually and not flushing it caused problems on one hand. ;)

no, endl should be the standard way to do things.
\n is not portable, it's a throwback to C.

endl is nothing more than a function that prints '\n' and then calls flush() for the stream. If '\n' is not portable, then neither is endl. ;)

Member Avatar for Ancient Dragon

Newlines on some systems are done with \r, \n, or \r\n (I forget which goes with which). Hence, non-portable.

True, but that is handled by the stream implementation. '\n' is interpreted correctly by the stream class. If you check the data that is stored in the file (read the file in binary mode) you will see the conversion:

*nix: '\n'
MS-DOS/MS-Windows: '\r\n'
MAC: '\r'

Ravalon is correct -- using '\n' is completely portable and always has been. The c++ standards did not change that.

Member Avatar for fesago90

endl calls the flush() method of the stream. That means more work done per use, and it's a sure bet that endl is less efficient than '\n'. It's also a nearly sure bet that the difference isn't enough for you to care. ;)

The poor man's theory behind stream flushing is that you prompt the user to do something and then ask for input. But on some systems the prompt isn't shown until the stream is flushed, ie. all unwritten characters are written to the output device, and then the user doesn't know what to do.

That's the theory, but it doesn't apply in C++ because cin and cout are tied together and any request for input on cin will automatically flush cout. Cool stuff. :) In fact, most of the time you want to flush a stream, it gets flushed for you automatically anyway, and it's redundant to use something that explicitly flushes the stream for you.

Thanks for that, I'll say it's enough of what I needed to know for now.
Again, thanks.

Member Avatar for Rashakil Fol

no, endl should be the standard way to do things.
\n is not portable, it's a throwback to C.

How is \n not portable?

Member Avatar for seanwalsh1984

With the ANSI C++ standard, '\n' should be totally portable, but there are old systems, such as MS-DOS 6.22, and old versions of POSIX that may be used in 3rd world countries that may not use the current ANSI standard, but for all intents and purposes in the current world of computing, '\n' should be considered totally portable. This is more a problem when working with old Borland compilers vs. MS managed C++ code. Consider the fact that other languages such as Java and PHP which are platform independent use '\n', as does C#, and they are derived from C as well, but can be run across platforms (MonoMac, MonoDevelop, Moonlight for C#). Just my 0.02

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.