c++ - 为什么我应该始终启用编译器警告？

Question

我经常听说在编译 C 和 C++ 程序时我应该“始终启用编译器警告”。为什么这是必要的？我怎么做？

有时我也听说我应该“将警告视为错误”。我是不是该？我该怎么做？

Answer 1

为什么要启用警告？

众所周知，C 和 C++ 编译器默认不善于报告一些常见的程序员错误，例如:

• 忘记初始化变量
• 忘记从函数返回一个值
• printf 和 scanf 系列中的参数与格式字符串不匹配
• 函数在没有事先声明的情况下使用(仅限 C)

这些可以被检测和报告，只是通常不是默认的；必须通过编译器选项明确请求此功能。

如何启用警告？

这取决于您的编译器。

Microsoft C 和 C++ 编译器理解 /W1、/W2、/W3、/W4 等开关和 /Wall。至少使用 /W3。 /W4 和 /Wall 可能会发出系统头文件的虚假警告，但如果您的项目使用这些选项之一编译干净，那就去吧。这些选项是相互排斥的。

大多数其他编译器都能理解像 -Wall 这样的选项, -Wpedantic和 -Wextra . -Wall 是必不可少的，其余的都是推荐的(请注意，尽管它的名称，-Wall 只启用最重要的警告，而不是所有其中)。这些选项可以单独使用，也可以一起使用。

您的 IDE 可能有办法从用户界面启用这些。

为什么我应该将警告视为错误？它们只是警告!

编译器警告表示您的代码中存在潜在的严重问题。上面列出的问题几乎总是致命的；其他人可能会也可能不会，但您希望编译失败，即使事实证明它是误报。调查每个警告，找到根本原因并修复它。在误报的情况下，解决它 - 即使用不同的语言功能或结构，以便不再触发警告。如果事实证明这非常困难，请根据具体情况禁用该特定警告。

您不希望只将警告保留为警告，即使它们都是误报。对于发出的警告总数少于 7 个的非常小的项目来说，这可能没问题。任何更多，新警告很容易在熟悉的旧警告的洪流中迷失。不允许这样。只是让您的所有项目都能干净地编译。

注意这适用于程序开发。如果您以源代码形式向全世界发布您的项目，那么最好不要提供 -Werror。或您的已发布构建脚本中的等效项。人们可能会尝试使用不同版本的编译器或完全不同的编译器来构建您的项目，这可能会启用一组不同的警告。您可能希望他们的构建成功。保持警告处于启用状态仍然是一个好主意，这样看到警告消息的人可以向您发送错误报告或补丁。

如何将警告视为错误？

这又是通过编译器开关完成的。 /WX 适用于 Microsoft，其他大多数使用 -Werror。在任何一种情况下，如果产生任何警告，编译都会失败。

这就够了吗？

应该不会吧!当您提高优化级别时，编译器开始越来越仔细地检查代码，这种更仔细的检查可能会发现更多错误。因此，不要满足于警告开关本身，在启用优化(-O2 或 -O3，或 /O2 如果使用 MSVC)。