C / C ++编译器的最佳编译器警告级别？
你对不同的C / C ++编译器推荐什么编译器警告级别？
海湾合作委员会和G + +会让你逃脱了很多在默认的水平。 我觉得对我来说最好的警告级别是“墙”。 而且我总是尝试删除修复它生成的警告的代码。 （甚至愚蠢的使用括号的逻辑优先规则或说我真的是指“if（x = y）”）
对于不同的编译器，你最喜欢的级别是什么？例如Sun CC，aCC（HPUX？），Visual Studio，intel？
编辑：
我只想指出，我不使用gcc / g ++中的“-Werror”（但是我明白它是实用的），因为我使用：
＃警告“这是对自己的一个说明”
在我的代码中的一些地方。 所有编译器都理解#warningmacros吗？
这是我用于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 这应该给你一些开始。 根据一个项目的不同，你可能需要调整一下，以免看到来自第三方库的警告（通常这些警告是免费的。）例如，Boost向量/matrix代码会使g ++发出很多的噪音。
处理这种情况的一个更好的方法是围绕g ++编写一个包装器，它仍然使用调整到max的警告，但是允许一个人禁止他们被特定的文件/行号看到。 我很久以前写了这样一个工具，一旦我有时间清理它，就会释放它。
在Visual C ++上，我使用/W4和/WX （将警告视为错误）。
VC也有/Wall ，但是它与标准头文件不兼容。
我select将警告视为错误，因为这迫使我解决它们。 我修正了所有警告，即使这意味着添加#pragma来忽略警告 – 这样，我明确地说，我知道警告（所以其他开发人员不会通过电子邮件发送给我）。
我相信VC也支持
#pragma message ("note to self")
但是随着系统的不断发展壮大，每晚为30名开发人员同时开展工作，需要花费数天的时间才能读完所有的笔记，即使这样，笔记本电脑自己也不会做任何事，在压力不能忍受，不得不辞职的压力下rest…
实际上，如果允许的话，警告的数量将会迅速增加，而且你将无法发现真正重要的警告（未初始化的variables，在构造函数中使用的这个指针，…）。
这就是为什么我会将警告视为错误：大多数情况下，编译器是正确的警告我，如果他不是，我将它logging在代码中，并预先
#pragma warning ( push ) #pragma warning ( 4191 : disable ) // violent code, properly documented #pragma warning ( pop )
我刚刚读到他们也有warning ( N : suppress )杂注。
我倾向于使用-Wall （因为每个人都做错误，没有人是完美的），但是我不使用-Werror （把警告当作错误），因为现在和当时gcc警告正确的东西（误报）。
我同意litb总是使用-Wall。 另外，如果你想确保你的代码是兼容的，你也可以使用-pedantic。 如果您在字节级别处理联合和结构，另一个警告可能会有所帮助，即-Wpadded。
我做所有的开发与警告作为错误打开。
由于我仍然在VC6中开发，我的代码中有很多#pragma（主要是4786）。
这里有一个很好的GCC选项列表： http ： //mces.blogspot.com/2008/12/year-end-cleaning-ie-on-warning-options.htm 。 – 没有启用所有可能的警告，有些必须明确地启用。
我喜欢–Wall和严格的原型以及隐式函数定义。 这些错误可能是非常有用的。 还有一个特别的东西，它可以把你想要成为条件的东西拿到各种各样的东西上，但却不小心写成了语句：
if (something); classic_way_to_leak_memory();
在类Unix系统上，你必须服从用户的ENV偏好..所以他们看到和报告可能会完全不同于你需要:)
我也是一个types双关的恶魔，所以我倾向于设置-Fno-strict-aliasing，除非用户需要。 经典C中的安全内存pipe理很难完成。
在Visual CI中使用/ w3。 我发现w4在每个版本上都会抛出过多的噪音（很多来自MS库）。 额外的警告是非常小的，并不是迄今为止的错误的原因。
在GCC上，首选我使用“-Wall -Wextra -Wwrite-strings -Werror”，并用std =指定一个标准。 哪个标准取决于项目：主要关于它的便携性。
我使用“错误”的原因是即使它们不代表真正的错误，警告也是不可接受的（对我来说）。 我宁愿在导致警告的地方工作，也不愿意每次编译我的余生都要忽略警告。 一旦在编译时允许警告，就很容易错过上次没有的警告。
当然，在处理第三方代码的时候，有时候你不能摆脱这些警告。 然后，我会根据具体情况决定是否放松-W选项，删除-Werror并编写一个脚本来检查是否只发生警告，或者修改第三方代码（或者“修复”如果可能，使用编译指示警告或禁用它）。
没有人提到英特尔编译器呢：
-w3相当健谈，所以我会build议-w2
我也喜欢查看给我的项目编译器的所有可能的警告。 不幸的是关于英特尔C ++编译器的回答对我来说并不是很有帮助（链接已经死了）。 我做了我自己的研究。
因为我使用Qt 5和qmake我有预定义的警告级别-w1 。 对此无能为力。 但是，这不是全部，ICC有更多的关键：
-Wcomment -Weffc++ -Wextra-tokens -Wformat -Winline // don't use, show only for example -Wmain -Wmissing-declarations -Wmissing-prototypes -Wnon-virtual-dtor -Wp64 -Wpointer-arith -Wremarks -Wreturn-type -Wsign-compare -Wstrict-aliasing -Wstrict-prototypes -Wtrigraphs -Wuninitialized -Wunknown-pragmas -Wunused-variable
更多关于所有的钥匙 。
另外我想补充一点，与GCC不同的是，ICC为一个键产生了几个警告，例如key- Weffc ++ 。 如果您只想从所有列表中看到几个警告，请使用键-wd 。
我禁用： -wd1418,2012,2015,2017,2022,2013 。 并警告-wd1572,873,2259,2261在默认情况下在qmake中被禁用。
我使用PCH，并发现非常恼人的Qt Creator消息有关使用PCH文件错误。 要禁用，请使用-Wno-pch-messages 。
在代码中禁用警告我使用：
#if defined(Q_CC_INTEL) #pragma warning( push ) #pragma warning( disable: 2021 ) #endif // some code #if defined(Q_CC_INTEL) #pragma warning( pop ) #endif
谢谢大家的答案。 自从我使用gcc / g ++以外，已经有一段时间了。 我不得不使用很久以前
-fmessage-length = 0（因为g ++有一个破坏消息的丑恶习惯） -Wno-deprecated（因为我在一个预先存在std名称空间的代码库上工作）
我记得（至less5年前），Sun Workshop CC编译器的默认警告级别以上的内容太多了。 我也认为这对英特尔编译器来说可能是正确的。 我还没有和non gnu编译器达成一段时间。
每个新版本的GCC编译器都变得越来越严格。 使用标志-ansi来产生违反ANSI语言标准的最严格解释的警告。 这通常是刚好在当前编译器中工作的东西，但是在下一个版本或其他编译器中可能会产生错误。 该标志将帮助您避免每次切换编译器/版本时都必须移植代码。
