C/C++ 编译器的最佳编译器警告级别？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/399850/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Best compiler warning level for C/C++ compilers?
提问by Alexander L. Belikoff
What compiler warning level do you recommend for different C/C++ compilers?
对于不同的 C/C++ 编译器，您建议使用什么编译器警告级别？
gcc and g++ will let you get away with a lot on the default level. I find the best warning level for me is '-Wall'. And I always try to remove fix the code for the warnings it generates. (Even the silly ones about using parenthesis for logical precedence rules or to say I really mean 'if (x = y)')
gcc 和 g++ 会让你在默认级别上摆脱很多。我发现对我来说最好的警告级别是“-Wall”。而且我总是尝试删除修复它生成的警告的代码。（即使是关于使用括号作为逻辑优先规则的愚蠢的人，或者说我的意思是“如果（x = y）”）
What are your favorite levels for the different compilers, such as Sun CC, aCC (HPUX ?), Visual Studio, intel?
对于不同的编译器，例如 Sun CC、aCC (HPUX ?)、Visual Studio、intel，您最喜欢的级别是什么？
Edit:
编辑：
I just wanted to point out that I don't use "-Werror" (but I do understand it's utility) on gcc/g++ because, I use:
我只是想指出，我没有在 gcc/g++ 上使用“-Werror”（但我确实理解它的实用性），因为我使用：
#warning "this is a note to myself"
in a few places in my code. Do all the compilers understand the #warning macro?
在我的代码中的几个地方。所有编译器都理解#warning 宏吗？
回答by Alexander L. Belikoff
This is a set of extra-paranoid flags I'm using for C++ code:
这是我用于 C++ 代码的一组额外偏执标志：
-g -O -Wall -Weffc++ -pedantic \
-pedantic-errors -Wextra -Waggregate-return -Wcast-align \
-Wcast-qual -Wchar-subscripts -Wcomment -Wconversion \
-Wdisabled-optimization \
-Werror -Wfloat-equal -Wformat -Wformat=2 \
-Wformat-nonliteral -Wformat-security \
-Wformat-y2k \
-Wimplicit -Wimport -Winit-self -Winline \
-Winvalid-pch \
-Wunsafe-loop-optimizations -Wlong-long -Wmissing-braces \
-Wmissing-field-initializers -Wmissing-format-attribute \
-Wmissing-include-dirs -Wmissing-noreturn \
-Wpacked -Wpadded -Wparentheses -Wpointer-arith \
-Wredundant-decls -Wreturn-type \
-Wsequence-point -Wshadow -Wsign-compare -Wstack-protector \
-Wstrict-aliasing -Wstrict-aliasing=2 -Wswitch -Wswitch-default \
-Wswitch-enum -Wtrigraphs -Wuninitialized \
-Wunknown-pragmas -Wunreachable-code -Wunused \
-Wunused-function -Wunused-label -Wunused-parameter \
-Wunused-value -Wunused-variable -Wvariadic-macros \
-Wvolatile-register-var -Wwrite-strings
That should give you something to get started. Depending on a project, you might need to tone it down in order to not see warning coming from third-party libraries (which are usually pretty careless about being warning free.) For example, Boost vector/matrix code will make g++ emit a lot of noise.
这应该给你一些东西开始。根据项目的不同，您可能需要将其调低，以免看到来自第三方库的警告（这些库通常非常粗心地免于警告。）例如，Boost 向量/矩阵代码将使 g++ 发出很多的噪音。
A better way to handle such cases is to write a wrapper around g++ that still uses warnings tuned up to max but allows one to suppress them from being seen for specific files/line numbers. I wrote such a tool long time ago and will release it once I have time to clean it up.
处理此类情况的更好方法是围绕 g++ 编写一个包装器，该包装器仍然使用调整到最大值的警告，但允许禁止在特定文件/行号中看到它们。很久以前就写过这样的一个工具，等我有时间清理一下就放出来。
回答by Paulius
On Visual C++, I use /W4and /WX(treat warnings as errors).
在 Visual C++ 上，我使用/W4和/WX（将警告视为错误）。
VC also has /Wall, but it's incompatible with the standard headers.
VC 也有/Wall，但它与标准头文件不兼容。
I choose to treat warnings as errors, because that forces me to fix them. I fix all warnings, even if that means adding #pragmato ignore the warning - that way, I'm stating explicitly, that I'm aware of the warning (so other developers won't e-mail me about it).
我选择将警告视为错误，因为这迫使我修复它们。我修复了所有警告，即使这意味着添加#pragma忽略警告 - 这样，我明确声明，我知道警告（因此其他开发人员不会向我发送电子邮件）。
回答by xtofl
I believe VC also supports
我相信VC也支持
#pragma message ("note to self")
But as the system grows and grows, and you get a nightly build 30 developers work on simultaneously, it takes days to read all the notes to self, even in that amount that self is going to be do nothing but note reading and finally going to break under the stress not being able to keep up and have to resign...
但是随着系统的发展和壮大，你每晚构建 30 个开发人员同时工作，需要几天的时间来阅读所有的笔记给自己，即使在这个数量上，自己除了阅读笔记之外什么都不做，最后会在压力下休息跟不上，不得不辞职......
No really, the amount of warnings is quickly going to grow if you allow them, and you won't be able to spot the really important ones (uninitialized variables, this pointer used in constructor, ...).
真的，如果允许警告的数量会迅速增加，并且您将无法发现真正重要的警告（未初始化的变量，构造函数中使用的 this 指针，......）。
That's why I try to treat warnings as errors: most of the time, the compiler is right warning me, and if he isn't, I document it in the code and prepend
这就是我尝试将警告视为错误的原因：大多数情况下，编译器是正确的警告我，如果他不是，我将其记录在代码中并预先添加
#pragma warning ( push )
#pragma warning ( 4191 : disable )
// violent code, properly documented
#pragma warning ( pop )
I just readthey have a warning ( N : suppress )pragma, too.
我刚刚读到他们也有一个warning ( N : suppress )pragma 。
回答by Johannes Schaub - litb
I tend to use -Wall(because everyone does make bugs, nobody is perfect) , but i don't use -Werror(treat warnings as errors) because now and then gcc warns about things which are right anyway (false positives).
我倾向于使用-Wall（因为每个人都会-Werror犯错误，没有人是完美的），但我不使用（将警告视为错误），因为 gcc 会时不时地对正确的事情发出警告（误报）。
回答by codelogic
I agree with litb to always use -Wall. In addition, if you want to ensure your code is compliant you can also use -pedantic. Another warning that can be helpful if you're handling unions and structs at the byte level is -Wpadded.
我同意 litb 总是使用 -Wall。此外，如果您想确保您的代码合规，您还可以使用 -pedantic。如果您在字节级别处理联合和结构，另一个可能会有所帮助的警告是 -Wpadded。
回答by graham.reeds
I do all development with Warning as Errors turned on.
当错误打开时，我使用警告进行所有开发。
Since I still develop in VC6 I have a lot of #pragma's in my code (4786 mainly).
因为我仍然在 VC6 中开发，所以我的代码中有很多#pragma（主要是 4786）。
回答by Tim Post
I like -Wall and strict prototypes as well as implicit function definitions. Errors on those can be very useful. There's also -Wextra which will pick up all kindsof things like things you intended to be conditionals but accidentally wrote as statements:
我喜欢 -Wall 和严格原型以及隐式函数定义。这些错误可能非常有用。还有 -Wextra 可以获取各种内容，例如您打算作为条件但不小心写为语句的内容：
if (something);
classic_way_to_leak_memory();
On Unix-like systems you have to obey the user's ENV preferences .. so what they see and report might be entirely different than what you need :)
在类 Unix 系统上，您必须遵守用户的 ENV 偏好......所以他们看到和报告的可能与您需要的完全不同:)
I'm also a type punning fiend, so I tend to set -Fno-strict-aliasing as well, unless the user wants it. Safe memory management in classic C is hard to accomplish otherwise.
我也是一个双关语的恶魔，所以我也倾向于设置 -Fno-strict-aliasing ，除非用户想要它。否则很难实现经典 C 中的安全内存管理。
回答by Marco
There's a nice list of options for GCC here: http://mces.blogspot.com/2008/12/year-end-cleaning-ie-on-warning-options.htm. -Wall does not enable all the possible warnings, and some have to be enabled explicitely.
这里有一个很好的 GCC 选项列表： http://mces.blogspot.com/2008/12/year-end-cleaning-ie-on-warning-options.htm。-Wall 不会启用所有可能的警告，有些必须显式启用。
回答by Steve Jessop
On GCC, for preference I use -Wall -Wextra -Wwrite-strings -Werror, and also specify a standard with std=. Which standard depends on the project: principally on how portable it needs to be.
在 GCC 上，出于偏好，我使用-Wall -Wextra -Wwrite-strings -Werror，并且还使用std=. 哪个标准取决于项目：主要取决于它需要的便携性。
The reason I use -Werroris that warnings are unacceptable (to me) even if they don't represent a real bug. I'd rather work around whatever caused the warning, than have to ignore warnings every single time I compile for the rest of my life. Once you allow warnings in the compile, it's just too easy to miss one that wasn't there last time.
我使用的原因-Werror是警告（对我来说）是不可接受的，即使它们不代表真正的错误。我宁愿解决导致警告的任何问题，也不愿在我的余生中每次编译时都忽略警告。一旦您在编译中允许警告，就很容易错过上次没有的警告。
Of course when dealing with third-party code, sometimes you can't get rid of the warnings. Then I'd decide on a case-by-case basis whether to relax the -Woptions, remove -Werrorand write a script to check that only expect warnings occur, or maybe modify the third-party code (either to "fix" the warning or to disable it with pragmas if possible).
当然，在处理第三方代码时，有时无法摆脱警告。然后我会根据具体情况决定是否放宽-W选项，删除-Werror并编写脚本来检查是否只发生预期警告，或者修改第三方代码（“修复”警告或如果可能，请使用编译指示禁用它）。
回答by Rob Latham
no one has mentioned the Intel compiler yet:
还没有人提到英特尔编译器：
-w3 is pretty chatty, so I would suggest -w2
-w3 很健谈，所以我建议 -w2
