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

Question

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

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

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

Answer 1

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

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

Answer 2

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

tool 2>/dev/null >output

但是把所有东西都放在一个流中就会留下SOL。

此外cerr是无缓冲的，因此无论您崩溃和刻录多么困难，都会保证出现错误消息。如果用户用其他东西替换了上面的/dev/null，那么警告应该伴随着错误传递......我不确定这是否是一个独特的论点。

Answer 3

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

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应用程序。