嵌入式C ++：要使用STL吗？ [英] Embedded C++ : to use STL or not?
问题描述
现在我发现自己在一个更通用的嵌入式世界在一个小型的初创企业中，我可能会转到不那么强大的处理器（有主观的位置） - 我无法预测哪个。
我已经阅读了关于在嵌入式系统中在C ++中使用STL的争论，并没有明确的答案。对可移植性有一些小小的担忧，还有一些关于代码大小或运行时间的问题，但是我有两个主要的问题：
1 - 异常处理;我仍然不确定是否使用它（请参阅嵌入式C ++：使用例外或不是？）
2 - 我非常不喜欢嵌入式系统中的动态内存分配，因为它可以引入问题。我通常有一个缓冲池，它在编译时静态分配，并且只提供固定大小的缓冲区（如果没有缓冲区，系统复位）。当然，STL做了大量的动态分配。
现在我必须决定是否使用或放弃STL - 对于整个公司，永远（它将进入一些非常核心的s / w）。
我跳哪种方式？超级安全失去了很多什么构成C ++（imo，它不仅仅是语言定义），也可能在以后遇到问题，或者必须添加大量的异常处理和可能还有一些其他的代码呢？
我很想去，只是用 Boost ，但是1）我不知道它是否将端口到我可能想要使用的每个嵌入式处理器和2）在他们的网站上，他们说他们不保证/推荐某些部分嵌入系统（特别是看起来很奇怪的FSM）。如果我去Boost&我们稍后找到一个问题....
超级安全&失去很多
构成C ++（imo，它超过
只是语言定义）和
可能会在以后遇到问题或
添加大量异常处理&
可能还有一些其他代码？
我们在游戏世界中有类似的辩论，人们双方都下来。关于引用的部分，你为什么要担心丢失大部分是什么构成C ++？如果不务实，不要使用它。如果它是C ++，不要紧。
运行一些测试。您能以满足您的方式了解STL的内存管理吗？如果是这样，那么值得吗？很多问题STL和boost是设计解决只是平原不要出来，如果你设计避免随机的动态内存分配... STL解决你面临的具体问题？
很多人在紧张的环境中解决了STL，并对此感到高兴。许多人只是避开它。有些人建议全新标准。我不认为有正确的答案。
I have always been an embedded software engineer, but usually at Layer 3 or 2 of the OSI stack. I am not really a hardware guy. I have generally always done telecoms products, usually hand/cell-phones, which generally means something like an ARM 7 processor.
Now I find myself in a more generic embedded world, in a small start-up, where I might move to "not so powerful" processors (there's the subjective bit) - I cannot predict which.
I have read quite a bit about debate about using STL in C++ in embedded systems and there is no clear cut answer. There are some small worries about portability, and a few about code size or run-time, but I have two major concerns:
1 - exception handling; I am still not sure whether to use it (see Embedded C++ : to use exceptions or not?)
2 - I strongly dislike dynamic memory allocation in embedded systems, because of the problems it can introduce. I generally have a buffer pool which is statically allocated at compile time and which serves up only fixed size buffers (if no buffers, system reset). The STL, of course, does a lot of dynamic allocation.
Now I have to make the decision whether to use or forego the STL - for the whole company, for ever (it's going into some very core s/w).
Which way do I jump? Super-safe & lose much of what constitutes C++ (imo, it's more than just the language definition) and maybe run into problems later or have to add lots of exception handling & maybe some other code now?
I am tempted to just go with Boost, but 1) I am not sure if it will port to every embedded processor I might want to use and 2) on their website, they say that they doesn't guarantee/recommend certain parts of it for embedded systems (especially FSMs, which seems weird). If I go for Boost & we find a problem later ....
Super-safe & lose much of what constitutes C++ (imo, it's more than just the language definition) and maybe run into problems later or have to add lots of exception handling & maybe some other code now?
We have a similar debate in the game world and people come down on both sides. Regarding the quoted part, why would you be concerned about losing "much of what constitutes C++"? If it's not pragmatic, don't use it. It shouldn't matter if it's "C++" or not.
Run some tests. Can you get around STL's memory management in ways that satisfy you? If so, was it worth the effort? A lot of problems STL and boost are designed to solve just plain don't come up if you design to avoid haphazard dynamic memory allocation... does STL solve a specific problem you face?
Lots of people have tackled STL in tight environments and been happy with it. Lots of people just avoid it. Some people propose entirely new standards. I don't think there's one right answer.
这篇关于嵌入式C ++：要使用STL吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
