什么时候应该使用编译器附带的STL以外的STL?

Mar*_*off 30 c++ stl

我对使用gcc或Visual Studio打包的STL实现感到好奇,因此快速的Google搜索结果显示了一些结果,例如:

在什么情况下应该使用替代标准模板库?

例如,Apache的页面有一个列表,其中包括"完全符合C++标准"和"针对快速编译和极小的可执行文件大小进行了优化"等项目.如果它太好了,为什么不能取代libstdc ++?


为了完整起见,以下是一些其他STL实现:

Lea*_*elo 13

我从来没有使用过编译器以外的STL版本.但是我想到了一些观点.

  • 线程安全:来自apache的STL提供了一个编译开关来打开/关闭一些线程安全功能.
  • 本地化:来自apache的STL再次为许多不同的语言环境提供了很好的支持.
  • 数据结构:您可能需要一个basic_string基于COW(写时复制)的实现,并且您的编译器附带的STL版本不提供.
  • 非标准扩展:您喜欢其他一些STL实现的特定功能.例如,hash_map(以及相关的)从Dinkumware的版本(它随Visual Studio中)有从显著不同的设计hash_map,从(以及相关的)STLPort的.
  • 二进制问题:由于代码大小,在某些环境(嵌入式软件)中存在约束.在这种情况下,如果您不需要整个STL,那么使用简化版本可能会很有趣.
  • 性能:如果您在分析后发现"其他"STL实现为特定应用程序提供了显着更好的性能,那该怎么办?(有了很多关于算法和数据结构的细节,这实际上是可能的.)
  • 调试模式:某些STL实现为调试提供了很好的功能.例如,检查迭代器的范围.


Len*_*ate 10

我有时使用STLPort而不是Visual Studio附带的STL.当支持VC6时,它附带的STL是错误的,所以使用STLPort(或其他STL)很有意义(特别是如果你正在构建多线程代码).

现在通常更多的是关于性能(大小或速度).例如,VS2008附带的STL在多线程情况下并不友好,因为它使用区域设置对象锁定,导致您不希望跨线程同步的事情.(请参阅此处将数字转换为C++中具有指定长度的字符串,以获取此示例的详细信息).


Cha*_*via 3

我从来没有需要使用替代的 STL,但我可以设想一些可能有用的场景,例如,如果您因为正在为嵌入式平台进行开发而需要小型可执行文件,则可以使用 Apache 版本。

另一个原因可能是使用 STL 版本来保证标准不一定保证的某些事情。例如,确保您拥有非 COW 字符串,以便您可以编写线程安全代码。