为什么没有 boost::copy_on_write_ptr ？

发布于 2024-08-22 20:35:06 字数 249 浏览 11 评论 0原文

我刚刚看到这个不错复制-写指针实现。它看起来非常通用且有用，所以我的问题是：这样的类是否包含在任何 C++ 工具包（boost、loki 等）中？如果没有，我真的很想知道为什么，因为这是一个非常有用的习惯用法，并且显然通用实现似乎是可行的（就像我链接到的那样）。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

空气里的味道 2024-08-29 20:35:06

关于这种可能性存在很多争论，并且最终出现的 auto_ptr 至少有一个建议版本是针对引用计数的 COW 指针。

不幸的是，COW 的时代已经过去了。使 COW 指针（或任何 COW）线程安全可能会导致严重的性能问题。

编辑：重读一遍，我觉得有必要指出，并非所有 COW 的使用都一定已经过时。有时它仍然有意义。线程安全增量的开销几乎是固定的——所以问题只是一个对象必须有多大，或者复制的成本有多大，COW 才有意义。在某些时候/地方，您拥有一个（未修改的）对象的大量副本，并且内存的节省可能是一个合理的权衡——内存的节省证明了一些额外的处理器时间是合理的。如果您可以节省在磁盘之间分页一点数据，您就可以很快取得成功。

回复收藏 0 原文

奢望 2024-08-29 20:35:06

正如 Jerry Coffin 所说，已经证明 COW 习惯引入了性能问题……但实际上还有另一个问题。

实际编写 COW 的通用实现是不可能的（正如您链接到的那篇文章所演示的那样）。在 std::string 的 COW 实现中，只要调用实际修改字符串状态的操作，就会执行复制。然而，指针应该如何知道这一点呢？它不了解它所指向的类。

例如，假设我这样做：

void method(Foo& foo, flag_t flag)
{
  if (flag == flag::Yes) foo.modify();
}

void invoke(COWPointer<Foo> ptr)
{
  method(*ptr, flag::No);
}

哎呀！我复制了 Foo 对象，即使它不会被修改！

问题是，虽然这个 COW 类有帮助，但您实际上必须包装它：

class Foo
{
public:

private:
  COWPointer<FooImpl> mImpl;
};

然后真正修改对象的 Foo 方法将负责复制 FooImpl 状态。所以课程确实有帮助，但它也不是灵丹妙药。

所有这些麻烦...由于 MT 应用程序中的同步问题而无法确定是否真正获得性能...

实际上尽可能避免复制（使用引用/指针）而不是调整类的 <在某些情况下可能会带来一些好处，但会惩罚已经解决性能问题的用户？

Like Jerry Coffin said it's been demonstrated that the COW idiom introduced performance issues... but there is actually another issue.

It is not possible (as demonstrated in the very article you link to) to actually write a generic implementation of COW. In the COW implementation of std::string the Copy is performed whenever an operation is invoked that will actually modify the state of the string. However, how is a pointer supposed to know that ? It has no knowledge over the class it points to.

For example, let's assume I do this:

void method(Foo& foo, flag_t flag)
{
  if (flag == flag::Yes) foo.modify();
}

void invoke(COWPointer<Foo> ptr)
{
  method(*ptr, flag::No);
}

Oups! I make a copy of the Foo object even though it's not going to be modified!

The problem is that while this COW class helps, you actually has to wrap it:

class Foo
{
public:

private:
  COWPointer<FooImpl> mImpl;
};

And then methods of Foo that really modifies the object will be responsible for copying the FooImpl state. So sure the class helps, but it's not silver bullet either.

And all this trouble... without being sure of actually gaining performance because of the synchronization issues in a MT application...

Is it not simpler to actually avoid copying whenever possible (using references / pointers) rather than tweaking your class for a possible gain in some situations that will penalize users that already took care of performances issues ?

回复收藏 0 原文