C++ 内存非常有限的嵌入式系统中的STL

我目前正在构建一个嵌入式系统，使用ARM Cortex M3处理器，具有64KB的SRAM。目前，我正在寻找一种方法来确保STL容器的确定性性能，包括确保在运行时不会耗尽内存

我主要关心STL容器如何执行动态内存分配。虽然我可以利用自定义分配器让这些结构从我留出的池中获取内存，但我需要为每个结构设置一个单独的池，以确保结构的一个实例不能占用另一个实例的空间

我正在与这个项目中的其他人一起工作，他们不想关心内存的原始分配，而是希望能够利用“众所周知”的数据结构（堆栈、队列、deque等）。因此，我目前正在考虑围绕C阵列构建包装器，以提供这些结构。这将允许静态分配支持这些容器所需的内存，并允许其他开发人员根据编译器提供的代码大小信息，知道他们在运行时之前实例化的容器的大小。在我看来，这保证了内存中断问题不会在运行时发生，并大大简化了系统设计

另一个选项涉及在系统初始化时分配STL容器。在初始化期间之后，不会发生额外的动态内存分配。然而，据我所知，标准的C++ STL数据结构不支持这一点——它需要像堆栈这样的容器能够预先分配（类似于向量）。 如果您对我关于围绕标准C阵列构建类的建议有任何意见，我将不胜感激？此外，有没有更简单的方法在编译时分配静态大小的STL容器，例如静态大小的堆栈或队列？（我知道这在vector中是可能的，但其他的我不确定）

注意：我已经通读了另一个问题（），但是这个问题的作者没有明确说明他们有多少内存（除了他们如何使用ARM7进程），或者似乎正在考虑类似于我的解决方案

---

第二个注意事项：我知道，对于一些开发人员来说，64KB的SRAM看起来可能会占用大量内存。事实上，我在AVR处理器上做过开发，内存明显减少，所以我理解这个观点。然而，从我目前的观点来看（可能是未知的），当谈到STL容器时，64KB的内存并不多。

这个问题有点困惑和奇怪。首先，让我们澄清一些误解

你提到“堆栈，队列，德克”的名字。嗯，其中两个不是容器<代码>堆栈和队列是容器适配器。看，它们实际上并不直接存储元素；它们只是将接口传递给它们<代码>堆栈确保只能推、弹出和获取顶部元素<代码>队列确保您只能向后推、弹出前面并获取前面的元素（虽然它也允许您获取后面的元素）

容器适配器实际上将要使用的实际容器类型作为其模板参数之一。因此，如果需要，可以将

堆栈

与

std:：list

一起使用。我不一定建议（取决于您的用例），但您可以

容器适配器不关心内存；是他们使用的容器分配内存

如果你在一个内存非常有限的系统中运行，你不会发现标准容器非常友好。即使使用分配器为它们提供固定大小的内存缓冲区，这些分配器也只能抛出一个异常来阻止实际容器分配更多内存

例如，如果有一个

向量

需要在2KB内存内工作，如果它的大小为1KB，并试图再分配2.5KB，则分配器不能简单地返回2KB。它可以根据请求返回2.5KB，也可以抛出

std:：bad_alloc

。这是你唯一的两个选择。分配器无法告诉

向量

它可以获得比它所拥有的更多的内存，但不是它想要的那么多

类似地，分配器需要提供新的内存，新分配的内存可以复制到内存中。它不应该只提供更多可用的相同内存点。这样做可能会在某些实现中导致问题

分配器旨在为访问提供不同的内存区域；它们没有很好地设计来限制容器本身的大小

---

我的建议是追踪。它是专门为这类事情设计的。我链接到的Github repo有一些bug修复等等，但基本上还是一样的。这是一段不错的代码。它们的类似STL的容器提供了大部分接口，因此它们大部分可以作为直接替换。但是它们提供了专门控制内存分配的特殊功能。

此外，您还可以使用boost。它与

std:：vector

共享大部分API，并且可以与容器适配器（队列、堆栈）一起使用。它可以调用

throw\u bad\u alloc（）

，而不是抛出

std:：bad\u alloc

，这样它也可以毫无例外地在嵌入式环境中使用。

我知道这是一个旧线程，但对于感兴趣的人，我为嵌入式应用程序维护了一个类似STL的模板库。根本不使用堆

嵌入式模板库（MIT许可证）

---

感谢指向EASTL源代码的指针-我不知道该源代码曾经发布过。上次我查看EASTL时（很久以前），看起来只有n2271文档可用（）。希望我有时间看看目前发布的源代码。这可能是另一个例子