GUI 应用程序警告消息是否应该发送到 std::cerr？
Unix GUI 应用程序的警告是否应该发送到 std::cerr 或 std::cout？
这假定 GUI 通常在控制台窗口中显示警告和错误，并将它们发送到日志文件。但如果控制台丢失而无法使用，是否应该使用 std::cerr、std::cout 或 std::clog 来显示此类消息？
我认为 std::cerr 是它们所属的地方。
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我更喜欢
cerr。如果用户通过管道输出或将其发送到文件，他们可以选择退出 cerr，但将所有内容放入一个流中会让他们感到 SOL。
此外，
cerr是无缓冲的，因此无论您多么努力地崩溃和烧毁，都一定会出现错误消息。如果用户将上面的/dev/null替换为其他内容，则警告应该与错误一起通过管道传输……我不确定这是否是一个不同的参数。I prefer
cerr. If the user pipes the output or sends it to a file, they can opt-out ofcerrwithbut putting everything in one stream leaves them SOL.
Also
cerris unbuffered, so error messages are guaranteed to appear no matter how hard you crash and burn. And warnings should be piped along with errors, if the user replaced/dev/nullabove with something else… I'm not sure if that's a distinct argument or not.如果您的程序被设计为具有正确格式的输出，可以通过管道传输到另一个程序，或者将被解析，那么您应该最好将警告重定向到 std::cerr。
If your program is designed to have a properly formatted output that may be piped to another program, or is going to be parsed, you should better redirect warnings to
std::cerr.对于编译器来说，有关正在编译的代码的错误消息是“正常”输出，因此它们应该写入 stdout，而不是 stderr。应该写入 stderr 的唯一消息是关于运行编译器本身的错误（例如，如果无法找到构成编译器一部分的文件，则编译器无法运行）。
相同的基本准则适用于大多数其他程序：如果所讨论的“消息”是该程序“标准”输出的一部分，并且用户通常希望在/如果他们重定向输出时包含它，那么它应该被写入标准输出。标准错误适用于用户通常希望/需要看到的消息，即使他们将标准输出重定向到文件 - 主要是那些说程序无法运行，因此没有输出，或者如果有的话可能不完整或无效。
For a compiler, error messages about the code being compiled are the "normal" output, so they should be written to stdout, not stderr. The only messages that should be written to stderr would be about errors in running the compiler itself (e.g., if a file that makes up part of the compiler can't be found, so the compiler couldn't run).
The same basic guideline applies to most other programs: if the "message" in question is part of the "standard" output of that program, and a user would normally expect it to be included when/if they redirect the output, then it should be written to standard output. Standard error is intended for messages the user will normally want/need to see even if they have standard output redirected to a file -- primarily those saying that the program couldn't run, so there is no output, or if there is that it's likely to be incomplete or invalid.
在 Windows 上，std::cerr 和 std::cout 都不会从 GUI 程序定向到任何地方，它们只是转到空中的那个大位桶。我猜你正在谈论基于 *nix 的系统。
On Windows, neither std::cerr nor std::cout are directed anywhere from a GUI program, they just go to that big bit bucket in the sky. I presume you're talking about *nix based systems though.
这可能对OP有帮助。这就是我们要做的：
syslog()客户端（带有 C++ 前端）（以及本地“Syslog Watcher" 服务器）openlog()与LOG_PERROR一起使用时 < code>syslog 消息也发送到本地日志文件iostreams正确，这不是 *nix。为我们辩护，它也不是 WIN32。我们不做 UI 应用程序。
This might help to the OP. This is what do we do:
syslog()client (with C++ front) (and local "Syslog Watcher" server)openlog()withLOG_PERROReach and everysyslogmessage goes to the local log file tooiostreamsat allCorrect, this is not *nix. To our defence neither it is WIN32. We do not do UI apps.