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)?
fesago90 0 Newbie Poster
Ravalon 62 Posting Whiz in Training
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.
fesago90 commented: thanks ;) +1
Ancient Dragon 5,243 Achieved Level 70 Team Colleague Featured Poster
>>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.
jwenting 1,889 duckman Team Colleague
no, endl should be the standard way to do things.
\n is not portable, it's a throwback to C.
~s.o.s~ 2,560 Failure as a human Team Colleague Featured Poster
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....
Infarction 503 Posting Virtuoso
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.
Ene Uran 638 Posting Virtuoso
Take you pick:
Unix OS is '\n'
Windows is '\r\n'
Mac OS is '\r'
Ravalon 62 Posting Whiz in Training
>>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. ;)
Ancient Dragon 5,243 Achieved Level 70 Team Colleague Featured Poster
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.
fesago90 0 Newbie Poster
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.
Rashakil Fol 978 Super Senior Demiposter Team Colleague
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?
seanwalsh1984 0 Newbie Poster
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.