這不是造輪子，而是技術選型的一種取舍，好的東西不一定合適。
大學我也是學的c語言，但是畢業就還給老師了。
第一份工作是主用c++，與其說是用c++不如說是在用stl，因為初學當時字串和容器沒有替代方案，並且大家都用，我自然也是隨大流。
初次看到boost這東西感覺這玩意真好啊，好多神奇的寫法，好厲害的樣子。然後立刻拉下來編譯和使用。當時就發現了它的一些弊端，它的體量太大了，全部編譯耗時很久生成庫檔比較大，配置編譯的話選項過多學習成本略大。但是這些困難沒有攔住我使用它的熱情。我當時使用了智慧指標，asio，還有幾個介面，沒用太多是因為我當時只用在自己的工程上，真的用不上太多功能。
慢慢的，我參與的計畫多了。在眾多業務的實作過程中，發現boost裏的很多元件其實於我而言並非必須。比如asio這個直接使用c的網路介面和系統io足夠覆蓋我的需求範圍。智慧指標這個更是基本沒有太硬性的使用場合（我只在設計事件系統的回呼函式連結串列時用上了），在充分理清記憶體和數據的有效範圍和所有權以後，絕大部份情況，我只需要在裸指標定義時加上一行註釋就能明確它的作用。
我開始反思：既然我有更合適的替代品，那麽引入一個幾G的庫是否真的有必要？於是boost慢慢被我移除了。它變成了一份參考案例。
比較常用的元件有哪些呢？我總結的是這麽幾個。
平台無關的元件：
容器類：字串，kv表，陣列，連結串列。
數學類：三角函式，科學函式，線性代數等。
通用演算法：md5，sha，隨機數等。
轉字串：整形浮點等與字串互轉。
平台相關的元件：
io類：檔讀寫操作，和檔狀態，遍歷目錄等。
時間類：休眠，計時器。
網路介面：套接字相關，多路復用等。
執行緒類：各種鎖，條件變量，執行緒。
系統特有：文字排版，系統View概念，鑰匙串等。硬體資訊類：記憶體資訊，顯卡資訊，處理器等。
還有很多也沒必要羅列了，從這份清單上我發現，其實業務方面更多的需求難點來源於os層的特有介面。平台無關的元件需求通常沒那麽奇葩，並且替代品比較好找。那麽這些需求stl或者boost解決了嗎？顯然只解決了極少部份，而且這些部份有更輕量的替代方案。鑒於成本，移除boost顯得合情合理。我的業務範圍以內，無需使用boost的任何元件。
有個意外，我似乎也無需使用stl的任何元件！我所需要的就是將llvm的string改成c版本，將linux的rbtree和list拷貝過來，就可以完成全c開發。。
我開始嘗試：全c開發的真正效率是怎樣的，瓶頸在哪？。完成全c開發切換後，我驚訝的發現，開發效率基本沒變，而編譯效率和執行效率卻提升了，偵錯變得更快，特別是生成的中間檔（c++的obj檔大得出奇）大大減小，這一點在xcode上直接拯救了我。
從c到c++再回到c，每次的轉變驅動其實都是效率。第一次c轉c++是因為c++的stl帶來業務編寫上的便利；第二次轉換是因為在已經有替代stl的基礎上c帶來了編譯速度體積和偵錯效率的提升。
當然，使用純c開發必須使用一套成體系的方法論，來保障記憶體和數據安全。但是與帶來的收益相比顯得劃算得多。
下面是記憶體相關的部份條例：
1、能int a就無需malloc int。
2、分配和釋放保持配對。
3、註意帶指標結構的淺拷貝。
4、分配和釋放中間夾雜break或return亮紅燈。
5、棧記憶體上限約1m，超過可能造成會崩潰。
6、智慧指標是一種思想（c也有），沒必要排斥。
7、指標定義時建議標明所有權和有效範圍。
8、能不分配就不分配。
