C++11 中 COW std::string 实现的合法性

Question

据我了解，写时复制不是在 C++11 中实现符合标准的 std::string 的可行方法，但最近在讨论时发现自己无法直接支持该声明。

C++11 不承认基于 COW 的 std::string 实现我是否正确？

如果是这样，这个限制是否在新标准的某处明确说明（在哪里）？

或者说这个限制是隐含的，因为新要求对std::string 的综合影响排除了std::string 的基于COW 的实现。在这种情况下，我会对“C++11 有效禁止基于 COW 的 std::string 实现”的章节风格派生感兴趣。

Answer 1

这是不允许的，因为根据标准 21.4.1 p6，迭代器/引用的失效只允许用于

——作为任何标准库函数的参数，引用 以非常量 basic_string 作为参数。

——调用非常量 成员函数，除了 operator[]、at、front、back、begin、rbegin、 结束，然后撕裂。

对于 COW 字符串，调用非 const operator[] 将需要制作副本（并使引用无效），这在上面的段落中是不允许的。因此，在 C++11 中使用 COW 字符串不再合法。

Answer 2

Dave S 和gbjbaanb 的答案正确。 （而 Luc Danton 的说法也是正确的，尽管它更多的是禁止 COW 字符串的副作用，而不是禁止它的原始规则。）

但为了消除一些混乱，我将添加一些进一步的说明。各种 cmets 链接到 a comment of mine on the GCC bugzilla，它给出了以下示例：

std::string s("str");
const char* p = s.data();
{
    std::string s2(s);
    (void) s[0];
}
std::cout << *p << '\n';  // p is dangling

该示例的重点是说明为什么 GCC 的引用计数 (COW) 字符串在 C++11 中无效。 C++11 标准要求此代码正常工作。代码中的任何内容都不允许 p 在 C++11 中失效。

使用 GCC 的旧引用计数 std::string 实现，该代码具有未定义的行为，因为 p 无效，成为一个悬空指针。 （发生的情况是，当s2 被构造时，它与s 共享数据，但通过s[0] 获得非常量引用需要取消共享数据，因此s 执行“写入时复制”，因为引用s[0] 可能被用于写入s，然后s2 超出范围，破坏p 指向的数组。

C++03 标准在 21.3 [lib.basic.string] p5 中明确允许这种行为，它说在调用 data() 之后，第一次调用 operator[]() 可能使指针、引用和迭代器无效。所以 GCC 的 COW 字符串是一个有效的 C++03 实现。

C++11 标准不再允许这种行为，因为对 operator[]() 的调用可能会使指针、引用或迭代器无效，无论它们是否遵循对 data() 的调用。

所以上面的例子必须在 C++11 中工作，但 不能在 libstdc++ 的那种 COW 字符串中工作，因此这种 COW 字符串在 C++11 中是不允许的C++11。

Answer 3

确实，CoW 是一种可接受的制作更快字符串的机制...但是...

它使多线程代码变慢（所有锁定以检查您是否是唯一一个编写代码的人在使用大量字符串时会降低性能）。这是几年前 CoW 被杀的主要原因。

其他原因是[] 运算符将返回字符串数据，而不会保护您覆盖其他人期望不变的字符串。这同样适用于c_str() 和data()。

快速谷歌说，多线程基本上是reason it was effectively disallowed（未明确）。

提案说：

建议

我们建议安全地进行所有迭代器和元素访问操作 并发执行。

我们正在提高操作的稳定性，即使在顺序代码中也是如此。

此更改实际上禁止了写时复制实现。

紧随其后

由于切换而导致的最大潜在性能损失 写时复制实现是增加内存消耗 适用于具有非常大的以读取为主的字符串的应用程序。然而，我们 相信对于这些应用，绳索是一种更好的技术 解决方案，并建议考虑将绳索提案纳入 图书馆 TR2。

Ropes 是 STLPort 和 SGIs STL 的一部分。

Answer 4

从 21.4.2 basic_string 构造函数和赋值运算符 [string.cons]

basic_string(const basic_string<charT,traits,Allocator>& str);

[...]

2 效果：构造一个 basic_string 类的对象，如表 64 所示。[...]

表 64 有用地记录了通过此（复制）构造函数构造对象后，this->data() 具有值：

指向数组的已分配副本的第一个元素，其第一个元素由 str.data() 指向

其他类似的构造函数也有类似的要求。

Answer 5

C++11 及更高版本中是否禁止使用 COW basic_string？

关于

”我是否正确 C++11 不承认基于 COW 的 std::string 实现？

是的。

关于

”如果有，这个限制是否在新标准的某处明确说明（在哪里）？

几乎直接，通过需要对字符串数据进行 O(n) 次物理复制的许多操作的恒定复杂性要求在 COW 实现中。

例如，对于成员函数

auto operator[](size_type pos) const -> const_reference;
auto operator[](size_type pos) -> reference;

...在 COW 实现中会 ¹触发字符串数据复制以取消共享字符串值，C++11 标准要求

C++11 §21.4.5/4：

” 复杂性：恒定时间。

...排除了这种数据复制，因此，COW。

C++03 支持 COW 实现，不具有这些恒定的复杂性要求，并且在某些限制条件下，允许调用 operator[]()、at()、begin()、@987654327 @、end() 或 rend() 使引用字符串项的引用、指针和迭代器无效，即可能导致 COW 数据复制。在 C++11 中删除了此支持。

---

C++11 失效规则也禁止 COW 吗？

在撰写本文时被选为解决方案的另一个答案中，该答案被大力支持，因此显然相信，它断言

