我看到许多代码在复制和交换方面实现了五条规则,但我认为我们可以使用移动函数来替换交换函数,如下面的代码所示:
#include <algorithm>
#include <cstddef>
class DumbArray {
public:
DumbArray(std::size_t size = 0)
: size_(size), array_(size_ ? new int[size_]() : nullptr) {
}
DumbArray(const DumbArray& that)
: size_(that.size_), array_(size_ ? new int[size_] : nullptr) {
std::copy(that.array_, that.array_ + size_, array_);
}
DumbArray(DumbArray&& that) : DumbArray() {
move_to_this(that);
}
~DumbArray() {
delete [] array_;
}
DumbArray& operator=(DumbArray that) {
move_to_this(that);
return *this;
}
private:
void move_to_this(DumbArray &that) {
delete [] array_;
array_ = that.array_;
size_ = that.size_;
that.array_ = nullptr;
that.size_ = 0;
}
private:
std::size_t size_;
int* array_;
};
这段代码,我想
我是对的吗?
由于
编辑:
move_to_this()
和析构函数 正如@thorsan指出的那样,出于极端的性能问题,最好将 DumbArray& operator=(DumbArray that) { move_to_this(that); return *this; }
分成DumbArray& operator=(const DumbArray &that) { DumbArray temp(that); move_to_this(temp); return *this; }
(感谢@MikeMB)和DumbArray& operator=(DumbArray &&that) { move_to_this(that); return *this; }
以避免额外的移动操作
添加一些调试打印后,我发现当您将其称为移动作业时,DumbArray& operator=(DumbArray that) {}
不会涉及额外移动
正如@ErikAlapää所指出的那样,在delete
move_to_this()
之前需要进行自我分配检查
醇>
答案 0 :(得分:8)
评论内联,但简要说明:
如果可能的话,您希望所有移动分配和移动构造函数为noexcept
。如果启用此标准库,多会更快,因为它可以忽略对重新排序对象序列的算法进行的任何异常处理。
如果您要定义自定义析构函数,请将其设为noexcept。为什么打开潘多拉的盒子?我错了。默认情况下它是noexcept。
在这种情况下,提供强有力的例外保证是无痛的,几乎不需要任何费用,所以让我们这样做。
代码:
#include <algorithm>
#include <cstddef>
class DumbArray {
public:
DumbArray(std::size_t size = 0)
: size_(size), array_(size_ ? new int[size_]() : nullptr) {
}
DumbArray(const DumbArray& that)
: size_(that.size_), array_(size_ ? new int[size_] : nullptr) {
std::copy(that.array_, that.array_ + size_, array_);
}
// the move constructor becomes the heart of all move operations.
// note that it is noexcept - this means our object will behave well
// when contained by a std:: container
DumbArray(DumbArray&& that) noexcept
: size_(that.size_)
, array_(that.array_)
{
that.size_ = 0;
that.array_ = nullptr;
}
// noexcept, otherwise all kinds of nasty things can happen
~DumbArray() // noexcept - this is implied.
{
delete [] array_;
}
// I see that you were doing by re-using the assignment operator
// for copy-assignment and move-assignment but unfortunately
// that was preventing us from making the move-assignment operator
// noexcept (see later)
DumbArray& operator=(const DumbArray& that)
{
// copy-swap idiom provides strong exception guarantee for no cost
DumbArray(that).swap(*this);
return *this;
}
// move-assignment is now noexcept (because move-constructor is noexcept
// and swap is noexcept) This makes vector manipulations of DumbArray
// many orders of magnitude faster than they would otherwise be
// (e.g. insert, partition, sort, etc)
DumbArray& operator=(DumbArray&& that) noexcept {
DumbArray(std::move(that)).swap(*this);
return *this;
}
// provide a noexcept swap. It's the heart of all move and copy ops
// and again, providing it helps std containers and algorithms
// to be efficient. Standard idioms exist because they work.
void swap(DumbArray& that) noexcept {
std::swap(size_, that.size_);
std::swap(array_, that.array_);
}
private:
std::size_t size_;
int* array_;
};
可以在移动赋值运算符中进一步提高性能。
我提供的解决方案保证了移动的数组将为空(资源被释放)。这可能不是你想要的。例如,如果您单独跟踪DumbArray的容量和大小(例如,像std :: vector),那么您可能希望this
中的任何已分配内存保留在that
之后移动。这样就可以分配that
,同时可以在没有其他内存分配的情况下离开。
要启用此优化,我们只需根据(noexcept)swap实现move-assign运算符:
因此:
/// @pre that must be in a valid state
/// @post that is guaranteed to be empty() and not allocated()
///
DumbArray& operator=(DumbArray&& that) noexcept {
DumbArray(std::move(that)).swap(*this);
return *this;
}
到此:
/// @pre that must be in a valid state
/// @post that will be in an undefined but valid state
DumbArray& operator=(DumbArray&& that) noexcept {
swap(that);
return *this;
}
在DumbArray的情况下,它可能值得在实践中使用更放松的形式,但要注意细微的错误。
e.g。
DumbArray x = { .... };
do_something(std::move(x));
// here: we will get a segfault if we implement the fully destructive
// variant. The optimised variant *may* not crash, it may just do
// something_else with some previously-used data.
// depending on your application, this may be a security risk
something_else(x);
答案 1 :(得分:1)
您的代码唯一(小)问题是move_to_this()
和析构函数之间的功能重复,如果您的类需要更改,这是一个维护问题。当然,可以通过将该部分提取到公共函数destroy()
中来解决。
我对&#34;问题的批评&#34; Scott Meyers在他的博客文章中讨论过:
如果足够智能,他会尝试手动优化编译器可以在哪里做同样出色的工作。
可以将五法则简化为四法则这会自动解决左侧对象的资源交换到右侧对象的问题,如果右侧对象不是临时对象,则不会立即释放。
然后,在根据复制和交换习惯用法的复制赋值运算符的实现中,swap()
将其作为其参数之一作为到期对象。如果编译器可以内联后者的析构函数,那么它肯定会消除额外的指针赋值 - 实际上,为什么要在下一步保存指针delete
?
我的结论是,遵循成熟的惯用法更简单,而不是为了微观优化而使实现略微复杂化,这些微优化在成熟编译器的范围内。