For console it seems text is immediately sent to the console after a cout statement.. so even if you were to flush.. what is there to be flushed? All the output is where it is!.. It's confusing..
Printable View
For console it seems text is immediately sent to the console after a cout statement.. so even if you were to flush.. what is there to be flushed? All the output is where it is!.. It's confusing..
Some systems only print to the console when a newline character appears, plus you can turn buffering on and off via unitbuf.
Normally if you're using a modern operating, like Windows, then the text is not sent to the "console" until something triggers a flush. There are several things that trigger a flush in C++ programs.Quote:
For console it seems text is immediately sent to the console after a cout statement..
1. You issue a manual flush of the stream with either something like std::cout.flush(), or std::cout.endl().
2. In normal operation of std::cout encountering an input operation will first flush() the output stream.
3. The output stream fills to capacity also causes a flush() of the stream.
Newline as in endl or inclusive of "\n" as well? So if unitbuf makes it so that there is a flush after every insertion, doesn't that mean that we're flushing when it's really not necessary though, so would that have practical purposes?Quote:
Originally Posted by tabstop
From what I have read, flush is required to send the data from the buffer to the output, which is the console in this case. Suppose I do not write a manual flush, do not use an input operation, do not fill the output stream to the brim, but still whatever I had typed in with cout goes to the console.. But there was no flush?Quote:
Originally Posted by jimblumberg
If flush is not required to make sure data goes to the console, then what would be it's practical purpose?
A flush is required in normal operation of the standard output stream (cout).Quote:
If flush is not required to make sure data goes to the console, then what would be it's practical purpose?
The three items I listed above are not the only reason for the standard output stream to be flushed. Another cause is when a program ends normally all streams are flushed then closed.
The endl() function differs from the '\n' character. The new line character doesn't cause a flush of the stream it is just a normal character. The endl() function prints a new line character then flushes the stream.Quote:
Newline as in endl or inclusive of "\n" as well?
endl is a flushing operation by definition. '\n' just puts a new-line character in the output stream. C had the distinction between no buffering (immediate output), line buffering (output on new-line), and fully buffered (output only on explicit flush or full buffer), and stdout would default to one of the first two depending on system (but I seem to recall seeing line buffering more often). The C++ unitbuf would appear to match up with no buffering, and I don't see an option that corresponds to line buffering explicitly. The C++ standard seems to say that unitbuf should be off by default, but on my Win10 machine at any rate, that is kind of broken -- the old MSVCRT that my gcc uses doesn't do buffering at all; using VS you can see a delay but eventually things get printed anyway. For instance, with the codeQuote:
Originally Posted by Nwb
a g++-compiled executable will immediately print "Printing"; a Visual Studio-compiled executable will show "Printing" after about four seconds. (In neither case should "Printing" ever appear, of course.)Code:#include <iostream>
int main(void) {
std::cout << std::nounitbuf << "Printing";
while(1) ;
return 0;
}
I'm using VS 2017 and it seems to print "Printing" immediately. Does that mean my system is not buffering? Is buffering necessary for output, what is the point of it? Does this mean my system won't buffer for file io as well or this is only for console?
Also that while loop is taking up an entire core of my CPU, if I were to use multithreading, that wouldn't mean more than one cores would be used.. right?
I'm guessing that MS has decided that it isn't going to bother implementing buffering completely/correctly, at least for the console. Buffering isn't necessary for output, especially to the console, but for file IO it can be quite a big thing indeed (since file IO can be pretty slow, especially if you're using something like a mapped drive that isn't necessarily even in the same building as you are right now). I'm going to assume without testing that you do have buffering for file IO, since it would be ludicrous if you didn't.Quote:
Originally Posted by Nwb
This thing only is one process, so that should be it.Quote:
Originally Posted by Nwb
So buffering is better than no buffering because it's faster, when we talk about file input? What's the convention for flushing file output, do I flush after every line or after say a list of consecutive statements (like suppose I had to print 10 lines worth of text about some kind of purchase) or do I just rely on .close() to flush.
What kind of issues could I run into which makes flush an important thing as opposed to only flushing before closing the file? Is it negligible, and could the issue be in between file input statements too (if such problems do not happen then I can flush at the end of consecutive printing statements instead of every line, that's why I'm asking)?
What's the length of the output buffer, could I edit the length and what happens if the length is exceeded how would I know if that happened and how does the buffer react?
endl is equivalent to "\n"<<flush right? They're the same exact thing, neither of them is preferred over the other in terms of performance?
Oh and also most vBulletin forums I've seen have a spoiler BB code, this one doesn't.. any specific reason?
By the way thanks a lot for baring with me! :wink:
When did we start talking about file input? I thought we were talking about the flush() function, that only works with output streams.Quote:
So buffering is better than no buffering because it's faster, when we talk about file input?
By the way the standard input stream is usually buffered so that you can use the backspace key to "delete" keystrokes. If the standard input wasn't buffered it would be difficult to modify the input before your program sees the input.
That depends, most of the time you can just rely on the normal flush triggers, such as closing the file and the filling of the output buffer. However sometimes it is desirable to manually flush() the output buffer at certain intervals like the end of the line, when an entire record has been written. Manually flushing a stream can be expensive in time but it can be invaluable when used to prevent data loss.Quote:
What's the convention for flushing file output, do I flush after every line or after say a list of consecutive statements (like suppose I had to print 10 lines worth of text about some kind of purchase) or do I just rely on .close() to flush.
No they are not the same exact thing, and if you're totally interested in performance then '\n' is preferred since it doesn't flush the stream.Quote:
endl is equivalent to "\n"<<flush right? They're the same exact thing, neither of them is preferred over the other in terms of performance?
The default length of the output buffer is implementation defined, it could be somewhere between 0 and the maximum size that can be held in the fpos_t type (inclusive). Yes you can alter the size of the buffer but this alteration usually must be done before you try to use the stream. If you enter more characters than can be accommodated by the buffer the buffer is flushed when the buffer reaches capacity.Quote:
What's the length of the output buffer, could I edit the length and what happens if the length is exceeded how would I know if that happened and how does the buffer react?
The convention for flushing file output is that you don't -- the system sets the buffer at what it believes to be the optimum amount to write out in one go based on how the disk is organized -- unless you need something real-time-like (e.g. one process is writing to a file that another process is reading from) or you are paranoid about the program dying unexpectedly and some amount of work getting lost. C has a BUFSIZ constant, but it's not supposed to be something you can change as I understand it.
Correct it is a constant after all.Quote:
C has a BUFSIZ constant, but it's not supposed to be something you can change as I understand it.
But you can change the C++ stream buffers size, but as you said, until someone really knows what they're doing they should leave the buffer size alone so I won't go into detail here on how to change that size. The compiler makers are quite good at selecting the correct values, most of the times
Could I come across a situation where my program dies unexpectedly or that's negligible? Thanks
That depends on how good you are at programming, as most of the situations where your program dies unexpectedly are caused by programmer error (getting stuck in an infinite loop, walking off the end of an array, mis-reading an input file...).Quote:
Originally Posted by Nwb