对于STL或!STL,这就是问题所在

Question

毫无疑问,我会选择将STL用于大多数C++编程项目.最近我提出了这个问题,"有没有你不会使用STL的情况？"......

我越是想到它,我就越意识到也许应该是我选择不使用STL的情况......例如,一个非常大的长期项目,其代码库预计将持续数年......也许是真正符合项目需求的定制容器解决方案值得最初的开销吗？你怎么想,有没有你选择不STL的情况？

Answer 1

不使用STL的主要原因是:

1. 您的C++实现是旧的,并且具有可怕的模板支持.
2. 您不能使用动态内存分配.

两者在实践中都是非常罕见的要求.

对于一个长期项目来说,滚动自己的容器与STL功能重叠只会增加维护和开发成本.

Answer 2

具有严格内存要求的项目(例如嵌入式系统)可能不适合STL,因为很难控制和管理从堆中获取和返回的内容.正如Evan所说,编写适当的分配器可以帮助解决这个问题,但是如果你计算所使用的每个字节或者关注内存碎片,那么手动推出针对您的特定问题量身定制的解决方案可能更为明智,因为STL已经过优化用于最常用的用途.

您也可以选择不对特定情况使用STL,因为存在不在当前标准中的更多适用容器,例如boost :: array或boost :: unordered_map.

Answer 3

使用stl有很多好处.对于长期项目而言,收益大于成本.

1. 新程序员能够从第一天开始理解容器,让他们有更多时间学习项目中的其他代码.(假设他们已经像任何有能力的C++程序员那样知道STL)
2. 修复容器中的错误会浪费时间,浪费时间来增强业务逻辑.
3. 很可能你不会写它们,因为无论如何都要实现STL.

话虽这么说,STL容器根本不处理并发问题.因此,在需要并发的环境中,我会使用其他容器,如英特尔TBB并发容器.这些使用细粒度锁定更加先进,这样不同的线程可以同时修改容器,并且您不必序列化对容器的访问.

Answer 4

通常,我发现最好的办法是将STL与自定义分配器一起使用,而不是用手动的STL容器替换STL容器.关于STL的好处是你只需为你使用的东西付费.

Answer 5

我认为这是一个典型的构建与购买场景.但是,我认为在这种情况下,我几乎总是'买',并且使用STL - 或者更好的解决方案(也许来自Boost),然后再推出自己的.您应该将大部分精力集中在应用程序的功能上,而不是它所使用的构建块上.

Answer 6

我真的不这么认为.在制作我自己的容器时,我甚至会尝试将它们与STL兼容,因为通用算法的功能太大而不能放弃.STL至少应该名义上使用,即使您所做的只是编写自己的容器并专门为它准备每个算法.这样,每个排序算法都可以调用sort(c.begin(),c.end()).如果你专门排序以产生相同的效果,即使它的工作方式不同.

Answer 7

编码为Symbian.

STLPort确实支持Symbian 9,所以反对使用STL的情况比过去要弱("它不可用"是一个非常有说服力的案例),但STL仍然对所有Symbian库都不同,所以可能比单纯的更麻烦以Symbian方式做事.

当然,基于这些理由可能会认为Symbian的编码不是"C++编程项目".