写时复制语义的优点

我想知道写时复制有什么优点？当然，我并不期望个人观点，而是希望在实际操作中以切实可行的方式在技术上和实践中受益。实际上，我的意思不只是节省&字符输入。

要澄清的是，此问题是在数据类型的上下文中进行的，在赋值或副本构造中创建一个隐式浅表副本，但对其进行修改会创建一个隐式深表副本，并将更改应用于它而不是原始对象。

我问的原因是，我似乎没有发现将COW作为默认隐式行为的任何优点。我使用Qt，它为许多数据类型实现了COW，实际上所有数据类型都具有一些动态分配的底层存储。但是它如何真正使用户受益呢？

一个例子：

QString s("some text");
QString s1 = s; // now both s and s1 internally use the same resource

qDebug() << s1; // const operation, nothing changes
s1[o] = z; // s1 "detaches" from s, allocates new storage and modifies first character
           // s is still "some text"

在此示例中，使用COW可以赢得什么？

如果我们打算做的只是使用const操作，那s1是多余的，不妨使用s。

如果我们打算更改该值，则COW仅将资源复制延迟到第一个非常量操作为止，其代价是（为最小）增加隐式共享的引用计数并从共享存储中分离。看起来COW涉及的所有开销都是毫无意义的。

在参数传递的上下文中没有太大区别-如果您不打算修改值，则以const引用的形式传递，如果您要修改，则可以隐式深层复制（如果您不想修改）原始对象，如果要对其进行修改，则通过引用传递。同样，COW似乎是不必要的开销，什么也做不了，仅增加了一个限制，即即使您愿意也不能修改原始值，因为任何更改都将脱离原始对象。

因此，取决于您是否了解COW或遗忘了COW，它可能导致意图含糊的代码和不必要的开销，或者导致完全混乱的行为，与预期不符，使您抓狂。

在我看来，无论您是想要避免不必要的深复制还是打算制作一个深复制，似乎都有更有效，更易读的解决方案。那么，COW的实际好处在哪里呢？我认为必须有一些好处，因为它在如此流行而强大的框架中使用。

此外，据我了解，C ++标准库中现已明确禁止使用COW。不知道我看到的缺点是否与它有关，但是无论哪种方式，都一定有原因。

写时复制用于经常创建对象副本而不修改它的情况。在这种情况下，它会收回成本。

如前所述，您可以传递const对象，并且在许多情况下就足够了。但是，const仅保证调用者无法对其进行突变（const_cast当然，除非他们）。它不处理多线程情况，也不处理存在回调（可能会使原始对象发生变化）的情况。按值传递COW对象带来了在API开发人员（而不是API用户）上管理这些详细信息的挑战。

C + 11的新规则std::string尤其禁止COW 。如果分离了后备缓冲区，则字符串上的迭代器必须无效。如果迭代器被实现为a char*（与a string*和索引相对），则该迭代器不再有效。C ++社区必须决定使迭代器失效的频率，并且决定operator[]不应该是其中一种情况。 operator[]在上std::string返回char&，可以修改。因此，operator[]将需要分离字符串，从而使迭代器无效。这被认为是一项糟糕的交易，并且与诸如end()和之类的函数不同cend()，没有办法要求operator[]缺少const转换字符串的const版本。（相关）。

COW仍然存在，并且不在STL之外。特别是，在我的API用户不合理地期望看起来很轻量的对象后面有一些重量级对象的情况下，我发现它非常有用。我不妨在后台使用COW，以确保他们永远不必担心此类实现细节。

对于字符串来说，这似乎比不使用更常见的用例更为悲观，因为字符串的常见用例通常是小字符串，因此，COW的开销往往远远超过简单复制小字符串的成本。对于我来说，小缓冲区优化对我来说更有意义，以避免在这种情况下避免堆分配而不是字符串副本。

但是，如果您有一个较重的对象（例如android），并且想要复制它并只替换其控制论臂，则COW似乎很合理，因为它可以保持可变的语法，同时又无需将整个android深度复制到给副本一个独特的手臂。在那个时候使其成为不变的数据结构可能会更好，但是在这些情况下，将“部分COW”应用于各个android部件似乎是合理的。

在这种情况下，Android的两个副本将共享/实例化相同的躯干，腿，脚，头，脖子，肩膀，骨盆等。它们之间唯一不共享的数据是手臂对于第二个覆盖其手臂的android而言是唯一的。