为什么 `basic_ios::swap` 只进行部分交换?

发布于 2024-12-16 18:54:39 字数 323 浏览 2 评论 0原文

C++11 §27.5.4.2/21:

void swap(basic_ios& rhs);

效果:*thisrhs 的状态应交换,但rdbuf() 除外返回与函数调用之前返回的值相同的值,并且 rhs.rdbuf() 将返回与函数调用之前返回的值相同的值。

这种部分交换有什么用?

会引起麻烦吗?

C++11 §27.5.4.2/21:

void swap(basic_ios& rhs);

Effects: The states of *this and rhs shall be exchanged, except that rdbuf() shall return the same value as it returned before the function call, and rhs.rdbuf() shall return the same value as it returned before the function call.

What is this partial swapping useful for?

Can it cause trouble?

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

扫码二维码加入Web技术交流群

发布评论

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

评论(2

萌辣 2024-12-23 18:54:39

你可以为这件事责怪我。委员会曾尝试改变(我认为是两次),但每次解决方案都以破坏事情告终。

交换和移动语义在我们的 I/O 系统设计十年后进行了改造。而且这并不是一个完美的契合。

请注意,basic_ios::swap 是一个受保护的成员函数,并且没有命名空间范围的变体。因此,这只能从派生类(通常是 istream/ostream)调用。请注意,i/o_stream::swap 也受到保护,并且没有名称空间范围的变体。他们的规范是调用基类 swap,然后交换任何本地数据(例如 istream 中的 gcount)。

最后,在字符串/文件流级别,您将获得您所认为的“正常”交换:公共成员和名称空间范围变体。在此级别,您有一个数据成员字符串/文件缓冲区rdbuf)和基类。此级别的交换仅交换基本成员和数据成员。

所有这一切的复杂特征是,基类中的 rdbuf() 实际上是一个指向派生类的 streambuf (basic_filebuf) 的自引用指针。 code> 或 basic_stringbuf) 和 that 这就是为什么您不希望基类交换这些自引用指针。

这使得基础交换变得奇怪,但除了派生客户端之外,每个人都受到保护。派生客户端的 swap 代码看起来非常简单。在派生级别,swap 是公开的,并且按照公共客户期望的方式运行。

类似的舞蹈是为动作构建和动作分配而制作的。移动构造由于基类是虚拟基这一事实而变得更加复杂,因此它的构造函数不会被最直接的派生类调用。

很有趣。看起来很奇怪。但它最终有效。 ;-)

轻微更正:

Alberto Ganesh Barbati 负责i/ostream级别保护swap。对他来说这是一个非常好的决定,而我在我的第一个设计中完全错过了这一点。

You can blame me for this one. The committee has tried to change (twice I think), but each time the solution ended up breaking things.

Swap and move semantics was retrofitted onto our I/O system a decade after it was designed. And it wasn't a perfectly clean fit.

Note that basic_ios::swap is a protected member function and there is no namespace-scope variant. Thus this can only be called from a derived class (typically istream/ostream). Note that i/o_stream::swap is also protected and with no namespace-scope variant. And their spec is to call the base class swap and then swap any local data (such as the gcount in istream).

Finally up at the string/filestream level you get what you would consider a "normal" swap: public member and namespace-scope variants. At this level you've got a data member string/file buffer (the rdbuf) and the base class. The swap at this level simply swaps the base and data members.

The complicating characteristic of all this is that the rdbuf() down in the base class is actually a self-referencing pointer to the derived class's streambuf (basic_filebuf or basic_stringbuf) and that is why you don't want the base class to swap these self-referencing pointers.

This makes the base swap weird, but everyone is protected from it except the derived clients. And the code for the derived client's swap is subsequently deceptively simple looking. And at the derived level, swap is made public and behaves in the manner that public clients expect it to.

A similar dance is made for move construction and move assignment. Move construction is further complicated by the fact that the base class is a virtual base, and thus its constructor is not called by the most directly derived class.

It was fun. It looks weird. But it ultimately works. ;-)

Slight Correction:

Alberto Ganesh Barbati is responsible for protecting swap at the i/ostream level. It was a very good call on his part that I had completely missed with my first design.

巷子口的你 2024-12-23 18:54:39

我只有一个推测性的答案......

如果作者假设流可以使用内部缓冲区(例如 char buffer[50] 数据成员),那么这一规定是必要的,因为显然内容缓冲区的数量可能会被交换,但它们的地址将保持不变。

我不知道实际上是否允许。

I only have one speculative answer...

If the author assumed that a stream may use an internal buffer (for example a char buffer[50] data member), then this provision is necessary as obviously the content of the buffers may be swapped, but their address will remain unchanged.

I do not know whether it is actually allowed or not.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文