Discussion:
Why cout.flush() does not seem to "work"?
(too old to reply)
JiiPee
2015-11-24 19:21:51 UTC
Permalink
I understood that cout flushes only after we call flush().
But if I run a code (Visual Studio):

cout<<"Start ....\n";

<doing something many seconds, like Sleep or a long for-loop>

cout<<"End";
cout.flush();

But this does not work like expected: it straight away prints
"Start...." and then waits some seconds (bce of sleep or for loop) and
then prints "End". why does cout flush immedistely when running the
program even though nothing flushes it?

I am expecting everything to be printed at the end and nothing at the
beginning of the run.
Scott Lurndal
2015-11-24 19:48:46 UTC
Permalink
Post by JiiPee
I understood that cout flushes only after we call flush().
cout<<"Start ....\n";
The '\n' causes the flush.
JiiPee
2015-11-24 20:03:31 UTC
Permalink
Post by Scott Lurndal
Post by JiiPee
I understood that cout flushes only after we call flush().
cout<<"Start ....\n";
The '\n' causes the flush.
But if I take out \n I still get the same result . Here is my code:

int main()
{
int n;
string x;

cout << "start";

std::this_thread::sleep_for(std::chrono::milliseconds(5000));

cout << "finished";
return 0;
}
Geoff
2015-11-24 21:24:08 UTC
Permalink
Post by JiiPee
Post by Scott Lurndal
Post by JiiPee
I understood that cout flushes only after we call flush().
cout<<"Start ....\n";
The '\n' causes the flush.
int main()
{
int n;
string x;
cout << "start";
std::this_thread::sleep_for(std::chrono::milliseconds(5000));
cout << "finished";
return 0;
}
Above is not compilable on my system. I'm using VS2010:

#include <Windows.h>
#include <iostream>
#include <string>

using namespace std;

int main()
{
string x;

cout << "start ";

Sleep(5000);

cout << "finished ";
return 0;
}

The console associated with this process is not blocked by Sleep().
The "start" is immediately transmitted and appears in the window.
The program defines the sequence of events:
cout
sleep
cout
terminate

Since there is no part of the process that blocks output to the
console it will flush the "start", then sleep, then cout again with
program termination producing an automatic flush of all remaining
output. The program is performing as the code specified. I can't think
of a method off-hand that might make the console busy such that it
won't display the output.

\n may or may not produce or influence flushing, only std::endl
guarantees that as far as I know.
Barry Schwarz
2015-11-24 23:36:39 UTC
Permalink
Post by JiiPee
Post by Scott Lurndal
Post by JiiPee
I understood that cout flushes only after we call flush().
cout<<"Start ....\n";
The '\n' causes the flush.
int main()
{
int n;
string x;
cout << "start";
std::this_thread::sleep_for(std::chrono::milliseconds(5000));
cout << "finished";
return 0;
}
Don't you think "whenever it feels like it" covers the ability to
flush immediately regardless of the presence or absence of \n?
--
Remove del for email
legalize+ (Richard)
2015-11-24 23:59:26 UTC
Permalink
[Please do not mail me a copy of your followup]
Post by Scott Lurndal
Post by JiiPee
I understood that cout flushes only after we call flush().
cout<<"Start ....\n";
The '\n' causes the flush.
Nope.

std::endl outputs a newline and then causes a flush.

Reading from an input stream tied to an output stream flushes the
output stream before reading from the input stream.

std::flush causes a flush.

There might be something else too, but I think that's it.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Alf P. Steinbach
2015-11-25 00:30:44 UTC
Permalink
Post by legalize+ (Richard)
[Please do not mail me a copy of your followup]
Post by Scott Lurndal
Post by JiiPee
I understood that cout flushes only after we call flush().
^^^^^^^^^^^^^^
Post by legalize+ (Richard)
Post by Scott Lurndal
Post by JiiPee
cout<<"Start ....\n";
The '\n' causes the flush.
Nope.
std::endl outputs a newline and then causes a flush.
Reading from an input stream tied to an output stream flushes the
output stream before reading from the input stream.
std::flush causes a flush.
There might be something else too, but I think that's it.
For Visual C++, or more generally Microsoft's runtime library, i/o to
the console is immediate, and is flushed one character at a time. That
plays havoc with UTF-8 encoding for output. Which is not as bad as it
sounds, because Windows consoles, down at the API level, do not support
UTF-8 input, so it would be one-way i/o anyway, only output. In typical
Microsoft fashion this is fixed by having some extended functionality
that sets up special mode for the C and C++ standard streams, via their
_setmode function. And /that/ again is not as bad as it sounds, because
even in Unix-land one has to do some configuration to make the wide
streams work, as a minimum calling setlocale( "", LC_ALL ), so, to sum
up, console i/o doesn't work in C or C++ by default. Well, except ASCII.

