作者：陈甫鸼
来源：知乎
最初开始禁用C++STL，是因为早期项目编码实践中留下的惯例，被后来的程序员继承下来。老项目中这种选择尤其地多。不过如果有人将其上升到公司行为在不同项目中全面禁用STL，则没有必要，而且我倾向于做这种决定的人并不理解C++编译系统。
一般来说，项目中禁用C++多见于两种具体场景：项目的产出产品为函数库OR需要引用第三方函数库。
具体地来说，有三个主要原因：
第一个原因是二进制边界混乱。
对需要在项目中使用第三方函数库的程序员来说，二进制边界是个头痛的问题。C++在这一方面本身就处理得不算好，加上模板后起到的是雪上加霜的后果。没有经验的程序员会贪图方便而在公开头文件中使用C++模板，如果这时调用方的编译器选项设置或STL版本和编译方不同，那么就可能出现同样的头文件在不同的环境下二进制布局不符的情况。
顺便说一句，在过去十年里，各个主流编译器附带的STL版本变化节奏不慢，所以这种由于编译环境不同而导致的bug并不算罕见，但缺乏汇编知识的用户难以排查。
第二个原因是不愿使用异常。
如今除了Android上的STLPort关闭异常，大部分主流C++STL实现里都无法脱离异常使用STL。异常带来的问题主要是两个：性能下降，代码膨胀。这几年C++编译器在性能方面的改进很多，goodpath的性能问题已经基本没有，但代码膨胀问题却没有太多改善，甚至这个性能问题的一部分解决方案就是以代码膨胀为代价。我写过一篇短文比对过Android上gcc4.6在有无异常的情况下的汇编代码逻辑，可以看到，启动异常时生成的汇编代码量多出了相当一部分（我的例子中是50%），用于处理各种隐含代码中的异常问题。这一条在手机系统中有时候会引起意想不到的麻烦，比如软件升级后导致app在低存储容量的手机中安装失败。顺便说一句，这个问题并不是gcc独有，clang上生成的代码是一样的。参考：