C++ Weekly - Ep 140 - Use `cout`, `cerr`, and `clog` Correctly

lot of learnings from a single video.
I have always used std::endl and thought that is a cleaner way in C++ to do a new line.
Clear explanation of when to use std::cout and std::cerr.
But, I tried running code with std::err in both visual studio code terminal and also in cmder, and it doesn't print in red like shown in the video.

std::clog is useful when you want to print an error but you want to keep the messages that led to the error in order.
For example:
void foo()
{
std::cout << "Entering foo.\n";
do_some_work();
std::cout << "Did some work.\n";
if(error_condition() == true)
std::clog << "Error encountered.\n";
}

If we use the unbuffered version with std::cerr we could (and probably would) see the error message on the output before the normal prints and this complicates the debugging process.

stdin - standard input stream
stdout - standard output stream
stderr - standard error stream

std::cout - writes to the standard C output stream stdout
std::cerr - writes to the standard C error stream stderr, unbuffered

where should the std::clog write?
why the hell it is stderr?

the more i learn cpp the more i think it is full of bicycles and workarounds. std::endl implies std::flush. cout is crap, clog is ambiguous. logging with std::cerr is like the programmer is not mentally healthy. now i understand why everyone just writes sdt::cout with std::endl and does not use clog or cerr at all.

I do sometimes use std::flush for debug printing in parallel environments, though I'd typically insert everything into a local stringstream instead and then print that.
I prefer it over std::endl, because it does what its name implies.

That was very helpful and excellent to watch. I will subscribe.

Saying never use std::flush or std::endl is like saying never use virtual functions or heap allocations: use where you need them, and pay for it. std::cerr is for sending output to the standard error, not to send "flushed output". Most people don't like their console output in red. If your program will just output a few lines you can totally use endl, and avoid changing operating system (that suggestion made zero sense). I write servers that output tons of lines to log files, and if I just put new lines and the program crashes, I won't get the unflushed text. Besides, have you tried displaying a log file that never flushes? You perform a request and the output never comes out, because the buffer isn't full. So a sane person will output the lines in between every block of output with new lines, and the last line with endl. Your take on std::flush and endl is irrational. When you want a flush, use them, and pay for what you want to use. My boss had me put a configuration value that can turn flushing on and off and the difference in performance is minimal, but the difference in output is large.

i get no performance difference between using '\n' and std::endl on Linux.but there is a performance difference in windows. it is because the stdout file stream is buffered on Linux.whereas in windows the stdout is not buffered.but thank you for your great videos.

Why don't you like seeing `std::endl;` in code? D:
Am I supposed to flush? (There's a joke there somewhere)

EDIT: Oh nevermind you explain why
Also I've been flushing std::cerr forever now. Should I not? Dang man.

I always thought that std::endl would produce a platform-specific line ending (e.g. \n on Linux and \r\n on Windows), but after checking the standard it seems that it should always produce \n. So yeah, I agree that std::endl seems quite pointless and a hazard to performance. Also, I didn't know about std::clog, thanks!

but...cant you just not use endl when you dont need it (for normal logging)? and use it when you do (for error messages)?
whats the point of cerr / clog again (other than to write to the stderr stream)?
The way i understood it, cerr just flushes immidiatly and clog is exactly the same as cout just for stderr

How does one get the "./a.out" button? I am assuming this how Jason gets the output from the executed code.

thank you

Then why std::endl exists at all?

Btw thoughts on std::ios::sync_with_stdio(false);
for more speed

Agree with you. Now can we get fmtlib in the standard?

If I recall correctly, cout (for linux at least) is flushed on new line anyway, so \n and std::endl will both print a new line and flush the stream.

If there is a buffered and an unbuffered version of standard error stream why isn't there an unbuffered version of standard out stream?

Regarding the buffer flush at the end of the program, it's guaranteed as part of the destructor for cout. (Well, not cout specifically, but as part of the cleanup mechanism for the global streams as a whole, i.e., std::ios_base::Init.)

Didn't we agre on using printf? What's thiz cout propagandization???? ^_^

Nope, cerr is designed send errors unbuffered to the terminal or wherever the error stream is being sent to when sending buffered cout to a file or pipe. Unlike half baked operating systems, cout was designed to be the program output that can be piped. You don't want the errors to be hidden, delayed or mixed in.

Didn't you made a video about this topic before?

I do not like it, that the streams classes are virtual. You compiler can optimize the first output-operation, but after that it might have problems to do this again, because the returntype of operator<< is std::ostream& and not the type of std::cout etc. I hope that in the upcoming standart, with concepts, all operator<<-overloads are templated and std::ostream& replaced with something like std::OStream&, where std::OStream is a concept.

If I write to an ofstream instead of cout, does endl also force a buffer flush?