条款41：针对可复制的形参，在移动成本低并且一定会被复制的前提下，考虑将其按值传递
有些函数的形参本来就是打算拿来复制的。例如，成员函数addName可能会将其形参复制入其私有容器。为效率计，这样的函数应该针对左值实参实施复制，而针对右值实参实施移动：
class Widget
{
public:
void addName(const std::string& newName) //接受左值
{ names.push_back(newName); } //对其实施复制
void addName(std::string&& newName) //接受右值
{ names.push_back(std::move(newName)); } //对其实施移动
... //关于std::move的用法，参见条款25
private:
std::vector names;
}; 这样写也没有错，但是要求撰写本质上在做同一件事的两个函数。这么一来就有活干了：需要撰写两份函数声明、两份函数实现、两份函数文档、两份函数维护工作量。要命。
犹有进者，在目标代码中将出现两个函数，如果你确实在意程序足迹一事，这一情况就可能会让你忧心。在本例情况下，这两个函数都可能会被实施内联，而这很可能会消除与存在两个函数相关的任何膨胀问题，但是如果这些函数没有处处实施内联的话，那么你在目标代码中就真会看到有两个函数了。
另一种方法是把addName写成接受万能引用的函数模板：
class Widget
{
public:
template //接受左值
void addName(T&& newName) //也接受右值
{ //对左值实施复制
names.push_back(std::forward(newName)); //对右值实施复制
} //关于std::forward的用法
....
}; 这减少了你需要着手处理的源代码数量，但是万能引用的使用会导致其他方面的复杂性。作为模板，addName的实现通常必须置于头文件中。它还可能在对象代码中产生好几个函数，因为它不仅针对左值和右值会产生不同的实例化效果，针对std::string和可以转换为std::string的型别（参见条款25）也会产生不同的实例化结果。同时，有些型别不能按通用引用方式传递（参见条款30），如果客户传入了不正确的实参型别，编译器错误消息可能会吓人一跳（参见条款27）。
如果有一种方法来撰写像addName这样的函数，针对左值实施的是复制，针对右值实施的是移动，而且无论在源代码和目标代码中只有一个函数需要着手处理，还能避免万能引用的怪癖，那该多妙！无巧不成书，方法还真有一个，你所需要做的事情只有一件，就是要放弃你可能身为C++程序员学到的第一个条规则。该规则说，要避免按值传递用户定义型别的对象。对于像addName这样的函数中的newName这样的形参，按值传递可能是个完全合理的策略。
在我们讨论为什么对于addName中的newName按值传递非常合理之前，让我们来考虑该会怎样实现：
class Widget {
public:
void addName(std::string newName) { //接受左值或右值；移动它
names.push_back(std::move(newName));
}
…
}该代码唯一可能令人困惑的部分就是对形参newName使用std::move。std::move典型的应用场景是用在右值引用，但是在这里，我们了解到：（1）newName是，与调用者传进来的对象相完全独立的，一个对象，所以改变newName不会影响到调用者；（2）这就是newName的最后一次使用，所以移动它不会影响函数内此后的其他代码。
只有一个addName函数的事实，解释了在源代码和目标代码中，我们怎样避免了代码重复。我们没有使用通用引用，不会导致头文件膨胀、奇怪的失败情况、或者令人困惑的编译错误消息。但是这种设计的效率如何呢？我们在按值传递哎，会不会开销很大？
在C++98中，可以肯定确实开销会大。无论调用者传入什么，形参newName都是由拷贝构造出来。但是在C++11中，只有在左值实参情况下，addName被拷贝构造出来；对于右值，它会被移动构造。来看如下例子：
Widget w;
…
std::string name("Bart");
w.addName(name); //使用左值调用addName
…
w.addName(name + "Jenne"); //使用右值调用addName（见下）第一处调用addName（当name被传递时），形参newName是使用左值被初始化。newName因此是被拷贝构造，就像在C++98中一样。第二处调用，newName使用std::string对象被初始化，这个std::string对象是调用std::string的operator+（即append操作）得到的结果。这个对象是一个右值，因此newName是被移动构造的。
就像我们想要的那样，左值拷贝，右值移动，优雅吧？
优雅，但是要牢记一些警示，回顾一下我们考虑过的三个版本的addName：
class Widget { //方法1：对左值和右值重载
public:
void addName(const std::string& newName)
{ names.push_back(newName); } // rvalues
void addName(std::string&& newName)
{ names.push_back(std::move(newName)); }
…
private:
std::vector names;
};
class Widget { //方法2：使用通用引用
public:
template
void addName(T&& newName)
{ names.push_back(std::forward(newName)); }
…
};
class Widget { //方法3：传值
public:
void addName(std::string newName)
{ names.push_back(std::move(newName)); }
…
}; 我将前两个版本称为“按引用方法”，因为都是通过引用传递形参。
仍然考虑这两种调用方式：
Widget w;
…
std::string name("Bart");
w.addName(name); //传左值
…
w.addName(name + "Jenne"); //传右值现在分别考虑三种实现中，给Widget添加一个名字的两种调用方式，拷贝和移动操作的开销。会忽略编译器对于移动和拷贝操作的优化，因为这些优化是与上下文和编译器有关的，实际上不会改变我们分析的本质。
-
重载：无论传递左值还是传递右值，调用都会绑定到一个叫
newName的引用上。从拷贝和移动操作方面看，这个过程零开销。左值重载中，newName拷贝到Widget::names中，右值重载中，移动进去。开销总结：左值一次拷贝，右值一次移动。 -
使用通用引用：同重载一样，调用也绑定到
addName这个引用上，没有开销。由于使用了std::forward，左值std::string实参会拷贝到Widget::names，右值std::string实参移动进去。对std::string实参来说，开销同重载方式一样：左值一次拷贝，右值一次移动。Item25 解释了如果调用者传递的实参不是
std::string类型，将会转发到std::string的构造函数，几乎也没有std::string拷贝或者移动操作。因此通用引用的方式有同样效率，所以这不影响本次分析，简单假定调用者总是传入std::string类型实参即可。 -
按值传递：无论传递左值还是右值，都必须构造
newName形参。如果传递的是左值，需要拷贝的开销，如果传递的是右值，需要移动的开销。在函数的实现中，newName总是采用移动的方式到Widget::names。开销总结：左值实参，一次拷贝一次移动，右值实参两次移动。对比按引用传递的方法，对于左值或者右值，均多出一次移动操作。
再次回顾本Item的内容：
对于移动成本低且总是被拷贝的可拷贝形参，考虑按值传递
这样措辞是有原因的。实际上四个原因：
-
应该仅考虑使用传值方式。确实，只需要编写一个函数。确实，只会在目标代码中生成一个函数。确实，避免了通用引用的种种问题。但是毕竟开销会比那些替代方式更高（译者注：指接受引用的两种实现方式），而且下面还会讨论，还会存在一些目前我们并未讨论到的开销。
-
仅考虑对于可拷贝形参使用按值传递。不符合此条件的的形参必须有只可移动的类型（move-only types）（的数据成员），因为函数总是会做副本（译注：指的是传值时形参总是实参的一个副本），而如果它们不可拷贝，副本就必须通过移动构造函数创建。（这样的句子就说明有一个术语来区分拷贝操作制作的副本，和移动操作制作的副本，是非常好的。）回忆一下传值方案比“重载”方案的优势在于，仅有一个函数要写。但是对于只可移动类型，没必要为左值实参提供重载，因为拷贝左值需要拷贝构造函数，只可移动类型的拷贝构造函数是禁用的。那意味着只需要支持右值实参，“重载”方案只需要一个重载函数：接受右值引用的函数。
考虑一个类：有个
std::unique_ptr的数据成员，对它有个赋值器（setter）。std::unique_ptr是只可移动的类型，所以赋值器的“重载”方式只有一个函数：class Widget { public: … void setPtr(std::unique_ptr调用者可能会这样写：
Widget w; … w.setPtr(std::make_unique这样，从
std::make_unique返回的右值std::unique_ptr通过右值引用被传给setPtr，然后移动到数据成员p中。整体开销就是一次移动。如果
setPtr使用传值方式接受形参：class Widget { public: … void setPtr(std::unique_ptr同样的调用就会先移动构造
ptr形参，然后ptr再移动赋值到数据成员p，整体开销就是两次移动——是“重载”方法开销的两倍。 -
按值传递应该仅考虑那些移动开销小的形参。当移动的开销较低，额外的一次移动才能被开发者接受，但是当移动的开销很大，执行不必要的移动就类似执行一个不必要的拷贝，而避免不必要的拷贝的重要性就是最开始C++98规则中避免传值的原因！
-
你应该只对总是被拷贝的形参考虑按值传递。为了看清楚为什么这很重要，假定在拷贝形参到
names容器前，addName需要检查新的名字的长度是否过长或者过短，如果是，就忽略增加名字的操作：class Widget { public: void addName(std::string newName) { if ((newName.length() >= minLen) && (newName.length() <= maxLen)) { names.push_back(std::move(newName)); } } … private: std::vector即使这个函数没有在
names添加任何内容，也增加了构造和销毁newName的开销，而按引用传递会避免这笔开销。
即使你编写的函数对可拷贝类型执行无条件的复制，且这个类型移动开销小，有时也可能不适合按值传递。这是因为函数拷贝一个形参存在两种方式：一种是通过构造函数（拷贝构造或者移动构造），还有一种是赋值（拷贝赋值或者移动赋值）。addName使用构造函数，它的形参newName传递给vector::push_back，在这个函数内部，newName是通过拷贝构造在std::vector末尾创建一个新元素。对于使用构造函数拷贝形参的函数，之前的分析已经可以给出最终结论：按值传递对于左值和右值均增加了一次移动操作的开销。
当形参通过赋值操作进行拷贝时，分析起来更加复杂。比如，我们有一个表征密码的类，因为密码可能会被修改，我们提供了赋值器函数changeTo。用按值传递的策略，我们实现一个Password类如下：
class Password {
public:
explicit Password(std::string pwd) //传值
: text(std::move(pwd)) {} //构造text
void changeTo(std::string newPwd) //传值
{ text = std::move(newPwd); } //赋值text
…
private:
std::string text; //密码的text
};将密码存储为纯文本格式恐怕将使你的软件安全团队抓狂，但是先忽略这点考虑这段代码：
std::string initPwd("Supercalifragilisticexpialidocious");
Password p(initPwd);毫无疑问：p.text被给定的密码构造，在构造函数用按值传递的方式增加了一次移动构造的开销，如果使用重载或者通用引用就会消除这个开销。一切都还好。
但是，该程序的用户可能对这个密码不太满意，因为“Supercalifragilisticexpialidocious”可以在许多字典中找到。他或者她因此采取等价于如下代码的一些动作：
std::string newPassword = "Beware the Jabberwock";
p.changeTo(newPassword);不用关心新密码是不是比旧密码更好，那是用户关心的问题。我们关心的是changeTo使用赋值来拷贝形参newPwd，可能导致函数的按值传递实现方案的开销大大增加。
传递给changeTo的实参是一个左值（newPassword），所以newPwd形参被构造时，std::string的拷贝构造函数会被调用，这个函数会分配新的存储空间给新密码。newPwd会移动赋值到text，这会导致text本来持有的内存被释放。所以changeTo存在两次动态内存管理的操作：一次是为新密码创建内存，一次是销毁旧密码的内存。
但是在这个例子中，旧密码比新密码长度更长，所以不需要分配新内存，销毁旧内存的操作。如果使用重载的方式，有可能两次动态内存管理操作得以避免：
class Password {
public:
…
void changeTo(std::string& newPwd) //对左值的重载
{
text = newPwd; //如果text.capacity() >= newPwd.size()，
//可能重用text的内存
}
…
private:
std::string text; //同上
};这种情况下，按值传递的开销包括了内存分配和内存销毁——可能会比std::string的移动操作高出几个数量级。
有趣的是，如果旧密码短于新密码，在赋值过程中就不可避免要销毁、分配内存，这种情况，按值传递跟按引用传递的效率是一样的。因此，基于赋值的形参拷贝操作开销取决于具体的实参的值，这种分析适用于在动态分配内存中存值的形参类型。不是所有类型都满足，但是很多——包括std::string和std::vector——是这样。
这种潜在的开销增加仅在传递左值实参时才适用，因为执行内存分配和释放通常发生在真正的拷贝操作（即，不是移动）中。对右值实参，移动几乎就足够了。
结论是，使用通过赋值拷贝一个形参进行按值传递的函数的额外开销，取决于传递的类型，左值和右值的比例，这个类型是否需要动态分配内存，以及，如果需要分配内存的话，赋值操作符的具体实现，还有赋值目标占的内存至少要跟赋值源占的内存一样大。对于std::string来说，开销还取决于实现是否使用了小字符串优化（SSO——参考Item29），如果是，那么要赋值的值是否匹配SSO缓冲区。
所以，正如我所说，当形参通过赋值进行拷贝时，分析按值传递的开销是复杂的。通常，最有效的经验就是“在证明没问题之前假设有问题”，就是除非已证明按值传递会为你需要的形参类型产生可接受的执行效率，否则使用重载或者通用引用的实现方式。
到此为止，对于需要运行尽可能快的软件来说，按值传递可能不是一个好策略，因为避免即使开销很小的移动操作也非常重要。此外，有时并不能清楚知道会发生多少次移动操作。在Widget::addName例子中，按值传递仅多了一次移动操作，但是如果Widget::addName调用了Widget::validateName，这个函数也是按值传递。（假定它有理由总是拷贝它的形参，比如把验证过的所有值存在一个数据结构中。）并假设validateName调用了第三个函数，也是按值传递……
可以看到这将会通向何方。在调用链中，每个函数都使用传值，因为“只多了一次移动的开销”，但是整个调用链总体就会产生无法忍受的开销，通过引用传递，调用链不会增加这种开销。
跟性能无关，但总是需要考虑的是，不像按引用传递，按值传递会受到切片问题的影响。这是C++98的事，在此不在详述，但是如果要设计一个函数，来处理这样的形参：基类或者任何其派生类，你肯定不想声明一个那个类型的传值形参，因为你会“切掉”传入的任意派生类对象的派生类特征：
class Widget { … }; //基类
class SpecialWidget: public Widget { … }; //派生类
void processWidget(Widget w); //对任意类型的Widget的函数，包括派生类型
… //遇到对象切片问题
SpecialWidget sw;
…
processWidget(sw); //processWidget看到的是Widget，
//不是SpecialWidget！如果不熟悉对象切片问题，可以先通过搜索引擎了解一下。这样你就知道切片问题是C++98中默认按值传递名声不好的另一个原因（要在效率问题的原因之上）。有充分的理由来说明为什么你学习C++编程的第一件事就是避免用户自定义类型进行按值传递。
C++11没有从根本上改变C++98对于按值传递的智慧。通常，按值传递仍然会带来你希望避免的性能下降，而且按值传递会导致切片问题。C++11中新的功能是区分了左值和右值实参。利用对于可拷贝类型的右值的移动语义，需要重载或者通用引用，尽管两者都有其缺陷。对于特殊的场景，可拷贝且移动开销小的类型，传递给总是会拷贝他们的一个函数，并且切片也不需要考虑，这时，按值传递就提供了一种简单的实现方式，效率接近传递引用的函数，但是避免了传引用方案的缺点。
请记住：
- 对于可拷贝，移动开销低，而且无条件被拷贝的形参，按值传递效率基本与按引用传递效率一致，而且易于实现，还生成更少的目标代码。
- 通过构造拷贝形参可能比通过赋值拷贝形参开销大的多。
- 按值传递会引起切片问题，所说不适合基类形参类型。