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

langue

我同样不认为 free() 之后应该自动置空，程序员应该有自己的选择，而不是简单、粗暴地 do it for you。

benjiam

我所有的代码在 free 以后都会设置成为NULL.
为下次扑捉 bug 提供条件。这是很个很普遍的做法。
而且我也能找到freen 以后设置为NULL 的很多优点， 简单的说 多线程的代码，当你发现一个不该出现 NULL指针的地方
出现了 你就可以找找是不是别的地方已经释放了。
当然你如果一定要在c++ 里面制作所谓的泄露，这个不是这样的写法能解决的问题。

如果你动则以 设计才是解决这类问题的终极方法， 我同意。但是我相信 大多数时候我们是看到了窟窿再开始找原因的。

还有这里很多人动则以性能作为借口，我想写程序最关键的一条是正确 而不是性能。

slow_hand

原帖由 benjiam 于 2009-11-26 13:40 发表
我所有的代码在 free 以后都会设置成为NULL.
为下次扑捉 bug 提供条件。这是很个很普遍的做法。
而且我也能找到freen 以后设置为NULL 的很多优点， 简单的说 多线程的代码，当你发现一个不该出现 NULL指针的地 ...

如果把赋值操作写到free里面，效率不会有啥影响吧？而且只有一份赋值操作的二进制拷贝，还可以节省空间。

flw

原帖由 slow_hand 于 2009-11-26 12:51 发表

既然有了p，为什么还要一个q呢？

因为指针支持赋值运算。
话说如果不支持赋值运算的话，还要指针干什么呢。

slow_hand

原帖由 flw 于 2009-11-26 14:09 发表

因为指针支持赋值运算。
话说如果不支持赋值运算的话，还要指针干什么呢。

当然可以赋给别的指针变量了。
那样的话，就是程序员自己不小心造成的问题。浅拷贝就是一个例子吧。

peidright

free的实现，跟c语言的设计，感觉没啥关系。没那么崇高。
设置为空，或者不空，都没啥讨论的意义。你认为应该设计为空，你可以再封装一次，
如果free设计为空，你看得不爽，则可以修改free的实现，写个不设置为空的代码。

无论如何，正确的代码，不应该因为上面的区别，而产生bug,一般，设置为NULL,能够让你更容易定位BUG,
但是对于某些容错的程序，如果检测指针为空，就采取其他的行为，也可能因此，而产生其他的隐藏的BUG.

koolcoy

我认为free后自动置成NULL没太大的问题。
持反对意见的给个例子说明一下置成NULL有不好的副作用。不要拿哲学说事，我是程序员不是哲学家

btw：不要认为C的全部都是好的

wishel

原帖由 koolcoy 于 2009-11-26 15:01 发表
不要拿哲学说事，我是程序员不是哲学家  

可是你在讨论语言设计的问题，而语言设计必须有明确的哲学。

zhoubug

原帖由 koolcoy 于 2009-11-26 15:01 发表
我认为free后自动置成NULL没太大的问题。
持反对意见的给个例子说明一下置成NULL有不好的副作用。不要拿哲学说事，我是程序员不是哲学家

btw：不要认为C的全部都是好的

你是想每次调用free这样 char *ptr ....free(&ptr);？
否则你想让语言设计怎么处理？改变它的函数调用时的传值规则？

[ 本帖最后由 zhoubug 于 2009-11-26 16:10 编辑 ]

shan_ghost

1、设计语言和设计库接口，想要好学好用并且稳定，就要遵循“完整且最小”原则

完整就是功能完整；最小就是没有任何一个功能和其他功能重复或可以通过组合其他几个功能拼凑出来。


2、C语言功能已经完整。现在再增加任何东西，都是在扩大已有接口。

3、扩大已有接口，实际上就是提供新的“语法糖”；那么如果没有很大好处，就不应该破坏接口的“完整且最小”基本原则。

4、包括malloc/free都不是C的关键字，何况free后置NULL

5、如前面网友所述，free后置NULL并不能保证所有指向这块内存区域的指针都被置为NULL

6、那么，free后，哪些必须手工置NULL，哪些不需要手工置NULL？或者，干脆不管系统有无置NULL，全都自己再做一遍？
显然，free后置NULL不光没有提供多少方便，反而因为无法保证一致性而制造出另外一种困扰。
这只能给初学者一种虚假的安全感或者更多的困扰。