为什么 C++11 标准的早期草案中没有默认的移动赋值/移动构造函数?
我是一个简单的程序员。我的类成员变量通常由 POD 类型和 STL 容器组成。因此,我很少需要编写赋值运算符或复制构造函数,因为它们是默认实现的。
除此之外,如果我在不可移动的对象上使用 std::move ,它会使用赋值运算符,这意味着 std::move 是完全安全的。
由于我是一个简单的程序员,我想利用移动功能,而不向我编写的每个类添加移动构造函数/赋值运算符,因为编译器可以简单地将它们实现为“this->; member1_ = std::move(other.member1_);...
"
但它没有(至少在 Visual 2010 中没有),这有什么特殊原因吗?
更重要的是; 有什么办法可以解决这个问题吗?
更新: 如果你看一下 GManNickG 的答案,他为此提供了一个很棒的宏。如果您不知道,如果您实现 move-semantics,则可以删除交换成员函数。
I'm a simple programmer. My class members variables most often consists of POD-types and STL-containers. Because of this I seldom have to write assignment operators or copy constructors, as these are implemented by default.
Add to this, if I use std::move
on objects not movable, it utilizes the assignment-operator, meaning std::move
is perfectly safe.
As I'm a simple programmer, I'd like to take advantage of the move-capabilities without adding a move constructor/assignment operator to every class I write, as the compiler could simply implemented them as "this->member1_ = std::move(other.member1_);...
"
But it doesn't (at least not in Visual 2010), is there any particular reason for this?
More importantly; is there any way to get around this?
Update:
If you look down at GManNickG's answer he provides a great macro for this. And if you didn't know, if you implement move-semantics you can remove the swap member function.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
移动构造函数和赋值运算符的隐式生成一直存在争议,并且 C++ 标准的最新草案进行了重大修订,因此当前可用的编译器在隐式生成方面的行为可能会有所不同。
有关该问题历史记录的更多信息,请参阅2010 年 WG21 论文列出 并搜索“mov”
当前规范(N3225,从 11 月开始)规定 (N3225 12.8/8):
12.8/22 中有类似的语言,指定何时将移动赋值运算符隐式声明为默认值。您可以在 N3203:收紧生成隐式移动的条件
,该决议主要基于 Bjarne Stroustrup 的论文 N3201:向右移动。
The implicit generation of move constructors and assignment operators has been contentious and there have been major revisions in recent drafts of the C++ Standard, so currently available compilers will likely behave differently with respect to implicit generation.
For more about the history of the issue, see the 2010 WG21 papers list and search for "mov"
The current specification (N3225, from November) states (N3225 12.8/8):
There is similar language in 12.8/22 specifying when the move assignment operator is implicitly declared as defaulted. You can find the complete list of changes made to support the current specification of implicit move generation in N3203: Tightening the conditions for generating implicit moves
, which was based largely on one of the resolutions proposed by Bjarne Stroustrup's paper N3201: Moving right along.
标准已考虑隐式生成的移动构造函数,但可能很危险。请参阅 Dave Abrahams 的分析。
然而,最终,该标准确实包括了移动构造函数和移动赋值运算符的隐式生成,尽管有相当多的限制:
但这还不是故事的全部。可以声明一个ctor,但仍然定义为已删除:
Implicitly generated move constructors have been considered for the standard, but can be dangerous. See Dave Abrahams's analysis.
In the end, however, the standard did include implicit generation of move constructors and move assignment operators, though with a fairly substantial list of limitations:
That's not quite all there is to the story though. A ctor can be declared, but still defined as deleted:
是的,我也走了那条路。这是你的宏:
(我已经删除了真实的注释,这些注释是长度和记录的。)
您将类中的基类和/或成员指定为预处理器列表,例如:
然后出现一个移动构造函数和移动赋值运算符。
(顺便说一句,如果有人知道我如何将细节组合到一个宏中,那就太好了。)
Yeah, I went that route too. Here's your macro:
(I've removed the real comments, which are length and documentary.)
You specify the bases and/or members in your class as a preprocessor list, for example:
And out comes a move-constructor and move-assignment operator.
(As an aside, if anyone knows how I could combine the details into one macro, that would be swell.)
VS2010 没有这样做,因为它们在实现时不是标准的。
VS2010 doesn't do it because they weren't Standard at the time of implementation.