既然是 C 語言, 其實沒什麼在意的點的話可以直接使用下面這個 Garbage Collector
http://www.hboehm.info/gc/
這個 GC 很有名, 被很多專案使用, 像是 Idris backend 就直接仰賴它, 因為方便
如果對 GC 的要求不是很多, 其實非常方便而且用起來很簡單
example 就非常簡單, 改成 GC_MALLOC 就對了
http://www.hboehm.info/gc/simple_example.html
它是 conservative garbage collector, 所以即使某些值(非指標)被誤當成
記憶體位置導致無法回收, 只要這種狀況不多就好 (通常是很少)
※ 引述《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() 掉所有申請過的空間，也是多此一舉。
: 我的看法是，若該指標出現在迴圈中或是遞迴中的話，才有使用 free() 的必要，
: 其餘的指標就讓作業系統去回收吧，畢竟通常吃記憶體的怪獸都是迴圈或遞迴中的指標。
: 大家怎麼看？通常都會嚴格遵守成對的習慣嗎？