Both serve the same purpose, putting a new line. The only difference is that endl causes flushing of the output buffer everytime it is called where as ‘\n’ does not.
So, if you are writing al the alphabets of English to a file using the following code,
#include
#include
using namespace std;
int main()
{
ofstream MyFileStream(“Alphabets.txt”, ios:: out);
for (char Index = ‘A’; Index <= 'Z'; ++Index)
{
MyFileStream << Index << endl;
}
return 0;
}
[/sourcecode]
the output buffer will be flushed 26 times while the same code with ‘\n’ instead of endl will cause it to be flushed only once and that is when the program exits (assuming that the output buffer is larger than 26 bytes).
Some Background Info
- Anything to be output is first queued into an output buffer and written to the device (hard disk, monitor etc…) when the queue is full. Of course, this is to ensure speed of execution as the access to the external device is less frequent.
- If you are in a situation where you have to avoid buffering, you can use std::endl instead of ‘\n’. An example of the above situation is when you are using old style debugging using multiple cout statements between code lines to see where exactly a crash occurs.
This site has been moved to http://techievibes.com 
Thank you, I did not know this. I have always had this feeling that my code ran faster when using \n rather than endl (when outputting a couple hundred-thousand lines), but I had always written it off as superstition.
Alexander, use a high res timer instead to verify. Your internal body clock does not have a very high resolution 😉 gl & hth
You have got to be kidding me right? \n will give you a better performance? How about you try this sample program.
#include
using namespace std;
int main()
{
for (unsigned short int i = 0; i <= 50000; ++i)
{
cout << i;
//cout << "\n";
cout << endl;
}
return 0;
}
run this three times and work out the average speed, then comment out the endl line and uncomment the \n line and do the same. The \n was .029 seconds faster with writing 50000 lines, how many lines are output in your typical program?
Dillon: imagine that instead of writing to standard out, you write to a file in a floppy disk ? I’d guess there would be some order of magnitude differences.
doom_Oo7: Not necessarily. Don’t forget that the filesystem itself does buffering as well. Flush only flushed the STL buffers. It does not imply a sync afaik.
What the hell does flush mean. Email me at d.master51@yahoo.com
Man I hate the C++ iostream so much I created my own library called Jav/File.h. It has three main classes. File, rFile and wFile. no virtual inheritance or virtual functions. No string to decide write mode or enumerated flags; which leads to runtime overhead. File is set for read and write, rFile is only for reading and wFile for writing. temporary and new files are created with special functions that return a File object. Surprisingly java api’s do the same. My library is very close to the OS file system. These objects only carry a file descriptor no buffers. But to implement a buffer is super easy. any old array will do. And I also have a Buffer structure that my File types are designed to work with. and they can also accept any void pointer. Every hardware functionality is provided to you as files. Terminal, printer, directory, reg files. So I dont need to supersede special Files for each. My Files can handle any File implementation. And the part is You can go File terminal = getTerminal(); and use one file to read AND write the terminal. No need for that unneccessary stuff.
Just wanted to emphasize why I hate iostream. It is too inconsistent. At one point every thing you cout is printed right away, and sooner or later you experience buffer behaviour. Plus all the inconsistencies or bugs in the fstream library. There library is hard to use and does unneccessary things. My app should go hay wire and crash because I entered some character into an integer. And the method to recover from it is similar to OpenGl pipeline.
My File classes all can convert to bool to check if file is open. However it sees data as raw. For formatted data one can inherit from Buffer a FormattedBuffer. However I just use sprintf to write to my buffer. But I guess I should implement a FormattedBuffer to make my library a one stop shop. which will handle errors much better than iostream. I build my libraries for ease of use and learning, just like SFML.