一般编译器错误_c++的好习惯：打开编译器警告

我在半年之前开始用c++来做一些算法开发并且部署到项目中，因为写的算法会被频繁调用，所以需要保证用c++写出正确，简洁，高效的算法代码，我知道现在的算法工程师大多都是从python入门的，对c++并不是特别熟悉，甚至有许多跟我一样，从别的专业转行的算法。但是无论如何，算法工程师首先是个工程师，必须严格为自己的代码负责，遵守代码规范，培养良好的开发习惯。

为什么不要忽视warning

我想许多算法工程师刚开始接触c++的时候，都会用cmake来编译自己的项目，或许从网上找到一份模板然后做一些修改最后发现能够编译通过就觉得已经ok了，但是事实上c++不像python等解释性语言，它更强大，当然也更难以控制，在简历上写精通c++可是减分项(除了真大神)。你觉得能够正确运行的代码后面可能埋藏了无数颗雷，在编译的时候忽略这些雷可能就会导致未来的某一天在线上就爆炸了，同时由于时间太久到那个时候已经发现留下的雷实在太多，会带来极高的维护和重构成本。warning可以解决什么问题呢？许许多多，举一个简单的例子，如果你不小心写出如下的c++代码：

if( flag = true) {
    //do something
}

那么这个错误如果你不打开warning的话，编译器是不会发现的，事实上许多有经验的c++程序员也会不小心写出这样的代码，这种错误需要你有一双放大镜一般的眼睛逐行扫描，可能要花费大量的时间才能发现。而如果打开了warning的话，编译器会马上告诉你

warning: suggest parentheses around assignment used as truth value [-Wparentheses]
     if(flag = true)

将你从人肉debug的深渊中拯救出来，不仅这样，warning还会告诉你更多的信息，比如未使用的变量，不正确的缩进，将不同类型的变量进行对比等等。修复这些警告不仅可以提高你程序的文件程度，同时显得更加干净和简洁。在Effective c++(如果你觉得你入门了c++,我推荐你马上看这本书)的条款53也强调了不要忽略编译器警告.

如何打开编译器警告

如果你是一个会使用gcc来编译c++程序的人，请忽略这节……

我想绝大多数人都会用类似于cmake这样的工具来保护自己的头发，对于单个可执行程序

if ( CMAKE_COMPILER_IS_GNUCC )
    target_compile_options(main PRIVATE "-Wall -Wextra")
endif()
if ( MSVC )
    target_compile_options(main PRIVATE "/W4")
endif()

就可以为那个程序打开编译器警告，如果希望为项目中的所有代码都打开编译器警告

if ( CMAKE_COMPILER_IS_GNUCC )
    set(CMAKE_CXX_FLAGS  "${CMAKE_CXX_FLAGS} -Wall -Wextra")
endif()
if ( MSVC )
    set(CMAKE_CXX_FLAGS  "${CMAKE_CXX_FLAGS} /W4")
endif()

当然我也推荐在-Wextra后面添加-Werror或者在/W4后面添加/WX来将warning视为error直接中断编译，严于律己是一个好习惯。这里在补充一下-Wall和-Wextra的小差别，-Wall并不是指“all warning"而是指"all errors that everybody could agree on"，-Wextra则指那些"somebody agree on"的warning.

总结

你可能会发现许多项目都有warning,不管是国内的还是国外的，事实上对待warning更是一个态度问题。我也知道所有公司几乎都不会把处理warning计入kpi,事实上几乎所有的项目都是紧急的，很难遇到一个不浮躁的团队，不浮躁的管理。等你真正将所有的warning解决，客户可能已经端着大菠萝冲上来了。但是我还是认为作为一个开发者，写出好的代码不是对公司的态度，而是对自己的态度，只有这样子去要求自己，才能真正提高自己的技术水平。

本文来自于本人博客，会首先在上面更新，再搬运到知乎，欢迎关注

zerollzeng/blog​github.com