对于 STL 或 !STL，这是个问题
毫无疑问，我会选择将 STL 用于大多数 C++ 编程项目.然而，最近有人向我提出了这个问题，在某些情况下您不会使用 STL?"...
Unquestionably, I would choose to use the STL for most C++ programming projects. The question was presented to me recently however, "Are there any cases where you wouldn't use the STL?"...
我想得越多，我就越意识到，也许应该有我选择不使用 STL 的情况……例如，一个非常大的长期项目，其代码库预计将持续数年.. 也许一个完全符合项目需求的自定义容器解决方案值得最初的开销?你怎么看，有没有你会选择 NOT STL 的情况?
The more I thought about it, the more I realized that perhaps there SHOULD be cases where I choose not to use the STL... For example, a really large, long term project whose codebase is expected to last years... Perhaps a custom container solution that precisely fits the projects needs is worth the initial overhead? What do you think, are there any cases where you would choose NOT to STL?
推荐答案
具有严格内存要求的项目(例如嵌入式系统)可能不适合 STL，因为它可能难以控制和管理取自和返回的内容堆.正如 Evan 提到的，编写适当的分配器可以帮助解决这个问题，但如果您正在计算使用的每个字节或关注内存碎片，那么手动滚动针对您的特定问题量身定制的解决方案可能更明智，因为 STL 已经过优化用于最一般的用途.
Projects with strict memory requirements such as for embedded systems may not be suited for the STL, as it can be difficult to control and manage what's taken from and returned to the heap. As Evan mentioned, writing proper allocators can help with this, but if you're counting every byte used or concerned with memory fragmentation, it may be wiser to hand-roll a solution that's tailored for your specific problem, as the STL has been optimized for the most general usage.
您也可以选择在特定情况下不使用 STL，因为存在当前标准中没有的更多适用容器，例如 boost::array 或 boost::unordered_map.
You may also choose not to use STL for a particular case because more applicable containers exist that are not in the current standard, such as boost::array or boost::unordered_map.
相关文章