是否应将GUI应用程序警告消息发送到std :: cerr？

Question

是否应将Unix GUI应用程序的警告发送到std :: cerr或std :: cout？

这假设GUI通常在控制台窗口中显示警告和错误，并将它们发送到日志文件。但是如果控制台丢失并因此无法使用，应该将std :: cerr，std :: cout或std :: clog用于此类消息吗？

我在想std :: cerr是他们所属的地方。

Answer 1

我更喜欢cerr。如果用户管道输出或将其发送到文件，他们可以选择退出cerr

tool 2>/dev/null >output

但是将所有内容放在一个流中会让他们失去SOL。

cerr也是无缓冲的，因此无论崩溃和刻录有多困难，都会保证出现错误消息。如果用户将上面的/dev/null替换为其他内容，警告应该与错误一起传输......我不确定这是否是一个明确的论点。

Answer 2

如果您的程序设计为具有正确格式化的输出，可以通过管道传输到另一个程序，或者将要解析，则最好将警告重定向到std::cerr。

Answer 3

对于编译器，有关正在编译的代码的错误消息是“正常”输出，因此应将它们写入stdout，而不是stderr。应该写入stderr的唯一消息是关于运行编译器本身的错误（例如，如果找不到构成编译器一部分的文件，那么编译器就无法运行）。

相同的基本准则适用于大多数其他程序：如果所讨论的“消息”是该程序的“标准”输出的一部分，并且用户通常期望在/如果它们重定向输出时包含它，然后应该写入标准输出。标准错误适用于用户通常希望/需要查看的消息，即使他们将标准输出重定向到文件 - 主要是那些说程序无法运行的消息，因此没有输出，或者如果有的话可能不完整或无效。

Answer 4

在Windows上，std :: cerr和std :: cout都不是从GUI程序引导到任何地方，它们只是转到天空中的那个大桶。我认为你在谈论基于* nix的系统。

Answer 5

这可能对OP有帮助。这就是我们的工作：

1. 将stderr重定向到本地日志文件（每个进程一个日志文件）
2. 使用我们自己的syslog()客户端（具有C ++前端）（和本地“ Syslog Watcher”服务器）
3. 当我们将openlog()与LOG_PERROR一起使用时，每条syslog消息也都转到本地日志文件
4. 我们根本不使用iostreams
5. 我们仅将控制台用于我们自己的小型测试框架

正确，这不是* nix。为了我们的辩护，这都不是WIN32。我们不提供UI应用。