副标题#e#
大大都措施员认为假如他们能这样写代码：
x = x + y; x = x – y;
那他们也能这样写：
x += y; x -= y;
假如x和y是用户界说的范例（user-defined type），就不能确保这样。就C++来说，operator+、operator=和operator+=之间没有任何关系，因此假如你想让这三个operator同时存在并具有你所期望的干系，就必需本身实现它们。同理，operator -, *, /, 等等也一样。
确保operator的赋值形式（assignment version）（譬喻operator+=）与一个operator的单独形式（stand-alone）(譬喻 operator+ )之间存在正常的干系，一种好要领是后者（指operator+ 译者注）按照前者（指operator+= 译者注）来实现（拜见条款6）。这很容易：
class Rational {
public:
...
Rational& operator+=(const Rational& rhs);
Rational& operator-=(const Rational& rhs);
};
// operator+ 按照operator+=实现;
//有关为什么返回值是const的表明，
//拜见Effective C++条款21 和 109页 的有关实现的告诫
const Rational operator+(const Rational& lhs,const Rational& rhs)
{
return Rational(lhs) += rhs;
}
// operator- 按照 operator -= 来实现
const Rational operator-(const Rational& lhs,const Rational& rhs)
{
return Rational(lhs) -= rhs;
}
在这个例子里，从零开始实现operator+=和-=，而operator+ 和operator- 则是通过挪用前述的函数来提供本身的成果。利用这种设计要领，只用维护operator的赋值形式就行了。并且假如假设operator赋值形式在类的public接口里，这就不消让operator的单独形式成为类的友元（拜见Effective C++ 条款19）。
#p#副标题#e#
假如你不介怀把所有的operator的单独形式放在全局域里，那就可以利用模板来替代单独形式的函数的编写：
template<class T>
const T operator+(const T& lhs, const T& rhs)
{
return T(lhs) += rhs; // 拜见下面的接头
}
template<class T>
const T operator-(const T& lhs, const T& rhs)
{
return T(lhs) -= rhs; // 拜见下面的接头
}
...
利用这些模板，只要为operator赋值形式界说某种范例，一旦需要，其对应的operator单独形式就会被自动生成。
这样编写确实不错，可是到今朝为止，我们还没有思量效率问题，效率究竟是本章的主题。在这里值得指出的是三个效率方面的问题。第一、总的来说operator的赋值形式比其单独形式效率更高，因为单独形式要返回一个新工具，从而在姑且工具的结构和释放上有一些开销。operator的赋值形式把功效写到左边的参数里，因此不需要生成姑且工具来容纳operator的返回值。
第二、提供operator的赋值形式的同时也要提供其尺度形式，答允类的客户端在便利与效率上做出折衷选择。也就是说，客户端可以抉择是这样编写：
Rational a, b, c, d, result;
...
result = a + b + c + d; // 大概用了3个姑且工具
// 每个operator+ 挪用利用1个
照旧这样编写：
result = a; //不消姑且工具
result += b; // 不消姑且工具
result += c; //不消姑且工具
result += d; //不消姑且工具
前者较量容易编写、debug和维护，而且在80％的时间里它的机能是可以被接管的（拜见条款16）。后者具有更高的效率，预计这对付汇编语言措施员来说会更直观一些。通过提供两种方案，你可以让客户端开拓人员用更容易阅读的单独形式的operator来开拓和debug代码，同时保存用效率更高的operator赋值形式替代单独形式的权力。并且按照operator的赋值形式实现其单独形式，这样你能确保当客户端从一种形式切换到另一种形式时，操纵的语义可以保持稳定。
最后一点，涉及到operator单独形式的实现。再看看operator+ 的实现：
template<class T>
const T operator+(const T& lhs, const T& rhs)
{ return T(lhs) += rhs; }
表达式T(lhs)挪用了T的拷贝结构函数。它成立一个姑且工具，其值与lhs一样。这个姑且工具用来与rhs一起挪用operator+= ，操纵的功效被从operator+.返回。这个代码仿佛不消写得这么隐密。这样写不是更好么？
template<class T>
const T operator+(const T& lhs, const T& rhs)
{
T result(lhs); // 拷贝lhs 到 result中
return result += rhs; // rhs与它相加并返回功效
}
这个模板险些与前面的措施沟通，可是它们之间照旧存在重要的不同。第二个模板包括一个定名工具，result。这个定名工具意味着不能在operator+ 里利用返回值优化（拜见条款20）。第一种实现要领总可以利用返回值优化，所以编译器为其生成优化代码的大概就会更大。
告白中的事实迫使我指出表达式：
return T(lhs) += rhs;
#p#分页标题#e#
比大大都编译器但愿举办的返回值优化更巨大。上面第一个函数实现也有这样的姑且工具开销，就象你为利用定名工具result而淹灭的开销一样。然而未定名的工具在汗青上比定名工具更容易排除，因此当我们面临在定名工具和姑且工具间举办选择时，用姑且工具更好一些。它使你淹灭的开销不会比定名的工具还多，出格是利用老编译器时，它的淹灭会更少。
这里谈论的定名工具、未定名工具和编译优化是很有趣的，可是主要的一点是operator的赋值形式（operator+=）比单独形式(operator+)效率更高。做为一个库措施设计者，应该两者都提供，做为一个应用措施的开拓者，在优先思量机能时你应该思量思量用operator赋值形式取代单独形式。
