Why cout.flush() does not seem to "work"?

[JiiPee]

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]

JiiPee <n...@notvalid.com> writes:
>I understood that cout flushes only after we call flush().
>But if I run a code (Visual Studio):
>
>cout<<"Start ....\n";

The '\n' causes the flush.

[Barry Schwarz]

On Tue, 24 Nov 2015 19:21:51 +0000, JiiPee <n...@notvalid.com> wrote:

>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.

>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

On many hosted systems, the \n will cause the data to be sent.

>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.

>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]

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;
}

[JiiPee]

On 24/11/2015 19:52, Barry Schwarz wrote:
> On Tue, 24 Nov 2015 19:21:51 +0000, JiiPee <n...@notvalid.com> wrote:
>
>> 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...

> 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.

[JiiPee]

On 24/11/2015 19:52, Barry Schwarz wrote:

> On Tue, 24 Nov 2015 19:21:51 +0000, JiiPee <n...@notvalid.com> wrote:
>
>> 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]

On 24/11/2015 20:09, JiiPee wrote:
> ok, so cout might or might not flush if I do:
> 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

[Geoff]

On Tue, 24 Nov 2015 20:07:40 +0000, JiiPee <n...@notvalid.com> wrote:

>On 24/11/2015 19:52, Barry Schwarz wrote:
>> On Tue, 24 Nov 2015 19:21:51 +0000, JiiPee <n...@notvalid.com> wrote:
>>
>>> 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.

>
>> 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.

[Geoff]

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]

On Tue, 24 Nov 2015 20:03:31 +0000, JiiPee <n...@notvalid.com> wrote:

Don't you think "whenever it feels like it" covers the ability to
flush immediately regardless of the presence or absence of \n?

[Richard]

[Please do not mail me a copy of your followup]

sl...@pacbell.net spake the secret code
<ya35y.105417$ij2....@fx08.iad> thusly:

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]

On 11/25/2015 12:59 AM, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> sl...@pacbell.net spake the secret code
> <ya35y.105417$ij2....@fx08.iad> thusly:
>
>> JiiPee <n...@notvalid.com> writes:
>>> I understood that cout flushes only after we call flush().
>>> But if I run a code (Visual Studio):

^^^^^^^^^^^^^^

>>>
>>> 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]

Alf P. Steinbach wrote:
>
> 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;
}

> CC local.cc; ./a.out
©

--
Ian Collins

[Juha Nieminen]

Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
> 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: ne...@netfront.net ---

[Nobody]

On Tue, 24 Nov 2015 23:59:26 +0000, Richard wrote:

> 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.

[Alf P. Steinbach]

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

[Luca Risolia]

Il 24/11/2015 20:21, JiiPee ha scritto:
> 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]

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]

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 .

[Rosario19]

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]

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]

On 26/11/2015 00:17, Jorgen Grahn wrote:

> On Thu, 2015-11-26, JiiPee wrote:
>> On 25/11/2015 19:41, Luca Risolia wrote:
>>> Il 24/11/2015 20:21, JiiPee ha scritto:
>>>> 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....

[JiiPee]

On 26/11/2015 11:20, Rosario19 wrote:
> On Tue, 24 Nov 2015 20:09:17 +0000, JiiPee wrote:
>
>> On 24/11/2015 19:52, Barry Schwarz wrote:
>>> On Tue, 24 Nov 2015 19:21:51 +0000, JiiPee <n...@notvalid.com> wrote:
>>>
>>>> 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.
> 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]

On 26/11/2015 18:58, JiiPee wrote:
> But even if I cout only character:
>
> 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]

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]

sure, those are the options

[Rosario19]

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