为什么free或者delete的时候不直接将指针置成NULL？

langue

这个世界是无情的。

设计成不置空，有人骂。
设计成直接置空，还是有人骂。
设计者大吼一声：烦死了！你们爱怎么玩怎么玩去！

shan_ghost

大局利益和眼前利益的冲突而已。


对程序员：

1、指针无效后是否应该统统置为NULL

眼前利益： 很麻烦，而且无效指针根本就不应该再用到，弄个空值，然后遇到空怎么怎么，这种做法只会隐藏问题。

长远利益： NULL明确标识了某个指针是无效的。如果遇到不应该出现的空指针就立刻退出、assert或抛异常，那么就可以迅速发现并修改“使用无效指针问题”——因为指针设为NULL，结果导致Bug被隐藏，只能说你们短视，没有严格检查逻辑上不应出现的空指针。

于是，另一个眼前利益： 使用指针总是检查是否为NULL导致代码冗余，影响性能，还要多敲不少字符。

长远利益： 使用指针前总是检查是否为NULL可以尽早发现bug，并且可以通过预处理指令在发行版去掉这些检查，并不会影响性能（assert就是典型的仅在测试期检查的标准宏）。如果多敲几个字符就可以尽早发现bug的话，为什么不这样做呢？难道现在省下几个字符，会比将来少花费数小时甚至数星期查找bug效率更高吗？


2、系统标准函数库应否在free指针后自动置空

眼前利益： 少打一行代码； 避免马大哈程序员忘了置空

长远利益： 自动置空无法保证当前指针在其他地方的拷贝也同样被置空。这导致指针行为的不一致——为什么有些指针会在释放后自动变为空、另一些则保留了旧的非法值呢？

眼前利益： 在我鼻子尖前面1厘米的地方，指针从来不会被复制，从来都只存储一份

长远利益： 请使用望远镜，眺望下在你鼻子尖之前10厘米的地方——那里有各种容器类，还有排序/交换/索引算法，还有“先复制后交换”的免锁算法、“写时复制”等高性能低空间占用的优化算法。

[ 本帖最后由 shan_ghost 于 2009-12-2 10:20 编辑 ]

slow_hand

原帖由 langue 于 2009-12-2 00:52 发表
这个世界是无情的。

设计成不置空，有人骂。
设计成直接置空，还是有人骂。
设计者大吼一声：烦死了！你们爱怎么玩怎么玩去！

lemoncookie

再说
凭什么就要给置NULL
俺就是要在free之后再回去看看俺上次指向的地址
怎么，虽然给抄家了，记住门牌号码留个念想还不给吗？

纯属joke
:wink:

mirnshi

热闹非凡。闲聊几句：NULL和指针free有啥关系呀？NULL只是一个宏定义。free后的变量赋值只是为了将来做判断而已，打个标记，表示那个变量所指向的内存区已经还给OS了而已。赋值成(void*)1，(void*)2，都无所谓的。如果不赋值，改为设置标志变量，看看还有多少人没事找事地free后置个标志变量。

快乐的土豆

其实吧，计算机世界里面，null代表的不是空，而是不确定。换句话说，当你的  p ==NULL，仅仅是表示，你的p的指向是“不确定”的，不一定是一个“不可用”的指针。

triphop

1. 出于程序效率问题考虑，没必要增加这些操作。 尽管我通常是在代码中主动置0的
2. 在下面这种情况下，你将指针设置成0，也不起什么作用
    void
   foobar(char *dummy)
   {
       if (NULL != dummy)
       {
           // stuff goes here
           free(dummy);
           // 如果编译器给你做了 dummy = 0 工作，也无济于事
        }
   }

3. 有时候，可能free(ptr)中的ptr本身就不是左值吧
  比如 使用   foobar("must die"这样的方式调用上面的foobar函数

to407

原帖由 slow_hand 于 2009-11-26 10:20 发表
为什么语言本身不在free或者delete的时候直接将指针置成NULL？这样不就完全杜绝了“野指针”的问题吗？

因为语言设计本身 不需要越俎代庖 去决定程序员下一步要做什么