Yeah, I've read the reference. But I still don't get it. How does each implemented? What should be used in a certain situation?

E.g.: If I want to display some error message, I should've used cerr. But what the difference with using cerr or cout for displaying error message? I mean it always went straight to the monitor anyway.

How is each implemented? Well, that's it, I guess -- the language doesn't specify. In my Windows Vista console window, I think that each buffer leads to the console window. The point is, as was said, each can be redirected independently. System implementers are implicity encouraged to direct cerr someplace where errors can be received, cout where a user can see, and clog where things can be stored.

>> But what the difference with using cerr or cout for displaying error message?
In my console enviornment, nothing. Unless I make it different.

Last edited by CodeMonkey; 07-09-2007 at 11:41 PM.
Reason: grammar

"If you tell the truth, you don't have to remember anything"
-Mark Twain

say a bank is using microsoft software on an ATM and something goes wrong. to the person at the ATM they are presented with a cover-up of the error (cout), while another message is sent to a terminal in the back room of the bank (cerr) so that someone knows what happened and to act on it.

most of the time, your software will simply be displayed on a computer monitor to someone sitting at a desk, and any output your program does (to either cout or cerr) will be sent to the same device--the monitor.

E.g.: If I want to display some error message, I should've used cerr. But what the difference with using cerr or cout for displaying error message? I mean it always went straight to the monitor anyway.

The operating system usually allows the user to redirect each of the three standard streams (cin, cout, cerr) to separate locations. If a program produces output AND logging/error messages, it is helpful to be able to direct ONLY the output to some destination, while still sending the error messages to the screen. Or, send errors to a file for later inspection. At any rate, you usually do not want the error output interleaved with the "normal" output, even though this is what happens when it goes to a screen.

Thanks to all of you. I finally understand more of them. I thought cout and cerr will always be sent to a screen. So if I'm not mistaken we can redirect the output of cerr (or clog) to another device while cout will always be directed to a standart output (screen), right? I get it now. Thanks.

No, not right. You can redirect standard output wherever you want, too.

First, cout, cerr and clog are ostream objects. You can call rdbuf() on them to redirect their output independently wherever you want, from within the application. You can open a network socket, wrap it in a stream buffer and redirect there, if you want.

By default, cout is tied to the application's standard output. By default, the standard output is the screen. You can direct the OS to redirect stdout elsewhere. Or it might do it by itself - the nohup utility in Linux, for example, does. Services in Windows also have their standard streams redirected, I think.

By default, cerr and clog are tied to the application's standard error. By default the standard error is the screen. You can again redirect stderr elsewhere.
Another issue here is that clog, by default, is buffered like cout, whereas cerr is unit-buffered, meaning it automatically calls flush() after every complete output operation. This is very useful, since it means that the output is not lost in the buffer if the application crashes directly afterwards.

All the buzzt! CornedBee

"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law

No, not right. You can redirect standard output wherever you want, too.

First, cout, cerr and clog are ostream objects. You can call rdbuf() on them to redirect their output independently wherever you want, from within the application. You can open a network socket, wrap it in a stream buffer and redirect there, if you want.

By default, cout is tied to the application's standard output. By default, the standard output is the screen. You can direct the OS to redirect stdout elsewhere. Or it might do it by itself - the nohup utility in Linux, for example, does. Services in Windows also have their standard streams redirected, I think.

By default, cerr and clog are tied to the application's standard error. By default the standard error is the screen. You can again redirect stderr elsewhere.
Another issue here is that clog, by default, is buffered like cout, whereas cerr is unit-buffered, meaning it automatically calls flush() after every complete output operation. This is very useful, since it means that the output is not lost in the buffer if the application crashes directly afterwards.

OIC, thanks. I always assume that standart output will always be the screen because that's the common thing. Ok, now I think I really get it. Thanks again.