You know... I still don't get buffers.

Call me dense, because I just don't get this.

Don't get me wrong, I understand the concept of buffered and unbuffered output completely. Conceptually, it's simple. When will I ever see it in practice though? To put it another way... when is cout not flushed?

For a long time I've been looking for a visual example that depicts the difference between cout and cerr. I've written some test programs trying to show the difference, but to no avail.

So does anyone have a good example of cout not outputting where cerr would? Right now the only thing I can think of is writing multiple threads and hope one of the threads fails, crashes the program, right in the middle of a cout out statement. I don't know. My head hurts.

No need for multiple threads. Simply write to cout without a flush or endl, then crash the program immediately afterwards. The stuff you wrote to cout might not be displayed.

cout and cerr are bound by default to the same output device, the console. However, while cout writes to the standard output, cerr writes to the standard error.

Maybe it helps to remember that cout and cerr are objects. They both are of ostream type. But cerr is meant as an abstraction of an error message being output to some stream, while cout is meant as an abstraction of a normal output.

A common usage of the cerr object is probably to bind it to an ofstream for in-file logging of error message. However, you can do the exact same thing with a cout object. However cerr is a more... moral choice.

I had a problem that illustrated this. I posted it here. Just add a selection_sort function that produces a segmentation fault and you should see the behavior you're looking for.

Oh... there's another (big) difference between cerr and cout. When you redirect your output to a file, cerr is still sent to ostream, despite being also sent to the ofstream. Which means cerr is still sent to your console.

But they behave exactly the same way otherwise.

Code:

---

#include <iostream>
using namespace std;

int main ( ) {
  cout << "hello ";
  cerr << "this is an error"; // appears before hello if cout isn't flushed
  cout << "world" << endl;
  return 0;
}

---

If run without any redirection, we get
$ ./a.exe
this is an errorhello world

Redirecting stdout, we only see stderr on console
$ a.exe 1> f1.txt
this is an error

Redirecting stderr, we only see stdout on console
$ a.exe 2> f2.txt
hello world

I can't manage to get that result. Compiled under MinGW and VS2005's compiler, I get "hello this is an errorworld", which ironically describes exactly what I'm feeling right now. :(

I get the idea of what *should* happen, but I just can't manage to see it happen.

Quote:

---

Originally Posted by SlyMaelstrom

I can't manage to get that result. Compiled under MinGW and VS2005's compiler, I get "hello this is an errorworld", which ironically describes exactly what I'm feeling right now. :(

I get the idea of what *should* happen, but I just can't manage to see it happen.

---

After you have compiled and linked program, go to console (Run->Cmd in windows) go to directory where your .exe file is and the type:
name.exe
name.exe > output.txt
name.exe 2> output.txt

and you'll see the difference.

Salem, can you explain what "2>" means in redirection and why this behaves in this way?

I give up

Ok, I see it now. Thanks

...and I'd imagine 2 is referring to the file descriptor. 2 I believe is stderr. So when you pipe with 2> you pipe stderr to the file and the rest prints to the console. Though it appears Windows also lets you pipe to 0 and 1, which I would imagine one of those is stdin. :|

Anyway, I was almost having trouble figuring this out because of the response the program was giving me and tricked me into thinking the command prompt was having a problem

Quote:

---

Originally Posted by cmd.exe

C:\> coutblah > output.txt
this is an error // What the hell kind of error!!! Arg!!!

---

Then I checked the file to see the rest. :p

I still don't get the output, "this is an errorhello world", which displeases me because I assume it means for some reason something in my PC is set wrong and decided that stdout is just as important as stderr and either doesn't buffer either or buffers both. Or maybe it just means the operator<<(&cerr, "this is an error") flushes the stdout.... whatever.

Anyway, thanks everyone. I can see it now.

Strictly speaking, cout does not need to be physically buffered. As described in the standard, the difference between cout and cerr (apart from the fact they are different streams) is that cerr.flags() & unitbuf is non-zero while cout.flags() & unitbuf is zero. The literal meaning of the unitbuf flag being set is that the stream will be flushed on each output operation. However, if the unitbuf flag is zero, it is up to the implementer as to when (or if) flushing is necessary. This means that cout is not necessarily physically buffered.

One other characteristic, of some libraries, is that cout is buffered, but flushed whenever output to cerr (and sometimes clog) occurs --- not just when something is read from cin. This is a nicety by some library implementers, and the intent is to ensure that messages to a console are coherent.

When you include iostream, cerr, cin and cout are automatically created and cout and cerr are tied to cin. So your cout and cerr are only flushed automatically one one of these 3 situations

1. function normal termination
2. buffer is full
3. cin is used (exactly because it is tied to cout and cerr)

You can control the 3rd situation with the use of the tie() member function.
Check on streambuf class for ways to deal with the 2nd
Pass a reference to a buffer or return a reference to a buffer to avoid the 1st

> Salem, can you explain what "2>" means in redirection and why this behaves in this way?
Exactly as SlyMaelstrom deduced, it's the descriptor of the stream you want to redirect.

I understand now, thanks