在 C++ 中使用 realloc

std::realloc如果 malloc 的内存包含非 Pod 类型，则在 C++ 中是危险的。看来only问题是std::realloc如果无法在原位增加内存，则不会调用类型析构函数。

一个简单的解决方法是try_realloc功能。如果新内存无法在原位生长，则不会对其进行 malloc，而是简单地返回 false。在这种情况下，可以分配新内存，将对象复制（或移动）到新内存，最后释放旧内存。

这看起来非常有用。std::vector可以充分利用这一点，可能避免所有复制/重新分配。
抢先阻燃：从技术上讲，这与 Big-O 性能相同，但如果矢量增长是应用程序中的瓶颈，即使 Big-O 保持不变，x2 速度也很好。

但是，我找不到任何像 a 那样工作的 c apitry_realloc.

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

更好的是，是否有一些记录较少的 API 的性能类似于try_realloc?

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

Update:继史蒂夫·杰索普 (Steve Jessops) 评论是否vector使用 realloc 会更有效我写了一个概念证明来测试。这realloc-vector模拟向量的增长模式，但可以选择重新分配。我运行该程序，向量中的元素达到一百万个。

为了比较vector在增长到 100 万个元素时必须分配 19 次。

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

If the realloc-vector与一个一起使用vector以 66% 的速度增长realloc-vector结果不太乐观，在生长期间分配8-10倍。

最后，如果realloc-vector与一个一起使用vector以同样的速度增长，realloc-vector分配17-18次。与标准向量行为相比，仅节省一次分配。

我毫不怀疑黑客可以玩弄分配大小来提高节省，但我同意史蒂夫的观点，即编写和维护这样一个分配器的巨大努力并没有带来好处。

vector一般都会大幅增长。你不能在不重新定位的情况下重复执行此操作，除非你仔细安排事情，以便在向量的内部缓冲区上方有大量的空闲地址（这实际上需要分配整个页面，因为显然你不能有其他分配稍后在同一页上）。

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

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

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