为何某些公司不允许使用 C++ STL？

最初开始禁用 C++ STL，更多的是早期项目编码实践中留下的惯例，被后来的程序员继承下来。老项目中这种选择尤其地多。不过如果有人将其上升到公司行为在不同项目中全面禁用 STL，则没有必要，而且我倾向于做这种决定的人并不理解 C++ 编译系统。

一般来说，项目中禁止用 C++ 多见于两种具体场景：或者项目的产出产品为函数库或者需要引用第三方函数库。常见的是会限制STL的某些容器使用，因为有些容器的操作线程不安全，内存管理也不高效。

但是要是完全禁止STL，也无意义因噎废食。STL包罗的东西很多除了容器还有算法、函数对象等。算法是相当方便的轮子，佩服STL的作者Alex Stepanov，将复杂、相似的问题用算法、迭代器、函数对象这种抽象来解决。

游戏后端不用stl是祖传代码留下来的陋习，最开始服务端代码上来就申请一大块共享内存，重载new，用pod方式存放有限玩家数据。

1、性能 随着C++11标准在各大编译器的实现，有了move和rvalue，STL的性能不会是瓶颈，而且另一方面，既然程序要最高的性能，但选择了C++语言而不是C或者assemble，看来还是看重C++的抽象能力。

2、不愿使用异常。如今除了 Android 上的 STLPort 关闭异常，大部分主流 C++ STL 实现里都无法脱离异常使用 STL。异常带来的问题主要是两个：性能下降，代码膨胀。

3、C 兼容。严格地说，STL 在这个问题上算是躺枪，这个坑在很多具体的场景中也是因为异常而引入，但这个问题的麻烦程度比前两个问题更高。比如 gcc 在编译纯 C 代码时默认关闭 -fexceptions 选项，因此这样编译出来的代码中没有异常处理相关的栈展开。

说到底还是因为人的（最低）水平不行。C++语言特性太丰富，轻轻松松就能写出。尤其是新手，最喜欢把代码写得fancy而不是bug-free。团队里只要有几个这样的人，整个项目就完蛋了。

STL展现的思想是基于模板的静态类型系统的一个极致。这也是为什么更多的主流语言加入模板支持的原因。

顺便说一下3ds Max内部实现代码用的是Peer Review模式，只需要有任意的另一个Code Reviewer审核过代码，就可以合并到开发分支。

C++对模板的支持语法上有点复杂， 语义上由于C++类型系统的不完备也略显冗余，但是其外部效果应该是完全达到了。

Reviewer会质疑任何有潜在问题的改动，包括各种C++问题，比如是否做到向前兼容、向后兼容、二进制兼容，是否有业务上的逻辑问题，是否符合C++的代码规范和最佳实践，是否测试过重要的第三方插件等等。

按照Dr Stroustrup的说法（Element of Programming的评语），“... contains some of the most beautiful code I have ever seen.”。TG：li9047