Many C++ books contain example code like this...
std::cout << "Test line" << std::endl;
...so I've always done that too. But I've seen a lot of code from working developers like this instead:
std::cout << "Test line\n";
Is there a technical reason to prefer one over the other, or is it just a matter of coding style?
'\n'
.
endl
statement. Especially if you are writing a lot of short lines or as I have often seen single characters to a file. The use of endl
is know to kill networked file systems like NFS.
The varying line-ending characters don't matter, assuming the file is open in text mode, which is what you get unless you ask for binary. The compiled program will write out the correct thing for the system compiled for.
The only difference is that std::endl
flushes the output buffer, and '\n'
doesn't. If you don't want the buffer flushed frequently, use '\n'
. If you do (for example, if you want to get all the output, and the program is unstable), use std::endl
.
The difference can be illustrated by the following:
std::cout << std::endl;
is equivalent to
std::cout << '\n' << std::flush;
So,
Use std::endl If you want to force an immediate flush to the output.
Use \n if you are worried about performance (which is probably not the case if you are using the << operator).
I use \n
on most lines.
Then use std::endl
at the end of a paragraph (but that is just a habit and not usually necessary).
Contrary to other claims, the \n
character is mapped to the correct platform end of line sequence only if the stream is going to a file (std::cin
and std::cout
being special but still files (or file-like)).
cout
is tied to cin
, meaning that if you read input from cin
, cout
will be flushed first. But if you want to display a progress bar or something without reading from cin
, then sure, flushing is useful.
operator<<
isn't performant, or what alternative to use for performance? Please point me to some material to understand this further.
sync_with_stdio(false)
and don't flush your output continuously. Let the library work out when to do it. stackoverflow.com/a/1926432/14065
sync_with_stdio
makes iostreams as fast as stdio. It does not
There might be performance issues, std::endl
forces a flush of the output stream.
There's another function call implied in there if you're going to use std::endl
a) std::cout << "Hello\n";
b) std::cout << "Hello" << std::endl;
a) calls operator <<
once.
b) calls operator <<
twice.
std::cout << "Hello" << "\n";
?
<<
would be 2 in the case a as well, thus I wouldn't claim the need for one or two <<
(or two function calls in general) be a difference between \n
and endl
.
I recalled reading about this in the standard, so here goes:
See C11 standard which defines how the standard streams behave, as C++ programs interface the CRT, the C11 standard should govern the flushing policy here.
ISO/IEC 9899:201x 7.21.3 §7 At program startup, three text streams are predefined and need not be opened explicitly — standard input (for reading conventional input), standard output (for writing conventional output), and standard error (for writing diagnostic output). As initially opened, the standard error stream is not fully buffered; the standard input and standard output streams are fully buffered if and only if the stream can be determined not to refer to an interactive device. 7.21.3 §3 When a stream is unbuffered, characters are intended to appear from the source or at the destination as soon as possible. Otherwise characters may be accumulated and transmitted to or from the host environment as a block. When a stream is fully buffered, characters are intended to be transmitted to or from the host environment as a block when a buffer is filled. When a stream is line buffered, characters are intended to be transmitted to or from the host environment as a block when a new-line character is encountered. Furthermore, characters are intended to be transmitted as a block to the host environment when a buffer is filled, when input is requested on an unbuffered stream, or when input is requested on a line buffered stream that requires the transmission of characters from the host environment. Support for these characteristics is implementation-defined, and may be affected via the setbuf and setvbuf functions.
This means that std::cout
and std::cin
are fully buffered if and only if they are referring to a non-interactive device. In other words, if stdout is attached to a terminal then there is no difference in behavior.
However, if std::cout.sync_with_stdio(false)
is called, then '\n'
will not cause a flush even to interactive devices. Otherwise '\n'
is equivalent to std::endl
unless piping to files: c++ ref on std::endl.
They will both write the appropriate end-of-line character(s). In addition to that endl will cause the buffer to be committed. You usually don't want to use endl when doing file I/O because the unnecessary commits can impact performance.
Not a big deal, but endl won't work in boost::lambda.
(cout<<_1<<endl)(3); //error
(cout<<_1<<"\n")(3); //OK , prints 3
If you use Qt and endl
, you could accidentally end up using an incorrect endl
which gives you very surprising results. See the following code snippet:
#include <iostream>
#include <QtCore/QtCore>
#include <QtGui/QtGui>
// notice that there is no "using namespace std;"
int main(int argc, char** argv)
{
QApplication qapp(argc,argv);
QMainWindow mw;
mw.show();
std::cout << "Finished Execution!" << endl;
// This prints something similar to: "Finished Execution!67006AB4"
return qapp.exec();
}
Note that I wrote endl
instead of std::endl
(which would have been correct) and apparently there is a endl
function defined in qtextstream.h (which is part of QtCore).
Using "\n"
instead of endl
completely sidesteps any potential namespace issues. This is also a good example why putting symbols into the global namespace (like Qt does by default) is a bad idea.
using namespace std;
?? :-)
using namespace std;
. It is considered bad practice. See Why is “using namespace std;” considered bad practice?
Something that I've never seen anyone say is that '\n'
is affected by cout formatting:
#include <iostream>
#include <iomanip>
int main() {
std::cout << "\\n:\n" << std::setw(2) << std::setfill('0') << '\n';
std::cout << "std::endl:\n" << std::setw(2) << std::setfill('0') << std::endl;
}
Output:
\n:
0
std::endl:
Notice, how since '\n'
is one character and fill width is set to 2, only 1 zero gets printed before '\n'
.
I can't find anything about it anywhere, but it reproduces with clang, gcc and msvc.
I was super confused when I first saw it.
cout
/ofstream
(I have not tested ofstream
on windows). Neither endl
nor \n
produce the carriage return when passed through xxd
on linux. Did you reply to a wrong answer? You say "Like others pointed out", but you are the only comment here.
With reference This is an output-only I/O manipulator.
std::endl
Inserts a newline character into the output sequence os and flushes it as if by calling os.put(os.widen('\n'))
followed by os.flush()
.
When to use:
This manipulator may be used to produce a line of output immediately,
e.g.
when displaying output from a long-running process, logging activity of multiple threads or logging activity of a program that may crash unexpectedly.
Also
An explicit flush of std::cout is also necessary before a call to std::system, if the spawned process performs any screen I/O. In most other usual interactive I/O scenarios, std::endl is redundant when used with std::cout because any input from std::cin, output to std::cerr, or program termination forces a call to std::cout.flush(). Use of std::endl in place of '\n', encouraged by some sources, may significantly degrade output performance.
Success story sharing
::std::cerr
instead of::std::cout
since it's unbuffered and flushed with each and every output operation.stderr
is for "errors". Rather, it's for out-of-band diagnostic messages, if you will. It should be possible to say./prog > file
and store only the true program payload, but the program may like to output a lot more status information, even in normal interaction.