c++ - 在 C++ 中使用 realloc

Question

如果 malloc 的内存包含非 pod 类型，则

std::realloc 在 c++ 中是危险的。似乎 only 的问题是 std::realloc 如果不能就地增加内存，则不会调用类型析构函数。

try_realloc 函数是一个简单的解决方法。如果它不能就地增长，它不会分配新内存，而是简单地返回 false。在这种情况下，可以分配新内存，将对象复制(或移动)到新内存，最后释放旧内存。

这似乎非常有用。 std::vector 可以很好地利用这一点，可能避免所有的复制/重新分配。
先发制人的阻燃剂:从技术上讲，这与 Big-O 性能相同，但如果 vector 增长是您应用程序中的瓶颈，那么即使 Big-O 保持不变，2 倍的加速也是不错的。

但是，我找不到任何像 try_realloc 一样工作的 c api。

我错过了什么吗？ try_realloc 没有我想象的那么有用吗？是否有一些隐藏的错误使 try_realloc 无法使用？

更好的是，是否有一些文档较少的 API 可以像 try_realloc 一样执行？

注意: 显然，我在这里使用库/平台特定代码。我并不担心，因为 try_realloc 本质上是一种优化。

---

更新:在 Steve Jessops 评论 vector 是否会更有效地使用 realloc 之后，我写了一个概念证明来测试。 realloc-vector 模拟 vector 的增长模式，但可以选择重新分配。我在 vector 中运行了多达一百万个元素的程序。

为了比较，vector 必须分配 19 次，同时增长到一百万个元素。

结果，如果 realloc-vector 是唯一使用堆的东西，结果非常棒，3-4 分配，同时增长到百万字节的大小。

如果 realloc-vector 与以 realloc-vector 速度增长 66% 的 vector 一起使用，结果会更少有希望，成长过程中分配8-10倍。

最后，如果 realloc-vector 与以相同速率增长的 vector 一起使用，则 realloc-vector 分配 17- 18 次。几乎没有比标准 vector 行为节省一个分配。

我不怀疑黑客可以通过游戏分配大小来节省成本，但我同意 Steve 的观点，即编写和维护这样一个分配器的巨大努力是徒劳的。

Answer 1

vector 通常以较大的增量增长。如果不重新定位，您不能重复执行此操作，除非您仔细安排事情，以便在 vector 的内部缓冲区上方有大量空闲地址(这实际上需要分配整个页面，因为显然您不能有其他分配稍后在同一页面上)。

所以我认为，为了在这里获得真正好的优化，您需要的不仅仅是一个“简单的解决方法”，如果可能的话，它会进行廉价的重新分配 - 您必须以某种方式为制作做一些准备有可能，而且准备工作会花费您的地址空间。如果你只为某些 vector 做这件事，那些表明它们会变大的 vector ，那么它是毫无意义的，因为它们可以用 reserve() 表明它们会变大。如果您有一个巨大的地址空间，您只能为所有 vector 自动执行此操作，这样您就可以在每个 vector 上“浪费”一大块。

据我了解，Allocator 概念没有重新分配功能的原因是为了保持简单。如果 std::allocator 有一个 try_realloc 函数，那么每个分配器都必须有一个(在大多数情况下无法实现，只需要返回false 总是)，否则每个标准容器都必须专门用于 std::allocator 才能利用它。这两个选项都不是一个很好的 Allocator 接口(interface)，尽管我认为对于几乎所有 Allocator 类的实现者来说，仅仅添加一个无操作的 try_realloc 函数并不是一项巨大的努力。

如果 vector 由于重新分配而变慢，deque 可能是一个很好的替代品。