在C ++开发中放弃STL是否可行？[关闭]

我知道在某些领域（例如游戏行业），不建议使用STL。所以我的问题是：在某些情况下不使用STL是否真的是一个好习惯？如果是这样，不使用现代C ++的STL的最大原因是什么？

• 我只能想到一个正当的理由，这真的很罕见：实时性很差。标准库中的许多内容都是在内部分配内存的，对于硬实时应用程序而言，这还不够确定，因此必须避免。这些应用程序通常非常简单，但是由于非常严格的审查和测试，它们花费了不成比例的时间来开发。

• 我可以想到一个无效但很常见的原因：不了解计算复杂性的开发人员会滥用STL，然后将其归咎于库。

  STL在运行时通常比具有回调指针的C样式解决方案或具有虚拟方法的基于多态的解决方案要快（另请参见此Bjarne Stroustrup的主题演讲）。但是，当开发人员不理解给出的复杂性规范，并通过创建某些复杂对象的向量vector之类的东西来滥用库时（在C ++ 11中，这不再是问题！），会导致性能问题，并且无法保护自己如果您看到“向量很慢”，则可能会导致人们认为标准库很慢。经理一旦有了这种认识，就可以在组织中生存很长时间。

• 显然，您不能使用目标平台不支持的任何功能。但是，我们目前的目标是四个最常见的移动平台（Android，iOS，Bada和旧的WinCE），并在所有平台上使用标准库和Boost的某些部分。

  Microsoft在WinCE早期就不支持许多标准库（IIRC iostream仅随Visual Studio 2005一起提供），但是有可能在此之前使用STLport很久了。通常，您可以将其编译为任何东西。因此，我也将这个原因称为无效。

  此外，长期以来，它不是“ STL”，而是ANSI C ++标准库。它是由定义语言本身的同一标准文档定义的。任何不支持它的东西都不应该真正被称为C ++。

我使用STL并提升了很多年。如果我想放弃它并使用我的自定义工具，其动机将是：

1. 减少编译时间（75％）。仅包含iostream即可向模块添加一百万行代码。是的，预编译的头文件有很大帮助，但是在大型项目中，它仍然使编译速度大大降低。从长远来看，这样做会浪费很多时间在工作上。
2. 性能。（25％）STL通常可以正常工作，但是您可以优化结构以完全按照需要工作。例如，您可能有一个包含数百万个短字符串的数据结构。使用基于boost :: small_vector原理的自定义字符串类可能要快得多（基于数据的静态小局部矢量，仅对较大的字符串进行动态分配），这些更改可以使关键代码段的工作速度提高许多倍。

没有使用C ++标准模板库的一个很大的正当理由：您的目标平台之一没有完全符合要求的实现（或者根本没有实现），并且您知道它不会得到一个在未来几年内。

我不了解复杂性（实现的效率），但是我广泛使用Qt容器和字符串而不是标准容器和字符串，它们可以正常工作。我还发现集和列表的Qt实现更易于使用。

因此，如果可以使用其他满足您需要的库，则放弃STL是很实际的。

Patrick提到了不使用整个STL的原因，即您的平台没有一个。

总而言之，我认为这个问题没有抓住重点。这基本上不是一个全有或全无的决定，而是一个选择的选择。您可能会决定使用容器和算法，但决定将Std Lib之外的内容用于字符串和I / O。

除非有充分的理由，否则这是不实际的。我可以想到的一些这样的原因包括您仅需解决的STL（或标准库的任何其他部分）的部分实现或缺乏实现或资源限制（内存，CPU速度，存储等）。滚动您自己的工具，使其符合您需要完成的工作。

在游戏行业中，大多数（甚至在某种程度上甚至更小）工作室都具有内部库和许多标准库部件的实现，这些库部件高度适合目标平台，在某些情况下还针对英语甚至游戏本身。简而言之，在开发游戏机游戏时，硬件受当今标准的限制。出于某种原因，有成千上万的手工装配线。最大限度地减少代码中的各种资源占用非常重要，这样游戏才能更快地运行，从而可以在游戏世界（例如更大的世界）中提供更多内容，从而有望带来更好的产品。

“每个成功的游戏都始于推出自己的链表实现。”