宁愿犯编译期错误， 也不犯运行期错误 ---再谈 char *p = “abc“； 的不合理性 以及 写成 if(NULL == p)而不是if(p == NULL)的理由

本文主要是介绍宁愿犯编译期错误， 也不犯运行期错误 ---再谈 char *p = “abc“； 的不合理性 以及 写成 if(NULL == p)而不是if(p == NULL)的理由，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

        年末， 各方催进度， 大家也在抓紧时间码代码， 各种低概率死机问题频出， 这些低概率的死机问题非常难以重现和定位， 即便是修改好了， 也需要验证， 如果没有出现死机， 那也不能完全保证修改好了。 总之， 低概率问题就是这么折腾人。 

        那低概率死机问题是怎么产生的呢？ 其实， 很多时候都是程序猿编码不细心， 对一些问题理解不透彻造成的。 比如最常见的内存错误问题。 

 

        在本文中， 我不去具体讨论某某问题， 而是以一个简单的例子说明安全编程的重要性， 我们来讨论编译期错误和运行期错误。我们先看一个有潜在问题的程序:

 

#include <iostream>
using namespace std;int main()
{char *p = "abc";// ...// ...char c = 100; // 随机值if(123 == c) {cout << "if" << endl;*p = '\0';}// ...return 0;
}

 

      在99%的时候（准确概率是255/256）， 运行上面程序是不会有什么问题的， 但是， 如果当c的值是123, 那么上述程序运行的时候会崩溃。 究其原因，是因为后面维护该代码的程序猿看到char *p = "abc";后(尤其是看到char *p后)， 判断p所指向的值是可以改变的， 于是就写了*p = '\0';   上面程序产生了低概率的运行错误。 那作为程序猿， 我们应该怎样避免这样的问题呢？ 我们更改一下上面的程序：

 

#include <iostream>
using namespace std;int main()
{const char *p = "abc";// ...// ...char c = 100; // 随机值if(123 == c) {cout << "if" << endl;*p = '\0';}// ...return 0;
}

        再编译一下， 发现根本通过不了编译， 此时， 程序猿就意识到自己哪个地方有问题了， 于是去修改 *p = '\0'; 这样的错误。 这样， 就不会有什么低概率的运行期错误了。所以说， 加上const是安全的， 它能保证程序错在编译期间， 强迫程序猿做出修改。 反之， 如果到了运行期， 软件到了用户手上， 出现运行期错误， 那就惨了。
        有时候， 一些程序猿遇到上面第二个程序的编译错误后， 居然想办法把const去掉， 让程序通过了编译， 而且运行居然也没有出错， 以为万事大吉，无语啊

 

        

        再举个常见的例子， 我们一直强调： if(NULL == p)比if(p == NULL)好， 其实是在防止程序猿将 == 写成=, 我们可以看一下， 如果程序猿不小心， 将==写成了=, 那就是if(NULL = p)和if(p = NULL)了, 前者会产生编译期错误， 编译器会发现， 强迫程序猿修改； 后者极有可能产生运行期错误， 用户会发现。

 

        总之， 运行期的错误时非常致命的。 我们要提高代码质量， 提前避免潜在的问题。

 

这篇关于宁愿犯编译期错误， 也不犯运行期错误 ---再谈 char *p = “abc“； 的不合理性 以及 写成 if(NULL == p)而不是if(p == NULL)的理由的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---