[建筑]第1条在高警告级别干净利落地进行编译

摘要高度重视警告：使用编译器的最高警告级别。应该要求构建是干净利落的（没有警告）。理解所有的警告。通过修改代码而不是降低警告级别来排除警告。讨论编译器是你的朋友。如果它对某个构造发出警告，这经常是说明

摘要 高度重视警告：使用编译器的最高警告级别。应该要求构建是干净利落的（没有警告）。理 解所有的警告。通过修改代码而不是降低警告级别来排除警告。 讨论 编译器是你的朋友。如果它对某个构造发出警告，这经常是说明你的代码中存有潜在的问题。 成功的构建应该是无声无息的（没有警告的）。如果不是这样，你很快就会养成不仔细查看 输出的习惯，从而漏过真正的问题（见第2条）。 排除警告的正确做法是：（1）把它弄清楚；然后，（2）改写代码以排除警告，并使代码阅 读者和编译器都能更加清楚，代码是按编写者的意图执行的。 即使程序一开始似乎能够正确运行，也还是要这样做。即使你能够肯定警告是良性的，仍然 要这样做。因为良性警告的后面可能隐藏着未来指向真正危险的警告。 示例 例1第三方头文件。无法修改的库头文件可能包含引起警告（可能是良性的）的构造。如 果这样，可以用自己的包含原头文件的版本将此文件包装起来，并有选择地为该作用域关闭 烦人的警告，然后在整个项目的其他地方包含此包装文件。例如（请注意，各种编译器的警 告控制语法并不一样）： //文件：myproj/my_lambda.h——包装了Boost的lambda.hpp //应该总是包含此文件，不要直接使用lambda.hpp。 //注意：我们的构建现在会自动检查“greplambda.hpp<srcfile>”。 //Boost.Lambda会产生一些已知无害的编译器警告。 //在改正以后，我们将删除以下的编译指示，但此头文件仍然存在。 // #prag__warning(push)//仅禁用此头文件 #prag__warning(disable:4512) #prag__warning(disable:4180) #include<boost/lambda/lambda.hpp>