” 对于 COW 字符串，调用非const operator[] 将需要制作副本（并使引用无效），这是 [C++ 上面的 [quoted] 段落所不允许的11 §21.4.1/6]。因此，在 C++11 中使用 COW 字符串不再合法。

该断言在两个主要方面是不正确和误导的：

• 它错误地表示只有非const 项目访问者需要触发 COW 数据复制。
  但const 项目访问器也需要触发数据复制，因为它们允许客户端代码形成引用或指针，（在 C++11 中）不允许以后通过可触发 COW 数据复制的操作使其无效。李>
• 它错误地认为复制 COW 数据会导致引用失效。
  但在正确的实现中，COW 数据复制、取消共享字符串值是在任何引用无效之前完成的。

要了解basic_string 的正确 C++11 COW 实现如何工作，当忽略使此无效的 O(1) 要求时，请考虑一个字符串可以在所有权策略之间切换的实现。字符串实例以策略共享开始。启用此策略后，将没有外部项目引用。该实例可以转换为唯一策略，并且它必须在可能创建项目引用时这样做，例如调用.c_str()（至少如果这会产生指向内部缓冲区的指针）。在多个实例共享值所有权的一般情况下，这需要复制字符串数据。在转换为 Unique 策略之后，实例只能通过使所有引用无效的操作（例如分配）转换回 Sharable。

因此，虽然该答案的结论（即排除了 COW 字符串）是正确的，但所提供的推理是不正确的并且具有很强的误导性。

我怀疑造成这种误解的原因是 C++11 的附件 C 中的非规范注释：

C++11 §C.2.11 [diff.cpp03.strings]，关于 §21.3：

更改：basic_string 要求不再允许引用计数字符串
理由：无效与引用计数字符串略有不同。此更改规范了本国际标准的行为（原文如此）。
对原始功能的影响：有效的 C ++ 2003 代码在本国际标准中的执行方式可能不同

这里的基本原理解释了决定删除 C++03 特殊 COW 支持的主要原因。这个理由，为什么，不是如何标准有效地禁止COW实施。该标准通过 O(1) 要求禁止 COW。

简而言之，C++11 失效规则不排除 std::basic_string 的 COW 实现。但他们确实排除了一种相当有效的不受限制的 C++03 风格的 COW 实现，例如至少一个 g++ 的标准库实现中的一种。特殊的 C++03 COW 支持实现了实际效率，特别是使用 const 项目访问器，但代价是微妙、复杂的无效规则：

C++03 §21.3/5，其中包括“首次调用”COW 支持：

” 引用basic_string 序列的元素的引用、指针和迭代器可能会因该basic_string 对象的以下用途而失效：
— 作为非成员函数 swap() (21.3.7.8)、operator>>() (21.3.7.9) 和 getline() (21.3.7.9) 的参数。
— 作为basic_string::swap() 的参数。
— 调用 data() 和 c_str() 成员函数。
— 调用非const 成员函数，operator[]()、at()、begin()、rbegin()、end() 和 rend() 除外。
— 除了返回迭代器的insert() 和erase() 的形式之外，在上述任何用途之后，第一次调用非const 成员函数operator[]()，at()，begin()，rbegin()， end()，或rend()。

这些规则是如此复杂和微妙，以至于我怀疑许多程序员（如果有的话）能否给出准确的总结。我做不到。

---

如果 O(1) 要求被忽略怎么办？

如果 C++11 的常量时间要求在例如operator[] 被忽略，那么 basic_string 的 COW 在技术上是可行的，但很难实现。

可以访问字符串内容而不引起 COW 数据复制的操作包括：

• 通过+连接。
• 通过<<输出。
• 使用basic_string 作为标准库函数的参数。

后者是因为允许标准库依赖于特定于实现的知识和构造。

另外，一个实现可以提供各种非标准函数来访问字符串内容，而不会触发 COW 数据复制。

一个主要的复杂因素是，在 C++11 中，basic_string 项目访问必须触发数据复制（取消共享字符串数据），但要求不抛出，例如C++11 §21.4.5/3 “抛出： 什么都没有。”。所以它不能使用普通的动态分配来创建一个新的缓冲区来复制COW数据。解决这个问题的一种方法是使用一个特殊的堆，其中可以保留内存而不实际分配，然后为每个对字符串值的逻辑引用保留必要的数量。在这样的堆中保留和取消保留可以是常数时间，O(1)，分配一个已经保留的数量可以是noexcept。为了符合标准的要求，对于这种方法，似乎每个不同的分配器都需要一个这样的特殊的基于预留的堆。

---

^{注意事项：
¹ const 项目访问器触发 COW 数据复制，因为它允许客户端代码获取指向数据的引用或指针，不允许由例如触发的后续数据复制使其无效。非const 项目访问者。}

Answer 6

由于现在可以保证字符串是连续存储的，并且您现在可以获取指向字符串内部存储的指针（即 &str[0] 的工作方式与数组一样），因此不可能一个有用的 COW 实现。您将不得不为太多事情制作副本。即使只是在非常量字符串上使用operator[] 或begin() 也需要一个副本。

Answer 7

我一直在想不可变的奶牛：一旦奶牛被创建，我只能通过另一头奶牛的赋值来改变，因此它符合标准。

我今天有时间尝试了一个简单的比较测试：一个大小为 N 的映射，由字符串/牛键入，每个节点都保存映射中的一组所有字符串（我们有 NxN 个对象）。

字符串大小约为 300 字节且 N=2000 头牛稍快一些，并且使用的内存几乎减少了一个数量级。见下文，size 以 kbs 为单位，run b 以奶牛为单位。

~/icow$ ./tst 2000
preparation a
run
done a: time-delta=6 mem-delta=1563276
preparation b
run
done a: time-delta=3 mem-delta=186384