Hello,
For C++/linux programs, how does writing to cout (when cout has been redirected to a file during program launch) compare against writing to the target file directly? (via say fstream)
Does the system do the appropriate magic at the start of the program to make these two cases exactly equivalent or is the later gonig to be better than the first?
Thanks!
I don't think the latter is necessiarily "better" or "worse". It certainly requires far less code when you simply redirect cout/stdout from the shell. It allows for simple text output (via printf/fprintf/cout).
I prefer using simple cout calls for quick and dirty logging and "printf" style debugging.
In my experience, I use syslog for things that absolutely have to be logged. For example, error cases where a file fails to open or you run out of resources or whatever.
I use printf/fprintf for the other "simple" logging tasks.
Some years ago, I developed a simple debugging system that now I just plug into my new Linux applications. I can then just call the appropriate functions in that code. It's similar to syslog in that it has debug "levels". For example, level 1 always writes to stdout, level 2 writes to stderr, level 4 writes to syslog, level 5 may create a new file and write messages to that, etc.
They are basically equivalent. In both cases, the underlying stream buffer will end up calling the write() system call, for the same effect.
Note however that by default, cout is synchronized to stdio, for backwards compatibility (so you can use C-style standard output as well as cout, and have it work as expected). This additional synchronization can slow down C++ output. If this is important, then you can use std::ios_base::sync_with_stdio(false) to unlink them. Then, a file-redirected cout and an fstream should have essentially identical performance and function.
The former is better for the phylosophy of UNIX tools, that is feeding a program with the output of another.
Let's say your programs prints numbers and you need to sort them. You feed the sort tool with the output of your commands and then write the result to a file, always with output redirection.
On the contrary, if you wrote directly to a file you couldn't to that.
Of course, if you don't plan your application to do this sort of things, you can write directly to a file. But if I were in you, I'll let the user decide. Maybe with a command line argument.
Yes. If the spawning process has arranged that file descriptor 1 (standard output) is the result of an open() call on a disk file, then I/O from the child process to that descriptor is exactly equivalent to the same I/O done to a file it had opened manually. The same is true for processes spawned with a pipe or socket (i.e. equivalent behavior to having opened their own pipe or socket). In fact, the kernel can't even tell the difference. All that matters is how the file descriptor was created (i.e. using what syscall, and on what filesystem), not which process did it.