你的作法有个隐藏前提“内存用之不尽取之不竭”
但是事实上要看应用情境
首先，
如果只是进行一次性的计算，工作做完后就结束
而且你非常确定内存总用量不会超过系统内存，
那么确实可以省一点管理内存的脑袋功夫
但是，
如果你的程式需要跑比较长的时间
例如系统服务(通常程式要活上好几天)
或者一些应用程式(如Word) 使用者可能会运行操作数个小时
你真的可以保证内存不会用完吗?
※ 引述《Hazukashiine (耻ずかしい ね...(>///<))》之铭言：
: 许多教程式的教授或是工程师会认为一个好的程式中 free() 与 *alloc() 必须成对。
: 但是，事实上，执行 free() 并不会把 memory 还给 operating system，
: 反而是告诉程式，下一次 *alloc() 的时候，可以用一下之前 free() 过的空间。
: 这种设计并不坏，主要是为了节省 system call 的时间消耗。
: 虽然心中觉得成对会比较严谨一点，不过在实作的时候确实会容易造成问题。
: 问题一：
: 前一个人 free() 掉之后，并没有把指标设成 NULL，然后还在 code 中到处流串，
: 只要一不小心，*** glibc detected *** double free or corruption 就会死给你看，
: 这种 bug 最恶心了，尤其在其他 code 不是你写的时候。
: 问题二：
: 当一个函数的回传值是一个指向空间的指标的时候，
: 而且这个函数会将这个指标送给超过一个的函数的话，
: 只要其中一个函数 free() 掉之后，其他的函数也会跟着遭殃，
: 通常会送个 Segmentation fault (core dumped) 当作圣诞节礼物。
free()之后没有把指标设成NULL
通常会用简单的 macro，如:
#define SAFE_DELETE(p) if (p) { free(p); p = NULL; }
来替代直接调用 free() 这样就不会忘记了
不管怎样，
解决之道应该是找出问题的源头:
1. 哪里没设 NULL
2. 为什么重新配置资源后，不会通知其他模组?
会有 dangling pointer 四处流窜
我觉的软件系统的设计问题比较大
你们系统的资源管理流程是不是很杂乱?
有没有一套共同遵守的作法?
应该要好好审视这个问题
而不是用不归还内存来解决
: 程式在结束的时候，大部分的作业系统都会回收内存，
: 所以，若在程式码结尾的地方 free() 掉所有申请过的空间，也是多此一举。
: 我的看法是，若该指标出现在循环中或是递回中的话，才有使用 free() 的必要，
: 其余的指标就让作业系统去回收吧，毕竟通常吃内存的怪兽都是循环或递回中的指标。
: 大家怎么看？通常都会严格遵守成对的习惯吗？
我目前执行的专案
一启动就会花掉1G内存
每个操作都有可能配置数十MB的空间
如果没有严格的内存管理
跑不了半小时就会内存耗尽给你看
所以对我来说 这不是要不要遵守的问题
敢不遵守就试试看XDDDD