这不是造轮子，而是技术选型的一种取舍，好的东西不一定合适。
大学我也是学的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、能不分配就不分配。
