'\n' vs "\n" vs "endl"
I know this has been questioned several times and I have already read some of the related previously discussed threads, but I didn't get the point well. Therefore, I would like to ask my problems here. As far as I know,
1. '\n' is a character like '1' or 'g', and it takes up one byte of the memory and it's faster than the two other alternatives.
2. "\n" is actually "\n\0" which has the null character at the end and it is an array of two characters (actually its process time takes more than the required amount for the first alternative ('\n') because it needs to read two characters instead of one). This one is a bit slower than the first alternative.
If there has been any problem with my explanations so far, please feel free to make any necessary corrections.
3. "endl" is a stream manipulator and it sends a newline character '\n' and flushes the output buffer, so this one has one more implementation step and it takes more tome in comparison with the aforementioned ones. My problem is what exactly "flushing the output buffer" means. I think it means "it empties what is in short-term memory to the screen or file", do you agree? If so, could you please provide an example to clarify this difference for me? I am still confused about what is in the buffer that should be flushed and is it visible in the results? Where should we use this?
Thank you in advance.
1. '\n' is a character like '1' or 'g', and it takes up one byte of the memory and it's faster than the two other alternatives.
2. "\n" is actually "\n\0" which has the null character at the end and it is an array of two characters (actually its process time takes more than the required amount for the first alternative ('\n') because it needs to read two characters instead of one). This one is a bit slower than the first alternative.
If there has been any problem with my explanations so far, please feel free to make any necessary corrections.
3. "endl" is a stream manipulator and it sends a newline character '\n' and flushes the output buffer, so this one has one more implementation step and it takes more tome in comparison with the aforementioned ones. My problem is what exactly "flushing the output buffer" means. I think it means "it empties what is in short-term memory to the screen or file", do you agree? If so, could you please provide an example to clarify this difference for me? I am still confused about what is in the buffer that should be flushed and is it visible in the results? Where should we use this?
Thank you in advance.
Last edited on
| I am still confused about what is in the buffer that should be flushed and is it visible in the results? |
every output stream object holds a buffer (an array of characters), somewhere in memory.
Writing a character to a stream means copying the character to the buffer and incrementing the next pointer (which is a data member of every stream object), that's a fast, simple operation.
When the buffer is full or when a flush is requested, the contents of the buffer are sent to the actual output device (screen, file, pipe, compressed file, network connection, in-memory data structure, whatever the author of the stream have set up). That usually means asking the OS to do some work, and that is relatively slow.
If you are working with std::cout, you don't need to flush it yourself usually because every input from std::cin flushes it for you, so that interactive programs work as expected: you will always see the output before any input is requested. Also calling exit(), ending the main function, and sending output to std::cerr flushes std::cout for you as well. Also, on most systems with default settings, sending just the \n to std::cout flushes it (although in a slightly different sense) without any effort on your part.
You may need a flush if your program has to wait for something other than input, e.g. you're doing a long computation and printing progress so far, or calling system() to wait for some external program.
A single quote represents a character '', a backslash \ represents an un-typeable character. It isn't always faster/as practical when dealing with multiple characters which could have been used within a double quote "". Some things like "strtok" only accept a string of individual characters as the delimiter.
When it comes to "", it wouldn't make sense for any string literal to automatically put a null terminator at the end of it. That's up to the back end. For instance, if you were to assign a string value on initialisation, it'd know the length from that and terminate it, whereas if you were to insert a sub-string somewhere within the string using double quotes, it wouldn't make any sense for it to pre-maturely terminate it. It just wouldn't be practical.
When it comes to "", it wouldn't make sense for any string literal to automatically put a null terminator at the end of it. That's up to the back end. For instance, if you were to assign a string value on initialisation, it'd know the length from that and terminate it, whereas if you were to insert a sub-string somewhere within the string using double quotes, it wouldn't make any sense for it to pre-maturely terminate it. It just wouldn't be practical.
Last edited on
| When it comes to "", it wouldn't make sense for any string literal to automatically put a null terminator at the end of it. |
That's exactly what it does, though.
"\n" has type const char[2] and holds two bytes: '\n' and '\0'
| [flushing the buffer] usually means asking the OS to do some work, and that is relatively slow |
Not only do you have the OS overhead, but consider if you're flushing to file on disk. Writing to disk is easily a THOUSAND times slower than writing to memory. The OS will usually provide another level of buffering but if you're writing a lot of data, flushing every few characters will slow things to a crawl.
Topic archived. No new replies allowed.