为什么我应该总是启用编译器警告? [英] Why should I always enable compiler warnings?
问题描述
我经常听到在编译 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 should I enable warnings?
C and C++ compilers are notoriously bad at reporting some common programmer mistakes by default, such as:
- 忘记初始化变量
- 忘记从函数中
返回一个值 printf和scanf系列中的参数与格式字符串不匹配- 函数在没有事先声明的情况下被使用(仅 C 语言)
- forgetting to initialise a variable
- forgetting to
returna value from a function - arguments in
printfandscanffamilies 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.
这取决于您的编译器.
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 只启用最重要的警告，而不是 all其中).这些选项可以单独使用，也可以一起使用.
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 是针对微软的，其他大多数使用 -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.
这篇关于为什么我应该总是启用编译器警告?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
