由于我们在C ++中具有移动语义，因此如今很常见
void set_a(A a) { _a = std::move(a); }
理由是，如果a是右值，则副本将被删除，并且只有一招。
但是，如果a是左值会怎样？似乎将有一个副本构造，然后是一个移动分配（假设A具有正确的移动分配运算符）。如果对象具有太多的成员变量，则移动分配的成本可能很高。
另一方面，如果我们这样做
void set_a(const A& a) { _a = a; }
将只有一份副本分配。如果我们要传递左值，是否可以说这种方法比按值传递惯用法更可取？
Answers:
昂贵的移动类型在现代C ++用法中很少见。如果您担心搬迁的成本，请写两个重载：
void set_a(const A& a) { _a = a; }
void set_a(A&& a) { _a = std::move(a); }
或完美转发的二传手：
template <typename T>
void set_a(T&& a) { _a = std::forward<T>(a); }
它将接受左值，右值以及任何其他可隐式转换为的值，decltype(_a)而无需额外的副本或移动。
尽管从左值开始设置时需要进行额外的移动，但这种用语也不错，因为（a）绝大多数类型提供了恒定时间的移动，并且（b）复制和交换提供了异常安全性，并且在单个操作中性能接近最佳代码行。
T可以由构造std::initializer_list，则不允许您在通话中使用列表。 set_a({1,2,3})将海成为set_a(A{1,2,3})自支撑，初始化列表的没有一个类型。
但是，如果
a是左值会怎样？似乎将有一个副本构造，然后是一个移动分配（假设A具有正确的移动分配运算符）。如果对象具有太多的成员变量，则移动分配的成本可能很高。
问题被发现。我最多不说通过值传递然后移动的构造是一个不好的习惯，但它肯定有其潜在的陷阱。
如果您的类型移动起来很昂贵和/或移动它本质上只是一个副本，那么按值传递方法就不是最佳选择。这样的类型的示例包括具有固定大小数组作为成员的类型：移动可能相对昂贵，并且移动只是副本。也可以看看
在这种情况下。
“按值传递”方法的优点是，您只需要维护一个功能，而您需要为此付出性能。此维护优势是否会超过性能损失，这取决于您的应用程序。
如果您有多个参数，则按值传递值和右值传递方法可能很快导致维护麻烦。考虑一下：
#include <vector>
using namespace std;
struct A { vector<int> v; };
struct B { vector<int> v; };
struct C {
A a;
B b;
C(const A& a, const B& b) : a(a), b(b) { }
C(const A& a, B&& b) : a(a), b(move(b)) { }
C( A&& a, const B& b) : a(move(a)), b(b) { }
C( A&& a, B&& b) : a(move(a)), b(move(b)) { }
};
如果您有多个参数，则会遇到排列问题。在这个非常简单的示例中，维护这4个构造函数可能仍然还不错。但是，在这种简单的情况下，我将认真考虑将传递值方法与单个函数一起使用
C(A a, B b) : a(move(a)), b(move(b)) { }
而不是上面的4个构造函数。
长话短说，这两种方法都没有缺点。根据实际的分析信息来做出决策，而不是过早地进行优化。
对于将要存储值的一般情况，值传递只是一个很好的折衷方案-
对于仅传递左值的情况（某些紧密耦合的代码），这是不合理，不明智的。
对于怀疑通过同时提供速度来提高速度的情况，请首先考虑两次，如果没有帮助，请进行测量。
在不存储值的位置，我更喜欢按引用传递，因为这样可以防止大量不必要的复制操作。
最后，如果可以将编程简化为没有规则的规则应用，我们可以将其留给机器人。因此，恕我直言，集中精力于规则不是一个好主意。更好地关注针对不同情况的优势和成本。成本不仅包括速度，还包括代码大小和清晰度。规则通常无法处理此类利益冲突。
当前的答案还很不完整。相反，我将尝试根据我发现的优缺点列表做出结论。
简而言之，这可能还可以，但有时也很糟糕。
与转发模板或不同的重载相比，这种习惯用法（即统一界面）具有更好的清晰度（在概念设计和实现方面）。有时与复制和交换一起使用（实际上，在这种情况下也包括移动和交换）。
优点是：
constconst，而且与兼容volatile，从而减少了更多的常规重载。
const }组合为ñ参数。constconst volatileT，则它可能仍会与参数const T&位于相同位置的重载发生冲突，因为参数可以是type的左值，T而用type实例化的模板T&（而不是const T&）则可能更多如果没有其他方法可以区分哪个是最佳的重载候选，则应由重载规则首选。这种不一致可能非常令人惊讶。
P&&在类中具有一个带有一个类型参数的转发模板构造函数C。您会忘记多少时间P&&从CSFINAE可能不具备cv资格的实例中排除实例（例如，通过添加typename = enable_if_t<!is_same<C, decay_t<P>>到template-parameter-list），以确保它不会与copy / move构造函数冲突（即使后者显式）用户提供）？constexpr在某个类中声明的静态数据成员而没有类外定义，当将其用作左值引用类型的参数的参数时，由于它是odr，因此最终可能无法链接-使用，没有定义。
constexpr数据成员的规则已更改为隐式引入定义，因此在这种情况下，差异并不明显。缺点是：
noexcept为const&和&&限定类型的参数指定不同的-specifier 。
noexcept(false)copy + noexceptmove noexcept，或者noexcept(false)在您未指定任何内容（或明确指定noexcept(false)）时始终为您提供copy + move 。（请注意，在前一种情况下，noexcept不能防止在复制期间抛出异常，因为这只会在函数参数范围内的参数求值期间发生。）没有进一步的机会分别调整它们。noexcept自C ++ 17起，的示例可能特别有问题，因为noexcept-规范现在会影响函数类型。（某些意外的兼容性问题可以通过Clang ++警告来诊断。）有时无条件复制实际上是有用的。由于具有强例外保证的操作的构成本质上不具有保证，因此，在需要强例外保证且操作不能按严格的操作顺序分解时，可以将副本用作事务状态持有者（无例外或强烈）例外保证。（这包括复制和交换的习惯用法，尽管通常不建议出于其他原因将分配统一，请参见下文。）但是，这并不意味着复制是不可接受的。如果接口的意图总是创建某种类型的对象T，并且移动的成本T是可忽略的，则可以将副本移动到目标而不会产生不必要的开销。
因此，对于某些给定的操作，以下是有关是否使用统一接口来替换它们的建议：
T，如果所有操作都需要每个参数的副本，请使用unification。T具有可忽略的成本，则使用统一。T，而移动构造的成本T是可忽略的，则使用统一。以下是一些需要避免统一的示例：
T在复制和移动构造中没有可忽略的成本的分配操作（包括分配给其子对象，通常具有复制和交换习惯）不符合统一的标准，因为分配的目的不是创建（而是替换）。对象的内容。复制的对象最终将被破坏，这将导致不必要的开销。对于自我分配的情况，这一点更加明显。std::map::insert_or_assign即使发生上述故障，仍会插入类似的容器），这会产生开销。请注意，“可忽略”成本的准确限制在一定程度上是主观的，因为它最终取决于开发人员和/或用户可以容忍多少成本，并且可能因情况而异。
实际上，我（保守地）假定其大小不超过一个机器字（如指针）的琐碎可复制且琐碎的可破坏类型通常符合可忽略成本的标准-如果在这种情况下所产生的代码实际成本过高，建议使用错误的构建工具配置，或者工具链尚未准备好进行生产。
如果对性能还有任何疑问，请进行分析。
根据约定，还有一些其他众所周知的类型优选按值传递或不按值传递：
std::bind。另请参阅LWG 817的分辨率。std::move，因为假定副本的成本是可忽略的，并且此举不一定会使它更好。
std::function（但不是赋值运算符模板）也使用传递值函子参数。std::initializer_list和的实例std::basic_string_view或多或少是两个指针或一个指针加一个大小。这个事实使它们便宜到足以直接使用而不使用引用。shared_ptr实例。（但是，并非所有智能指针都是这样；observer_ptr更像是原始指针。）按值传递，然后移动实际上是您知道可移动对象的一个好习惯。
如您所提到的，如果传递了一个右值，它将取消副本或将其移动，然后在构造函数中将其移动。
您可以重载复制构造函数并显式移动构造函数，但是如果您拥有多个参数，它将变得更加复杂。
考虑这个例子，
class Obj {
public:
Obj(std::vector<int> x, std::vector<int> y)
: X(std::move(x)), Y(std::move(y)) {}
private:
/* Our internal data. */
std::vector<int> X, Y;
}; // Obj
假设如果要提供显式版本，则最终会得到以下4个构造函数：
class Obj {
public:
Obj(std::vector<int> &&x, std::vector<int> &&y)
: X(std::move(x)), Y(std::move(y)) {}
Obj(std::vector<int> &&x, const std::vector<int> &y)
: X(std::move(x)), Y(y) {}
Obj(const std::vector<int> &x, std::vector<int> &&y)
: X(x), Y(std::move(y)) {}
Obj(const std::vector<int> &x, const std::vector<int> &y)
: X(x), Y(y) {}
private:
/* Our internal data. */
std::vector<int> X, Y;
}; // Obj
如您所见，随着参数数量的增加，排列所需的构造函数的数量也会增加。
如果您没有具体的类型，但是有一个模板化的构造函数，则可以像下面这样使用完善转发：
class Obj {
public:
template <typename T, typename U>
Obj(T &&x, U &&y)
: X(std::forward<T>(x)), Y(std::forward<U>(y)) {}
private:
std::vector<int> X, Y;
}; // Obj
参考文献：
我正在回答自己，因为我将尝试总结一些答案。在每种情况下，我们有多少个移动/副本？
（A）传递值并移动分配构造，传递X参数。如果X是...
临时：1步（删除副本）
左值：1复制1移动
std :: move（lvalue）：2次移动
（B）通过引用传递和复制赋值常规（C ++ 11之前的版本）构造。如果X是...
临时：1份
左值：1个副本
std :: move（lvalue）：1个副本
我们可以假设这三种参数具有相同的可能性。因此，每3个电话就有（A）4个动作和1个副本，或（B）3个副本。即，平均而言，（A）每个呼叫1.33次移动和0.33副本，或（B）每个呼叫1个副本。
如果我们遇到班级大部分由POD组成的情况，则移动与复制一样昂贵。因此，在情况（A）中，对设置员的每次调用将有1.66份（或移动）副本，在情况（B）中，我们有1份副本。
我们可以说，在某些情况下（基于POD的类型），“按值传递然后移动”构造是一个非常糟糕的主意。它慢了66％，并且取决于C ++ 11功能。
另一方面，如果我们的类包含容器（利用动态内存），则（A）应该快得多（除非我们大多传递左值）。
如果我错了，请纠正我。
声明中的可读性：
void foo1( A a ); // easy to read, but unless you see the implementation
// you don't know for sure if a std::move() is used.
void foo2( const A & a ); // longer declaration, but the interface shows
// that no copy is required on calling foo().
性能：
A a;
foo1( a ); // copy + move
foo2( a ); // pass by reference + copy
职责：
A a;
foo1( a ); // caller copies, foo1 moves
foo2( a ); // foo2 copies
对于典型的内联代码，优化后通常没有区别。但是foo2（）可能仅在某些条件下执行复制（例如，如果键不存在，则插入map中），而对于foo1（），复制将始终完成。
std::move，否则就是这样。
std::movea会const&传回const&&无法移走的a。