Re: [討論] 大家對Ｃ語言中 free() 的看法？

[chchwy (mat)]

你的作法有個隱藏前提「記憶體用之不盡取之不竭」
但是事實上要看應用情境

首先，
如果只是進行一次性的計算，工作做完後就結束
而且你非常確定記憶體總用量不會超過系統記憶體，
那麼確實可以省一點管理記憶體的腦袋功夫

但是，
如果你的程式需要跑比較長的時間
例如系統服務(通常程式要活上好幾天)
或者一些應用程式(如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

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 219.85.1.14
※ 文章網址: https://www.ptt.cc/bbs/C_and_CPP/M.1434266491.A.AB2.html
※ 編輯: chchwy (219.85.1.14), 06/14/2015 15:26:30
推 rodion: 可以不需要check null for p when free(p)吧
推 arthur104: 可以 free裡面有說到
推 twooo333: 既然可以設macro 來保證指標有被指向NULL
→ twooo333: 那當初設計free時 怎麼不直接加入 有不需要NULL的情況嗎
→ suhorng: 設計 free 時不加入是指把 free 直接定成 macro 嗎?
→ uranusjr: 其實嚴格來說沒有「必須」設成 NULL 啊, 只對人類有差
→ Feis: 即使訂成 macro 也沒辦法解決所有的問題.