让operator=返回*this的引用

c++的设计者bjarne stroustrup下了很大的功夫想使用户自定义类型尽可能地和固定类型的工作方式相似。这就是为什么你可以重载运算符，写类型转换函数，控制赋值和拷贝构造函数，等等。他做了这么多努力，那你最少也该继续做下去。

让我们看看赋值。用固定类型的情况下，赋值操作可以象下面这样链起来：

所以，你也应该可以将用户自定义类型的赋值操作链起来：

因为赋值运算符的结合性天生就是由右向左，所以上面的赋值可以解析为：

很值得把它写成一个完全等价的函数形式。除非是个lisp程序员，否则下面的例子会很令人感到高兴，因为它定义了一个中缀运算符：

这个格式在此很具有说明性，因为它强调了w.operator=, x.operator=和y.operator=的参数是前一个operator=调用的返回值。所以operator=的返回值必须可以作为一个输入参数被函数自己接受。在一个类c中，缺省版本的operator=函数具有如下形式（见弄清C++在幕后为你所写、所调用的函数）：

一般情况下几乎总要遵循operator=输入和返回的都是类对象的引用的原则，然而有时候需要重载operator=使它能够接受不同类型的参数。例如，标准string类型提供了两个不同版本的赋值运算符：

请注意，即使在重载时，返回类型也是类的对象的引用。

c++程序员经常犯的一个错误是让operator=返回void，这好象没什么不合理的，但它妨碍了连续（链式）赋值操作，所以不要这样做。

另一个常犯的错误是让operator=返回一个const对象的引用，象下面这样：

这样做通常是为了防止程序中做象下面这样愚蠢的操作：

这样的做法实际中很少看到，但它对int来说是可以的，对我和我的类来说也可以。那它对你和你的类也应该可以。为什么要无缘无故地和固定类型的常规做法不兼容呢？

采用缺省形式定义的赋值运算符里，对象返回值有两个很明显的候选者：赋值语句左边的对象（被this指针指向的对象）和赋值语句右边的对象（参数表中被命名的对象）。哪一个是正确的呢？

例如，对string类（假设你想在这个类中写赋值运算符，参见为需要动态分配内存的类声明一个拷贝构造函数和一个赋值操作符中的解释）来说有两种可能：

对你来说，这好象是拿六个一和十二的一半来比较一样为难。实际上他们有很大的不同。

首先，返回rhs的那个版本不会通过编译，因为rhs是一个const string的引用，而operator=要返回的是一个string的引用。当要返回一个非const的引用而对象自身是const时，编译器会给你带来无尽的痛苦。看起来这个问题很容易解决——只用象这样重新声明operator=：

这次又轮到用到它的应用程序不能通过编译了！再看看最初那个连续赋值语句的后面部分：

因为赋值语句的右边参数不是正确的类型——它是一个字符数组，不是一个string——编译器就要产生一个临时的string对象使得函数继续运行。就是说，编译器必须产生大致象下面这样的代码：

编译器一般会产生这样的临时值（除非显式地定义了所需要的构造函数——见分清成员函数，非成员函数和友元函数），但注意临时值是一个const。这很重要，因为它可以防止传递到函数内的临时值被修改。否则，程序员就会很奇怪地发现，只有编译器产生的临时值可以修改而他们在函数调用时实际传进去的参数却不行。（关于这一点是有事实根据的，早期版本的c++允许这类的临时值可以被产生，传递，修改，结果很多程序员感到很奇怪）

现在我们就可以知道如果string的operator=声明传递一个非const的stirng参数，应用程序就不能通过编译的原因了：对于没有声明相应参数为const的函数来说，传递一个const对象是非法的。这是一个关于const的很简单的规定。

所以，结论是，这种情况下你将别无选择：当定义自己的赋值运算符时，必须返回赋值运算符左边参数的引用，*this。如果不这样做，就会导致不能连续赋值，或导致调用时的隐式类型转换不能进行，或两种情况同时发生。