为什么要始终启用编译器警告？

问题描述

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

I often hear that when compiling C and C++ programs I should "always enable compiler warnings". Why is this necessary? How do I do that?

有时我还听说我应该将警告视为错误。我是不是该？我该怎么办？

Sometimes I also hear that I should "treat warnings as errors". Should I? How do I do that?

推荐答案

为什么启用警告？

众所周知，C和C ++编译器在默认情况下会报告一些常见的程序员错误，例如：

Why enable warnings?

C and C++ compilers are notoriously bad at reporting some common programmer mistakes by default, such as:

• 初始化变量


• 忘记让返回来自函数的值


• <$中的参数c $ c> printf 和 scanf 系列与格式字符串不匹配


• 不使用函数事先声明（仅C）

• forgetting to initialise a variable
• forgetting to return a value from a function
• arguments in printf and scanf families not matching the format string
• a function is used without being declared beforehand (C only)

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

These can be detected and reported, just usually not by default; this feature must be explicitly requested via compiler options.

这取决于您的编译器。

This depends on your compiler.

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

Microsoft C and C++ compilers understand switches like /W1, /W2, /W3, /W4 and /Wall. Use at least /W3. /W4 and /Wall may emit spurious warnings for system header files, but if your project compiles cleanly with one of these options, go for it. These options are mutually exclusive.

大多数其他编译器都理解 -Wall ，- Wpedantic 和 -Wextra 。 -Wall 是必不可少的，所有其他内容都建议使用（请注意，尽管名称为 -Wall ，重要警告，而不是全部警告。）这些选项可以单独使用，也可以一起使用。

Most other compilers understand options like -Wall, -Wpedantic and -Wextra. -Wall is essential and all the rest are recommended (note that, despite its name, -Wall only enables the most important warnings, not all of them). These options can be used separately or all together.

您的IDE可能有一种从用户界面启用这些选项的方法。

Your IDE may have a way to enable these from the user interface.

编译器警告表示代码中潜在的严重问题。上面列出的问题几乎总是致命的。其他可能会或可能不会，但是您希望编译失败即使证明是错误的警报。调查每个警告，找到根本原因，然后加以解决。如果发生错误警报，请解决它-即，使用其他语言功能或结构，以便不再触发警告。如果事实证明这样做很困难，请逐个案例地禁用该特定警告。

A compiler warning signals a potentially serious problem in your code. The problems listed above are almost always fatal; others may or may not be, but you want compilation to fail even if it turns out to be a false alarm. Investigate each warning, find the root cause, and fix it. In the case of a false alarm, work around it — that is, use a different language feature or construct so that the warning is no longer triggered. If this proves to be very hard, disable that particular warning on a case by case basis.

即使所有警告都作为警告，您也不想保留是虚假的警报。对于发出警告的总数少于7个的非常小的项目，可能还可以。而且，新警告很容易在大量熟悉的旧警告中丢失。不允许那样只需使您的所有项目都能干净地编译即可。

You don't want to just leave warnings as warnings even if all of them are false alarms. It could be OK for very small projects where the total number of warnings emitted is less than 7. Anything more, and it's easy for a new warning to get lost in a flood of old familiar ones. Don't allow that. Just cause all your project to compile cleanly.

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

Note this applies to program development. If you are releasing your project to the world in the source form, then it might be a good idea not to supply -Werror or equivalent in your released build script. People might try to build your project with a different version of the compiler, or with a different compiler altogether, which may have a different set of warnings enabled. You may want their build to succeed. It is still a good idea to keep the warnings enabled, so that people who see warning messages could send you bug reports or patches.

这也是使用编译器开关完成的。 / WX 适用于Microsoft，大多数其他人使用 -Werror 。无论哪种情况，如果产生任何警告，编译都会失败。

This is again done with compiler switches. /WX is for Microsoft, most others use -Werror. In either case, the compilation will fail if there are any warnings produced.

这篇关于为什么要始终启用编译器警告？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！