Effective C++ 2e Item15

原创 2001年07月08日 19:35:00

条款15: 让operator=返回*this的引用

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

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

int w, x, y, z;

w = x = y = z = 0;

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

string w, x, y, z;               // string是由标准C++库
                                 // “自定义”的类型
                                 // (参见条款49)

w = x = y = z = "Hello";

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

w = (x = (y = (z = "Hello")));

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

w.operator=(x.operator=(y.operator=(z.operator=("Hello"))));

这个格式在此很具有说明性,因为它强调了w.operator=, x.operator=和y.operator=的参数是前一个operator=调用的返回值。所以operator=的返回值必须可以作为一个输入参数被函数自己接受。在一个类C中,缺省版本的operator=函数具有如下形式(见条款45):

C& C::operator=(const C&);

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

string&                            // 将一个string
operator=(const string& rhs);      // 赋给一个string

string&                            // 将一个char*
operator=(const char *rhs);        // 赋给一个string

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

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

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

class Widget {
public:
  ...                                           
  const Widget& operator=(const Widget& rhs);   
  ...                                           
};                                              

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

Widget w1, w2, w3;

...

(w1 = w2) = w3;         // w2赋给w1, 然后w3赋给其结果
                        // (给operator=一个const返回值
                        // 就使这个语句不能通过编译)

这可能是很愚蠢,但固定类型这么做并不愚蠢:

int i1, i2, i3;

...

(i1 = i2) = i3;                // 合法! i2赋给i1
                               // 然后i3赋给i1!

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

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

例如,对String类(假设你想在这个类中写赋值运算符,参见条款11中的解释)来说有两种可能:

String& String::operator=(const String& rhs)
{

  ...

  return *this;            // 返回左边的对象
}

String& String::operator=(const String& rhs)
{

  ...

  return rhs;              // 返回右边的对象
}

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

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

String& String::operator=(String& rhs)   { ... }

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

x = "Hello";                     // 和x.op=("Hello");相同

因为赋值语句的右边参数不是正确的类型——它是一个字符数组,不是一个String——编译器就要产生一个临时的String对象(通过Stirng构造函数——参见条款M19)使得函数继续运行。就是说,编译器必须产生大致象下面这样的代码:

const String temp("Hello");      // 产生临时String

x = temp;                        // 临时String传给operator=

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

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

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

《Effective C++》学习笔记——条款31

《Effective C++》学习笔记——条款31:将文件间的编译依存关系降至最低
  • lx417147512
  • lx417147512
  • 2015年06月15日 13:51
  • 1364

《Effective C++》让自己习惯C++:条款1-条款4

《Effective C++》条款1到条款4。基本是总结C++的一些特点,尤其是不同于C语言的特点。...
  • KangRoger
  • KangRoger
  • 2014年12月13日 19:26
  • 2344

effective C++ 目录(第三版)

我把目录整理一下,方便在以后工作中查看。 条款01:视C++为一个语言联邦 条款02:尽量以const,enum,inline替换#define 条款03:尽可能使用const 条...
  • u010889616
  • u010889616
  • 2015年12月24日 20:12
  • 513

《Effective C++》读后感

几天前,我曾在微信朋友圈中发了一条消息: 和大牛之间的差距就是这一个书架。 图片来自于微信公众号“二爷鉴书”的分享。 我时常纠结于自己的技术为什么进步的这么慢,大概就是书读的太少、思考的太少。 《E...
  • Since20140504
  • Since20140504
  • 2016年06月27日 12:13
  • 7422

《Effective C++》:条款44-条款45

条款44将与参数无关的代码抽离templates 条款45运用成员函数模板接受所有兼容类型...
  • KangRoger
  • KangRoger
  • 2015年03月12日 22:01
  • 1481

【C++】《Effective C++》读书笔记汇总

我之前边读《Effective C++》边写下每个条款的读书笔记,这一版是C++11之前的版本。这里我将每个条款令我印象深刻的点小结一下。 1、C++包括:Plain C(面向过程)、OOP(面向对...
  • lpsl1882
  • lpsl1882
  • 2016年04月06日 11:14
  • 2218

《Effective C++》学习笔记(六)

原创文章,转载请注明出处:http://blog.csdn.net/sfh366958228/article/details/38922567 前言 今天学的条款都是出自于《设计与声明》这一张,...
  • sfh366958228
  • sfh366958228
  • 2014年08月29日 20:00
  • 741

《Effective C++》:条款41-条款42

条款41了解隐式接口和编译期多态 条款42了解typename的双重意义条款
  • KangRoger
  • KangRoger
  • 2015年03月10日 22:13
  • 1200

《Effective C++》:条款28-条款29

条款28避免返回handles指向对象内部成分:指的是不能返回对象内部数据/函数的引用、指针等。 条款29为异常安全而努力是值得的:指的是要有异常处理机制,避免发生异常时造成资源泄露等问题。...
  • KangRoger
  • KangRoger
  • 2015年02月19日 19:47
  • 1370

《Effective C++》资源管理:条款13-条款15

在系统中,资源是有限的,一旦用完必须归还给系统,否则可能会造成资源耗尽或其他问题。例如,动态分配的内存如果用完不释放会造成内存泄漏。 这里说的资源不仅仅是指内存,还包括其他,例如文件描述符、网络连接、...
  • KangRoger
  • KangRoger
  • 2015年01月14日 21:46
  • 1282
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Effective C++ 2e Item15
举报原因:
原因补充:

(最多只允许输入30个字)