0

I've been learning how flushing works with cout, so I decided to perform this quick test.

#include <iostream>
#include <unistd.h>

using namespace std;

int main()
{
    cout << "Line 1..."; // OR cout << "Line 1..." << flush;

    usleep(500000);

    cout << "\nLine 2" << endl;

    cout << "Line 3" << endl ;

    return 0;
}

In the case that is presented above, the expected output is for:
Line 1...
Line 2
Line 3
to print out altogether after some delay. However, in the scenario in which "<< flush;" is included, the expected result is for Line 1 to print immediately, then after some delay, Line 2 and Line 3 print.

These expected outputs ONLY occur when I compile my program on a Linux machine using the command:

g++ -o myFile.out myFile.cpp -Wall

Then run it using: 

./myFile.out

When I run these same code pieces on my windows machine, line 1 is ALWAYS displayed immediately, regardless of the insertion of "<< flush;". Why does this happen?

It should be noted that on my windows machine, I am compiling and running my code through codeblocks x64. According to Codeblocks Settings > Compiler > Toolchain Executables, my C++ compiler is "mingw32-g++.exe". Isn't this the same compiler as running g++ on Linux as I did earlier? Thanks!

SuperGoA
  • 225
  • 1
  • 2
  • 9
  • 4
    The standard doesn't actually require the output to be buffered until `std::flush` (or equivalent) is passed, only that those objects will cause it to flush when passed to the stream. The implementation can flush whenever is pleases. – François Andrieux Oct 11 '17 at 17:17
  • @François Andrieux but if I'm using the SAME compiler, shouldn't I expect the same results, regardless of operating system? – SuperGoA Oct 11 '17 at 17:18
  • @SuperGoA Likely either the implementation of the standard library is different or it relies on an underlying OS dependent mechanisms. – François Andrieux Oct 11 '17 at 17:19
  • @SuperGoA The question says that *"line 1 is ALWAYS delayed"*. Did you mean always displayed? – François Andrieux Oct 11 '17 at 17:24
  • @François Andrieux yes, thanks! – SuperGoA Oct 11 '17 at 17:25
  • 1
    Possible duplicate of https://stackoverflow.com/questions/17977657/make-the-compiler-not-to-automatically-flush-the-buffer – François Andrieux Oct 11 '17 at 17:25
  • @François Andrieux How could it be a duplicate of [this](http://stackoverflow.com/questions/17977657/) if I'm compiling the code using the same compiler (therefore, the same implementation)? – SuperGoA Oct 11 '17 at 17:41
  • 2
    @SuperGoA it's obviously a different back-end implementation as it interfaces to the Windows API instead of Linux. – Klitos Kyriacou Oct 11 '17 at 17:45
  • 1
    @SuperGoA The behavior of `cout` regarding flushing is implementation defined. Check with both tool chains you are comparing and see if they both make the same guarantees. If they do, then one of them has a bug and you should file a bug report with the defective one. If not (including if one of them makes no guarantee), then the reason the behavior is different is that the implementations have different behavior. The linked question is in regard to why the behavior may vary. If the comparison between two seemingly identical implementations is what is bothering you, I will remove that comment. – François Andrieux Oct 11 '17 at 17:46
  • 2
    @SuperGoA Keep in mind that standard library implementation can be a distinct concept from the compiler implementation. Some compilers allow you to provide your own library implementation, or to select from multiple versions. And a given library implementation can vary from platform to platform in order to accommodate the platform's unique requirements. See the implementation's documentation (if there is any) to see what portability guarantees it makes regarding implementation defined behavior. In general, it's best to not rely on implementation defined behavior. – François Andrieux Oct 11 '17 at 17:50
  • @François Andrieux This was the root cause of my confusion. I did not realize that implementation relied on more than just the compiler level. – SuperGoA Oct 11 '17 at 17:52
  • 1
    Specifically, GCC on Windows uses the internal Windows C runtime, which never uses line buffering. Console output is unbuffered; non-console output is fully buffered. I believe Linux runtimes typically use line buffering for console output, and that's why the `\n` and/or `endl` make a difference. – Harry Johnston Oct 12 '17 at 01:10

0 Answers0