4

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

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

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

4

5 回答 5

6

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

tool 2>/dev/null >output

但是将所有内容放在一个流中会使它们成为 SOL。

同样cerr是无缓冲的，因此无论您多么努力地崩溃和烧毁，都会保证出现错误消息。如果用户将/dev/null上面的内容替换为其他内容，则警告应该与错误一起传送……我不确定这是否是一个独特的论点。

于 2010-10-05T18:29:54.650 回答
4

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

于 2010-10-05T18:30:42.760 回答
1

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

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

于 2010-10-05T18:34:32.813 回答
0

在 Windows 上，std::cerr 和 std::cout 都不是来自 GUI 程序的任何地方，它们只是转到天空中的那个大桶。我想你说的是基于 *nix 的系统。

于 2010-10-05T19:16:37.960 回答
0

这可能对 OP 有所帮助。这就是我们要做的：

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

正确，这不是 *nix。对我们来说，它也不是WIN32。我们不做 UI 应用程序。

于 2019-03-23T14:19:24.633 回答