c++中的持久化数据结构

Posted 2023-03-31

【中文标题】c++中的持久化数据结构

【英文标题】：Persistent data structures in c++

【发布时间】：2010-12-09 02:50:04

【问题描述】：

c++ 中有没有类似于 clojure 的持久化数据结构实现？

【问题讨论】：

C++ 没有垃圾收集，这使得构建这样的结构变得异常复杂。如果您不关心内存泄漏（或集成了垃圾收集器），那么这很容易。

哇，冷静点，兄弟。查找“Clojure”并不难；我通常不会吹嘘自己没有听说过一种处于函数式编程前沿的语言。我不是它的忠实粉丝，但我觉得很奇怪，一个问题应该因为提到它而被贬低。 （尽管我非常同意你重新评估需求的建议，而不是将另一种语言的风格硬塞到 C++ 中）。

相关：***.com/questions/2757278/…，***.com/questions/303426/…

持久数据结构不能创建循环。例如。如果您创建A，那么您可以创建指向A 的B，但您需要修改A 以创建循环。持久数据结构是不可变的，所以一个简单的 ref.计数应该足以在 C++ 中实现它们。

【参考方案1】：

我自己推出了 immer library 作为一个相当全面的例子，它特别受到 clojure 的启发。几年前，在听了约翰·卡马克 (John Carmack) 的演讲后，我感到非常兴奋并推出了自己的演讲，他在函数式编程的潮流中跳跃。他似乎能够想象一个围绕不可变数据结构旋转的游戏引擎。虽然他没有详细说明，虽然这在他的脑海中似乎只是一个模糊的想法，但他正在认真考虑它并且似乎并不认为开销会急剧降低帧速率这一事实足以让我兴奋关于探索这个想法。

我实际上将它用作某种优化细节，这可能看起来自相矛盾（不变性存在开销），但我的意思是在特定的上下文中。如果我绝对想这样做：

// We only need to change a small part of this huge data structure.
HugeDataStructure transform(HugeDataStructure input);

...而且我绝对不希望该函数引起副作用，以便它可以是线程安全的并且永远不会被误用，那么我别无选择，只能复制巨大的数据结构（可能跨越千兆字节）。

我发现在这种情况下拥有一个不可变数据结构的小型库非常有用，因为它通过浅拷贝和引用未更改的部分使上述场景相对便宜。也就是说，我大多只使用一个不可变的数据结构，它基本上是一个随机访问序列，如下所示：

正如其他人所提到的，它确实需要一些小心和调整以及全面的测试以及许多 VTune 会话才能使其线程安全和高效，但是在我投入了肘部油脂之后，它确实让整个事情变得更加容易.

每当我们使用这些结构来编写没有副作用的函数时，除了自动线程安全之外，您还可以获得诸如非破坏性编辑、简单的撤消系统、简单的异常安全（无需回滚副作用）之类的东西通过函数中的范围保护，导致异常路径中没有），并让用户复制和粘贴数据并实例化它而不占用太多内存，直到/除非他们修改他们粘贴的内容作为奖励。实际上，我发现这些奖金每天比线程安全更有用。

我使用“瞬态”（又名“构建器”）来表达对数据结构的更改，如下所示：

Immutable transform(Immutable input)

    Transient transient(input);

    // make changes to mutable transient.
    ...

    // Commit the changes to get a new immutable
    // (this does not touch the input).
    return transient.commit();

我什至有一个不可变的图像库，用于图像编辑以简化非破坏性编辑。它使用与上述结构类似的策略，将图像视为图块，如下所示：

当一个瞬态被修改并且我们得到一个新的不可变时，只有被改变的部分是唯一的。其余的图块是浅拷贝的（只有 32 位索引）：

我确实在网格和视频处理等性能相当关键的领域使用这些。关于每个块应该存储多少数据进行了一些微调（太多了，我们浪费了处理和内存深度复制太多数据，太少了我们浪费了处理和内存浅复制了太多指针和更频繁的线程锁)。

我不会将这些用于光线追踪，因为这是可以想象到的最极端的性能关键领域之一，并且用户可以注意到最微小的开销（他们实际上进行基准测试并注意到 2% 范围内的性能差异），但是大多数时候，它们足够高效，而且当您可以将这些巨大的数据结构作为一个整体左右复制以简化线程安全、撤消系统、非破坏性编辑等时，这是一个非常棒的好处，而无需担心爆炸性的内存使用和明显的延迟用于深度复制所有内容。

【参考方案2】：

获得持久数据结构的主要困难确实是缺乏垃圾收集。

如果您没有适当的垃圾回收方案，那么您可能会得到一个糟糕的方案（即引用计数），但这意味着您需要格外小心，不要创建循环引用。

它改变了结构的核心。例如，考虑二叉树。如果您创建节点的新版本，则需要其父节点的新版本才能访问它（等等...）。现在，如果关系是双向的（子 父），那么实际上您将复制整个结构。这意味着您将有一个父 -> 子关系，或者相反（不太常见）。

我可以考虑实现二叉树或 B-Tree。例如，我几乎看不到如何获得正确的数组。

另一方面，我同意在多线程环境中拥有高效的环境会很棒。

【讨论】：

循环引用在数据结构（在您的示例中为二叉树）中不是问题。在持久集合中，节点不能引用其父节点；如果他们这样做了，这意味着整个树在每次写入时都会失效。

@JoshuaWarner：同意，我在下一段中谈到，但没有得出明显的结论：没有循环是可能的（如果构建良好）并且没有循环 shared_ptr 方案完全足够了，不需要成熟的垃圾收集器。

【参考方案3】：

如果我正确理解了这个问题，那么您所寻求的是复制对象的能力，而无需在复制完成时实际支付复制费用，仅在需要时复制。可以在不损坏另一个对象的情况下对任一对象进行更改。 这称为“写入时复制”。

如果这是您正在寻找的，这可以很容易地在 C++ 中使用共享指针实现（参见 Boost 中的 shared_ptr，作为一种实现）。 最初，副本将与源共享所有内容，但是一旦进行更改，对象共享指针的相关部分就会被指向新创建的深度复制对象的其他共享指针替换。 （我意识到这个解释是模糊的——如果这确实是你的意思，答案可以详细说明）。

【讨论】：

Copy-on-write 在功能上是@Miguel 正在寻找的 - 但它会导致集合在重复写入时表现不佳。

写时复制中的“深拷贝”使其不适合在函数式编程中使用。函数式编程中的数据结构是持久性数据结构。由于它们是不可变的，如果你想“修改”它，就会制作一个新的“副本”（新版本），而旧版本仍然可用。当只有部分结构不同时（例如，列表的“头”），制作整个副本将浪费内存。相反，这两个版本共享相同的部分（例如列表的“尾部”）。