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

文章图片

文章图片

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

【C++|为何某些公司不允许使用 C++ STL？】一般来说，项目中禁止用 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.” 。