嵌入式 C++:要不要使用 STL?
我一直是一名嵌入式软件工程师，但通常在 OSI 堆栈的第 3 层或第 2 层.我不是一个真正的硬件人.我一般都做电信产品，通常是手/手机，这通常意味着类似于 ARM 7 处理器.
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.
我已经阅读了很多关于在嵌入式系统中使用 C++ 中的 STL 的争论，但没有明确的答案.有一些关于可移植性的小担忧，还有一些关于代码大小或运行时的担忧，但我有两个主要的担忧:
1 - 异常处理；我仍然不确定是否使用它(参见 嵌入式 C++:使用异常或不是吗?)
2 - 我非常不喜欢嵌入式系统中的动态内存分配，因为它会带来一些问题.我通常有一个缓冲池，它在编译时静态分配，并且仅提供固定大小的缓冲区(如果没有缓冲区，则系统重置).当然，STL 做了很多动态分配.
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.
现在我必须决定是使用还是放弃 STL - 对于整个公司，永远(它进入一些非常核心的软件).
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).
我往哪个方向跳?超级安全失去了构成 C++ 的大部分内容(imo，它不仅仅是语言定义)，并且可能稍后会遇到问题或必须添加大量异常处理和；也许现在还有其他代码?
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?
我很想只使用 Boost，但是 1) 我不确定它是否会移植到我可能想使用的每个嵌入式处理器和 2) 在他们的网站上，他们说他们不保证/推荐嵌入式系统的某些部分(尤其是 FSM，这看起来很奇怪).如果我选择 Boost &我们稍后发现问题....
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 ....
推荐答案
超级安全&失去很多东西构成 C++(imo，它不仅仅是只是语言定义)和也许以后会遇到问题或有添加大量异常处理 &也许现在还有其他代码?
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?
我们在游戏世界中也有过类似的争论，双方都反对.关于引用的部分，您为什么会担心失去构成 C++ 的大部分内容"?如果它不实用，请不要使用它.它是否是C++"应该无关紧要.
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.
运行一些测试.你能以你满意的方式绕过 STL 的内存管理吗?如果是这样，值得付出努力吗?如果您的设计是为了避免随意的动态内存分配，那么 STL 和 boost 旨在解决的很多问题就不会出现……STL 是否解决了您面临的特定问题?
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?
很多人都在紧张的环境中处理过 STL 并对此感到满意.很多人只是避免它.有些人提出了全新的标准.我认为没有一个正确的答案.
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.
相关文章