你的作法有個隱藏前提「記憶體用之不盡取之不竭」
但是事實上要看應用情境
首先，
如果只是進行一次性的計算，工作做完後就結束
而且你非常確定記憶體總用量不會超過系統記憶體，
那麼確實可以省一點管理記憶體的腦袋功夫
但是，
如果你的程式需要跑比較長的時間
例如系統服務(通常程式要活上好幾天)
或者一些應用程式(如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