Cheers,

- Alf
Ian Collins
2015-11-25 05:39:36 UTC
Permalink
Post by Alf P. Steinbach
For Visual C++, or more generally Microsoft's runtime library, i/o to
the console is immediate, and is flushed one character at a time. That
plays havoc with UTF-8 encoding for output. Which is not as bad as it
sounds, because Windows consoles, down at the API level, do not support
UTF-8 input, so it would be one-way i/o anyway, only output. In typical
Microsoft fashion this is fixed by having some extended functionality
that sets up special mode for the C and C++ standard streams, via their
_setmode function. And /that/ again is not as bad as it sounds, because
even in Unix-land one has to do some configuration to make the wide
streams work, as a minimum calling setlocale( "", LC_ALL ), so, to sum
up, console i/o doesn't work in C or C++ by default. Well, except ASCII.
Not necessarily.

On my system, the following "just works":

#include <iostream>

int main()
{
const uint32_t value = 0xa9;

const char lower = 0x80|(value&0x3f);
const char upper = 0xc0|(value >> 6);

std::cout << upper << lower << std::endl;
}
Post by Alf P. Steinbach
CC local.cc; ./a.out
©
--
Ian Collins
Alf P. Steinbach
2015-11-25 13:24:29 UTC
Permalink
Post by Ian Collins
Post by Alf P. Steinbach
For Visual C++, or more generally Microsoft's runtime library, i/o to
the console is immediate, and is flushed one character at a time. That
plays havoc with UTF-8 encoding for output. Which is not as bad as it
sounds, because Windows consoles, down at the API level, do not support
UTF-8 input, so it would be one-way i/o anyway, only output. In typical
Microsoft fashion this is fixed by having some extended functionality
that sets up special mode for the C and C++ standard streams, via their
_setmode function. And /that/ again is not as bad as it sounds, because
even in Unix-land one has to do some configuration to make the wide
streams work, as a minimum calling setlocale( "", LC_ALL ), so, to sum
up, console i/o doesn't work in C or C++ by default. Well, except ASCII.
Not necessarily.
#include <iostream>
int main()
{
const uint32_t value = 0xa9;
const char lower = 0x80|(value&0x3f);
const char upper = 0xc0|(value >> 6);
std::cout << upper << lower << std::endl;
}
Post by Alf P. Steinbach
CC local.cc; ./a.out
©
This is a nice example of what I wrote (so I don't understand the "not
necessarily"), to wit, it avoids using wide streams and therefore
doesn't work in Windows, i.e. it's not portable:


<example>
C:\my\forums\clc++\012>g++ foo.cpp
foo.cpp: In function 'int main()':
foo.cpp:7:38: warning: overflow in implicit constant conversion [-Woverflow
const char lower = 0x80|(value&0x3f);
^
foo.cpp:8:38: warning: overflow in implicit constant conversion [-Woverflow
const char upper = 0xc0|(value >> 6);
^

C:\my\forums\clc++\012>chcp 65001 & a
Active code page: 65001
��

C:\my\forums\clc++\012>_
</example>


The reason for the /two/ odd result characters is that each byte is sent
separately to the console, which therefore interprets each byte separately.

If the program had used wide streams it /could/ have worked in Windows
by adding a translation unit with proper system-specific wide stream
configuration, which in Unix-land would be a call to setlocale.

Here's a program, based on yours, that illustrates the problem for byte
level streams in Windows. To understand it it's necessary to know that
the version of g++ I use, use Microsoft's runtime library, or else an
emulation of that runtime library's quirks and faults. That also has
other problems, but the main problem here is the lack of buffering:


<file "oops.cpp">
#include <stdio.h>
#include <windows.h>

auto main() -> int
{
unsigned const value = 0xA9;
const char utf8_bytes[] = { char( 0xC0|(value >> 6) ), char(
0x80|(value&0x3f) ) };
int const n_bytes = sizeof( utf8_bytes );

// Sending separate bytes to the console:
fwrite( utf8_bytes, 1, n_bytes, stdout );
printf( "\n" );

// Sending the all bytes of an UTF-8 character together:
HANDLE const winout = GetStdHandle( STD_OUTPUT_HANDLE );
WriteFile( winout, utf8_bytes, n_bytes, nullptr, nullptr );
printf( "\n" );
}
</file>

<example>
C:\my\forums\clc++\012>g++ oops.cpp

C:\my\forums\clc++\012>chcp 1252 & a
Active code page: 1252
©
©

C:\my\forums\clc++\012>chcp 65001 & a
Active code page: 65001
��
©

C:\my\forums\clc++\012> _
</example>


Cheers!,

- Alf
Juha Nieminen
2015-11-25 09:25:11 UTC
Permalink
Post by Alf P. Steinbach
For Visual C++, or more generally Microsoft's runtime library, i/o to
the console is immediate, and is flushed one character at a time.
In other words, in typical Windows fashion, they do it as inefficiently
as possible.

--- news://freenews.netfront.net/ - complaints: ***@netfront.net ---
Nobody
2015-11-25 12:24:41 UTC
Permalink
Post by legalize+ (Richard)
There might be something else too, but I think that's it.
If the unitbuf flag is set on the stream, it is flushed after each
operation. By default, this is set for cerr but not for cout.

If the C++ ostream is synchronised with the corresponding C
stdio stream (sync_with_stdio), which is the default for the standard
streams, they share the same buffer.

C requires that stdout is fully buffered if and only if it can be
determined not to refer to an interactive device. If it might refer to an
interactive device, it will be at most line-buffered, meaning that
fputc(stdout,'\n') will flush stdout. AIUI, if cout is sync'd with stdio,
then writing '\n' to cout (or to the underlying filebuf) will also flush
it.
Stefan Ram
2015-11-25 13:07:18 UTC
Permalink
Post by Nobody
Post by legalize+ (Richard)
There might be something else too, but I think that's it.
If the unitbuf flag is set on the stream, it is flushed after each
operation. By default, this is set for cerr but not for cout.
Yes, to clarify the situation for cout: C++ asserts that
»cerr.flags() & unitbuf && wcerr.flags() & unitbuf«, but
leaves it /unspecified/ whether »cout.flags() & unitbuf«.
Barry Schwarz
2015-11-24 19:52:26 UTC
Permalink
Post by JiiPee
I understood that cout flushes only after we call flush().
You understood wrong. For buffered output streams, flushing is
guaranteed to send all the data in the buffer to the device. However,
the system is allowed to send the data or a portion of it any other
time it deems it appropriate.
Post by JiiPee
cout<<"Start ....\n";
<doing something many seconds, like Sleep or a long for-loop>
cout<<"End";
cout.flush();
But this does not work like expected: it straight away prints
"Start...." and then waits some seconds (bce of sleep or for loop) and
On many hosted systems, the \n will cause the data to be sent.
Post by JiiPee
then prints "End". why does cout flush immedistely when running the
program even though nothing flushes it?
It would have been interesting if you had placed a similar delay
between outputting the text and flushing the stream. Then you would
have been able to determine if the cout stream on your system waits
for a flush or a \n.
Post by JiiPee
I am expecting everything to be printed at the end and nothing at the
beginning of the run.
Just to compound matters, the system could behave differently for that
last output if you are sending data to a disk file as opposed to the
monitor.
--
Remove del for email
JiiPee
2015-11-24 20:07:40 UTC
Permalink
Post by Barry Schwarz
Post by JiiPee
I understood that cout flushes only after we call flush().
You understood wrong. For buffered output streams, flushing is
guaranteed to send all the data in the buffer to the device. However,
the system is allowed to send the data or a portion of it any other
time it deems it appropriate.
ok, so I guess a compiler can deside to flush whenever it wants...
Post by Barry Schwarz
It would have been interesting if you had placed a similar delay
between outputting the text and flushing the stream. Then you would
have been able to determine if the cout stream on your system waits
for a flush or a \n.
but there was no delay when I did the first cout (without a flush or
even \n). So flush does not seem to make any difference here.
Geoff
2015-11-24 21:14:11 UTC
Permalink
Post by JiiPee
Post by Barry Schwarz
Post by JiiPee
I understood that cout flushes only after we call flush().
You understood wrong. For buffered output streams, flushing is
guaranteed to send all the data in the buffer to the device. However,
the system is allowed to send the data or a portion of it any other
time it deems it appropriate.
ok, so I guess a compiler can deside to flush whenever it wants...
The compiler doesn't get to choose.

It's the operating system that determines what gets "flushed" and
when. The system can send the output immediately or after some
indeterminate delay which will be a function of what the state of the
system is at that moment. A console window may not be "busy" and
therefore the data appears without delay.
Post by JiiPee
Post by Barry Schwarz
It would have been interesting if you had placed a similar delay
between outputting the text and flushing the stream. Then you would
have been able to determine if the cout stream on your system waits
for a flush or a \n.
but there was no delay when I did the first cout (without a flush or
even \n). So flush does not seem to make any difference here.
This can't be observed in a primitive program such as you have posted.
There is nothing keeping the system "busy" enough to show an
observable delay and you have not bracketed the cout with any timer
with resolution fine enough to measure the delay between the cout and
the appearance of the text on a console.

Furthermore, program termination flushes all buffers so immediate
termination after cout << "finished"; causes immediate output without
delay (or at least measurable delay per above.
JiiPee
2015-11-24 20:09:17 UTC
Permalink
Post by Barry Schwarz
Post by JiiPee
I understood that cout flushes only after we call flush().
You understood wrong. For buffered output streams, flushing is
guaranteed to send all the data in the buffer to the device. However,
the system is allowed to send the data or a portion of it any other
time it deems it appropriate.
ok, so cout might or might not flush if I do:
cout<< "Hello";
at any time.
Vir Campestris
2015-11-24 21:06:17 UTC
Permalink
Post by JiiPee
cout<< "Hello";
at any time.
That's correct. But push a std::endl and it will flush. (but not
_necessarily_ a \n)

See http://en.cppreference.com/w/cpp/io/manip/endl

Andy
Rosario19
2015-11-26 11:20:11 UTC
Permalink
Post by JiiPee
Post by Barry Schwarz
Post by JiiPee
I understood that cout flushes only after we call flush().
You understood wrong. For buffered output streams, flushing is
guaranteed to send all the data in the buffer to the device. However,
the system is allowed to send the data or a portion of it any other
time it deems it appropriate.
cout<< "Hello";
at any time.
in my understand when buffer of stdoud is full there is the flush

in C if one has one string has "\n"
the buffer is fhush when it meet "\n"
if i remember well
JiiPee
2015-11-26 18:58:22 UTC
Permalink
Post by Rosario19
Post by JiiPee
Post by Barry Schwarz
Post by JiiPee
I understood that cout flushes only after we call flush().
You understood wrong. For buffered output streams, flushing is
guaranteed to send all the data in the buffer to the device. However,
the system is allowed to send the data or a portion of it any other
time it deems it appropriate.
cout<< "Hello";
at any time.
in my understand when buffer of stdoud is full there is the flush
But even if I cout only character:

cout<< "s";

it flushes it straight away.
Vir Campestris
2015-11-26 21:33:12 UTC
Permalink
Post by JiiPee
cout<< "s";
it flushes it straight away.
It can flush whenever it wants. There are ways to force it to flush, but
AFAIK no way to make it hold on to characters you've told it to write.
Why would it?

Andy
Öö Tiib
2015-11-26 21:54:48 UTC
Permalink
Post by JiiPee
Post by Rosario19
Post by JiiPee
Post by Barry Schwarz
Post by JiiPee
I understood that cout flushes only after we call flush().
You understood wrong. For buffered output streams, flushing is
guaranteed to send all the data in the buffer to the device. However,
the system is allowed to send the data or a portion of it any other
time it deems it appropriate.
cout<< "Hello";
at any time.
in my understand when buffer of stdoud is full there is the flush
cout<< "s";
it flushes it straight away.
Yes, Alf P. Steinbach already wrote that *Visual Studio* flushes *terminal
output* after every character. There are no output buffer/lazy output.

You must make it clear to yourself what you want. Then it is easy to see
what to do:
* If you want to wait with output then wait. Do not output.
* If you do not care then just output.
* If you want to be sure that output is complete then flush the buffer (or
with C++ streams use std::endl instead of '\r').
JiiPee
2015-11-26 22:07:38 UTC
Permalink
Post by Öö Tiib
Post by JiiPee
Post by Rosario19
Post by JiiPee
Post by Barry Schwarz
Post by JiiPee
I understood that cout flushes only after we call flush().
You understood wrong. For buffered output streams, flushing is
guaranteed to send all the data in the buffer to the device. However,
the system is allowed to send the data or a portion of it any other
time it deems it appropriate.
cout<< "Hello";
at any time.
in my understand when buffer of stdoud is full there is the flush
cout<< "s";
it flushes it straight away.
Yes, Alf P. Steinbach already wrote that *Visual Studio* flushes *terminal
output* after every character. There are no output buffer/lazy output.
You must make it clear to yourself what you want. Then it is easy to see
* If you want to wait with output then wait. Do not output.
* If you do not care then just output.
* If you want to be sure that output is complete then flush the buffer (or
with C++ streams use std::endl instead of '\r').
sure, those are the options
Rosario19
2015-11-27 09:15:49 UTC
Permalink
Post by Rosario19
Post by JiiPee
Post by Barry Schwarz
Post by JiiPee
I understood that cout flushes only after we call flush().
You understood wrong. For buffered output streams, flushing is
guaranteed to send all the data in the buffer to the device. However,
the system is allowed to send the data or a portion of it any other
time it deems it appropriate.
cout<< "Hello";
at any time.
in my understand when buffer of stdoud is full there is the flush
in C if one has one string has "\n"
the buffer is fhush when it meet "\n"
if i remember well
if i understand well there are case
it is useful sys not flush when meet "\n" ...
if one has to do a pipe or interprocess comunication,
it has to flush only when EOF, or buffer full, or explicit flush

Luca Risolia
2015-11-25 19:41:46 UTC
Permalink
Post by JiiPee
I am expecting everything to be printed at the end and nothing at the
beginning of the run.
Consider using std::clog instead of std::cout. Any output sent to the
former is immediately flushed (although this is not the only difference).
JiiPee
2015-11-26 00:03:33 UTC
Permalink
Post by Luca Risolia
Post by JiiPee
I am expecting everything to be printed at the end and nothing at the
beginning of the run.
Consider using std::clog instead of std::cout. Any output sent to the
former is immediately flushed (although this is not the only difference).
But here I was more like wanting to deside myself when to flush
everything. But it seems like Microsoft flushes when it wants.
Jorgen Grahn
2015-11-26 00:17:24 UTC
Permalink
Post by JiiPee
Post by Luca Risolia
Post by JiiPee
I am expecting everything to be printed at the end and nothing at the
beginning of the run.
Consider using std::clog instead of std::cout. Any output sent to the
former is immediately flushed (although this is not the only difference).
But here I was more like wanting to deside myself when to flush
everything. But it seems like Microsoft flushes when it wants.
Well, if I look at your original posting, you wanted to print to cout

Start...
End

but not make it actually print until later, when you flush.

It seems to me that if you want something printed later, you have to
print it later. For example, you can't expect cout to keep a gigabyte
of text, waiting for your permission to actually output it. That's
not its job.

/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
JiiPee
2015-11-26 18:56:20 UTC
Permalink
Post by Jorgen Grahn
Post by JiiPee
Post by Luca Risolia
Post by JiiPee
I am expecting everything to be printed at the end and nothing at the
beginning of the run.
Consider using std::clog instead of std::cout. Any output sent to the
former is immediately flushed (although this is not the only difference).
But here I was more like wanting to deside myself when to flush
everything. But it seems like Microsoft flushes when it wants.
Well, if I look at your original posting, you wanted to print to cout
Start...
End
but not make it actually print until later, when you flush.
It seems to me that if you want something printed later, you have to
print it later. For example, you can't expect cout to keep a gigabyte
of text, waiting for your permission to actually output it. That's
not its job.
/Jorgen
ye sure I could print it later. Not sure why would I want to wait ...
but there might be situations where you want to wait.. not sure...
Just wanted some logic for this
JiiPee
2015-11-26 18:56:53 UTC
Permalink
Post by Jorgen Grahn
Post by JiiPee
Post by Luca Risolia
Post by JiiPee
I am expecting everything to be printed at the end and nothing at the
beginning of the run.
Consider using std::clog instead of std::cout. Any output sent to the
former is immediately flushed (although this is not the only difference).
But here I was more like wanting to deside myself when to flush
everything. But it seems like Microsoft flushes when it wants.
Well, if I look at your original posting, you wanted to print to cout
Start...
End
ye sure in that example we want it like that. But am talking generally....
Continue reading on narkive:
Loading...