嵌入式环境下的STL

STL有很多问题(如本文所述 EASTL PSP port of Aquaria

我的建议是 在遵循假设之前进行第一次测试

最后,boost是基于模板的,所以如果你看生成的模板代码的大小,它将遭受与STL相同的痛苦。

只是为了澄清我上次的陈述。在C语言中,你可以(ab)使用相同的代码在共享相同头(或布局)的不同结构上执行相同的工作,但是对于模板,每种类型可能都有自己的副本(如果启用了“优化大小”,我从来没有测试过编译器是否足够聪明来执行此操作),即使它与刚刚生成的完全相同(在机器/程序集级别)。boost的优点是读起来更干净,并且有更多的东西被塞进其中,但是由于大量(有时是巨大的)头,这可能导致编译时间过长。STL的收益是因为你可以传递你的项目,而不需要boost的下载/伴随。

在arm系统上,你有足够的内存。使用STL!

我看到了这个演示: Standard C++ for Embedded Systems Programming

与运行时系统相比,模板的大部分复杂性在于编译器,这也是问题所在——因为我们不确定编译器能够完成多少优化。事实上,基于STL的C++代码应该比C++模板更紧凑和更快,而不是使用模板,甚至是C代码!

模板导致更大代码的概念背后有一些逻辑。基本思想非常简单:模板的每个实例化都产生本质上独立的代码。这在早期编译器中尤其有问题——因为模板(通常)必须放入头中,模板中的所有函数都是 inline vector<int> 在10个不同的文件中实例化,你(理论上)有10个你使用的成员函数的独立副本,一个对应于你使用它的每个文件。

任何一个相当新的编译器(比如不到10年)都会在链接器中有一些逻辑将它们合并在一起,所以实例化

另一点(仍然正确)是模板可以使创建一些相当复杂的代码变得容易。如果你在用C语言自己写东西,你通常会有强烈的动机去使用最简单的算法、集合等来完成这项工作——足够的动力让你很可能去检查细节,比如你可能遇到的最大项数,看看你是否能在真正简单的事情中脱身。模板可以使使用通用集合变得如此容易,以至于您不必费心检查这样的内容,所以(例如)您最终得到了构建和维护一个平衡树的所有代码,即使您最多只存储(比如)10个项,所以使用线性搜索的简单数组可以节省内存,并且通常运行得更快。

大多数安全关键系统的指导原则只是禁止使用动态内存分配。如果您不必担心malloc/new调用失败,那么设计程序就简单得多,也更安全。对于可能出现堆碎片的长时间运行的系统,您无法轻松证明内存分配不会失败,即使是在内存量很大的芯片/系统上(尤其是当设备必须运行数年而不重新启动时)。

我在大型项目中所做的是将实时和关键功能与其他功能隔离开来。非关键的东西可以用STL等标准工具编写。只要操作系统不妨碍关键部件,那就没关系了。如果我不能保证没有这样的交互,那就不要使用这些工具。

我在一个嵌入式项目中,使用了C++和STL,在一个非常受限的系统中(内存在一兆字节,ARMv4在低速下)。在大多数情况下,STL是很棒的,但是有些部分我们必须跳过(例如,std::map每次实例化需要2-4k代码[相对于ROM大小这是一个很大的数字],而且我们有自己的std::bitset的自定义替换[它可能是~1k ROM])。但是,std::vector和std::list非常有用,因为使用boost::intrusive\ptr进行引用计数(共享的ptr太大了,每个对象大约有40个字节的RAM!)。

使用STL的一个缺点是当异常被关闭时没有错误恢复(对于我们来说,异常和RTTI在我们的编译器中并不便宜)。例如,如果某个内存分配在这行代码的某个地方失败(std::map object):

my_map[5] = 66;

也就是说,我们在C++和STL方面取得了巨大的成功。就像海报上说的那样,试着用另一个系统来测量。作为一个侧重点,有一个伟大的技术报告,对C++的性能一般是一个良好的阅读: http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf

许多人认为(由于许多原因,比如便携性),C++不适合嵌入环境。有许多类型的嵌入式环境和STL当然是可以为其中一些。

一般来说,当你需要为资源受限的环境选择任何东西时,“更强大”总是一个让人害怕的短语,因为你通常想要的是功能较弱、更可控的东西。尤其是如果“更强大”意味着开发人员(或以后维护代码的人)对底层实现的理解会更少。

这样的系统可能有几千字节的RAM(或更少),也可能有许多兆字节甚至千兆字节。因此,内存限制可能是一个问题,也可能不是一个问题。

这并不是说它STL不能被使用,即使在实时应用中也是如此。但是,您需要仔细设计代码,以便知道在时间关键的过程中不会发生某些非确定性操作。

对我来说,只有一个很好的理由,不使用某些库,如果它不适合有限的约束或它的大小可能是以后的问题。如果这对你来说不是问题,那就去做吧。不管怎样,你不会好起来的。