有没有情况下,开发人员应该避免在他/她的项目中使用C++ STL?
可能重复:
使用STL或者不使用STL, 这是个问题
有没有情况下,开发人员应该避免在他/她的项目中使用C++ STL?
可能重复:
使用STL或者不使用STL, 这是个问题
如果你不能使用 RTTI 和/或异常处理,你可能会发现 STL 的某些部分无法正常工作。例如,原生 Android 应用程序就是这种情况。因此,如果它不能满足你的需求,这就是不使用它的原因!
不完全正确。除非该库只提供一种功能(这并不是标准库的情况),否则禁止使用整个库是没有道理的。应该根据每个函数的特点来评估提供的功能。例如,你可能会认为需要一个执行比 vector
更具体目的的容器,但这并不是禁止使用 deque
、iostream
或 for_each
的借口。
更重要的是,通过模板生成的代码不会比手写的等效代码更臃肿。拒绝使用 std::vector
并编写自己的 float 和 double 向量的等效代码并不能减少代码膨胀。尤其是在2011年,可执行文件的大小在绝大多数情况下与媒体等其他东西相比毫无意义。
关于uTorrent大小的一些信息:
官方FAQ(来自2008年),这个问题在最近的FAQ中没有出现。
请注意,即使uTorrent>300kb并且使用UPX压缩,但考虑到它所能做的事情,它仍然非常小。
它可能会增加可执行文件的大小。如果你正在运行嵌入式平台,你可能希望排除STL。
唯一的原因是,如果您正在使用内存较低的嵌入式系统工作,或者如果您的项目编码指南明确禁止STL。
我找不到其他合理的理由来手动滚动自己不兼容、错误满载的STL某些功能的实现。
当您使用实现相同功能的Qt库等内容时,可能不需要STL。这可能取决于其他需求,例如性能。
TR18015讨论了STL的一些限制。它从不同的角度来看待问题——编译器能做得更好——但仍然是一个有趣(如果深入)的阅读。
总的来说,在微处理器和小型嵌入式系统中要小心。首先,编译器优化不如桌面计算机那么高效,而且你很快就会遇到硬件限制。
话虽如此,这在很大程度上取决于你使用的库。I/O流通常很慢(需要仔细实现才能避免),而std::vector
只是一个薄薄的包装。