Some hard-learned C++ knowledge:
cinalways uses file descriptor 0.
coutalways uses file descriptor 1.
cerralways uses file descriptor 2.
This is particularly annoying where you close file descriptors 0, 1, and 2 and re-open them to something else, because cin/cout/cerr will still use those file descriptors, and will read/write to the new things that you opened!
I finally figured out that that was what was happening on my tree-based booters -- I had debugging cerr's that ended up writing down sockets, which caused havoc on the remote side, because it got unformatted and unexpected messages. Doh!!!
In hindsight, this completely makes sense (and may even be by design; I don't have an iostream book handy). Consider that cin/cout/cerr are not tied to the OS -- they have no way of knowing when file descriptors 0, 1, and 2 have been closed and reopened to something else. For example, cout's operator<<(...) assumedly eventually boils down to:
write(1, ...);In which case, cout has had no indication that file descriptor has been closed and re-opened into something else.
Just a point of wisdom for readers out there... it caused me three days of grief.