c++ - 使用 STL 克隆有哪些优势？

Question

• 我什么时候需要 C++ 的 STL 的替代品？
• 使用替代 STL 有什么优势吗？
• 如果有的话，你会推荐哪些？

很抱歉这些菜鸟要点，但我看到很多产品都链接了不同的 STL，我想知道这样的东西什么时候有用。

Answer 1

我假设您在谈论 STL 的替代实现，而不是 STL 的替代方案。

您可能使用 3rd 方 STL 实现而不是编译器提供的默认实现有几个原因。

1. 一致性 - 您可能正在使用多个编译器并希望确保在每个平台上获得相同的行为。

2. 速度 - 一种实现可能比您的编译器提供的更有效。

3. 完整性 - 您的编译器默认库可能无法提供完整的 STL 功能。（这可能仅适用于旧编译器、嵌入式系统编译器或 C++11 功能）。

4. 额外功能 - STL 的一些实现提供了改进的无效迭代器调试等功能，这些功能可能不在您的编译器实现中。

显然，并非所有这些都适用于所有编译器.. 但在某些情况下，第 3 方 STL 肯定会有所帮助。

至于实现：你可以在这里找到一个列表

Answer 2

迈克尔提供了一个很好的答案 - 只需添加几点：

• “速度”不仅仅是一个线性的东西，你可以果断地说 STL 实现 X 比 STL Y 快 N%：在各种使用场景中，存在权衡速度和内存使用的实现选择。例如，“短字符串优化”可能允许将非常短的字符串直接存储在字符串对象中而不是堆内存中；对于超出当前容量的容器调整大小的方式，实现可能会略有不同。

• 二进制互操作性很重要：如果您需要调用预编译的库函数以接受 STL X 对象，您不能简单地链接该库并为其提供 STL Y 等效项：可能会在损坏的名称中存在差异，从而阻止链接时，对象的二进制布局很可能会有所不同，即使没有并且您强制执行此类调用 - 您的客户端代码对这些对象执行的操作可能不是库代码所期望或需要的所有内容（即不会维护相同的不变量）。

• 线程安全是“额外功能”的一个值得注意的例子……例如，许多早期的 STL 在 Copy-on-Write 字符串实现方面存在错误。

Answer 3

另一点：一些 STL 实现允许您禁用异常，可能使用自定义全局错误处理程序而不是 C++ 异常。这在今天已经不那么重要了，但是很长一段时间以来，很多系统由于各种原因禁用了异常，并且仍然有一些异常系统不鼓励或完全不支持异常。