这可能看起来很奇怪，但我会尝试将其合理化。我目前广泛使用boost.object_pool与shared_ptr一起使用，最近我遇到了一种情况，我需要拍摄当前程序状态的快照，以便进行全尺寸重放/回滚/快进等功能。
所以我不是试图克隆一个对象池在其他地方使用，这显然不会起作用，因为即使我被boost.pool的接口允许这样做（我不是这样），也没有指向块的有效指针在那个新克隆的游泳池里，它只会毫无意义。但我的用例是，如果有重放/回滚需求，我想将其“粘贴”回原始池中。
我当然可以手动复制和克隆所有状态，对象和子状态，子对象和子子...然后将它们打包成快照，并希望一切都会正确，但鉴于复杂性，这很容易出错该项目已经有了，并且它要比我直接复制内存慢得多。使用Command模式（或类似物）来实现undo-redo也是不可能的，因为undo-redo机制不是我的意图。
我只是想知道我是否使用顽固的传统C方式从头开始再做项目，而简单的memcpy（snapshot，all_states，size）调用几乎可以完成所有工作。
我还有其他选择吗？是否有任何boost.object_pool实现允许您克隆底层内存区域？在考虑到这种情况的情况下，侵入性地刺激boost.object_pool是一个合理的选择吗？
从来没听说过。
正如您所指出的，这里的主要问题是对象之间可能存在相互依赖关系，这需要在复制时更新指针。当然是非平凡的。
我可以想到两种可能的解决方案：
持久性绝不会改变现有的状态。当您更改状态时，您将创建一个新快照，该快照引用除新位之外的旧状态。例如，它通常用于数据库的MVCC实现，并且在函数式编程世界中普遍存在。如果你试图保留太多的引用，它也是一个很好的方法来获取空间泄漏。最后，它需要深入的重新设计。
序列化是关于持久状态，但是以不同的格式。您以序列化格式（无论是文本格式还是二进制格式）转储当前状态，并且可以通过读取序列化缓冲区来重新创建它。您甚至可以在序列化缓冲区上应用压缩传递以节省一些内存。
由于你已经在使用Boost，所以很高兴得知Boost.Serialization自动处理对象的图形（呃！），我认为已经正确处理了boost::shared_ptr。这可能是你最好的选择。