读书笔记《Effective C++》条款11:令operator=中处理”自我赋值“

先看个例子:

class Bitmap {

};

class Widget {
public:
	Widget& operator=(const Widget& rhs);
private:
	Bitmap* pb;//指针,指向一个从heap分配而得到的对象
};

下面是operator=实现代码,表明上看起来合理,但自我赋值出现时并不安全(它也不具备异常安全性)。

Widget& Widget::operator=(const Widget& rhs)//一份不安全的operator=实现版本
{
	delete pb;//停止使用当前的bitmap
	pb = new Bitmap(*rhs.pb);//使用rhs's bitmap的副本
	return *this;
}
这里的自我赋值问题是,operator=函数内的*this(赋值的目的端)和rhs有可能是同一个对象。果真如此delete就不只是销毁当前对象的bitmap,它也销毁rhs的bitmap。在函数末尾,Widget——它原本不该自我赋值动作改变的——发现自己持有一个指针指向一个已被删除的对象!

欲阻止这种错误,传统做法是藉由operator=最前面一个“认同测试”达到“自我赋值”的检查目的:

Widget& Widget::operator=(const Widget& rhs)
{
	if (this == &rhs)//认同测试:如果是自我赋值,就不做任何事
		return *this;

	delete pb;
	pb = new Bitmap(*rhs.pb);
	return *this;
}
这样做行得通。但是这个版本存在异常方面的问题。如果“new Bitmap”导致异常(不论是因为分配时内存不足或因为Bitmap的copy构造函数抛出异常),Widget最终会持有一个指针指向一个被删除的Bitmap。这样的指针有害。你无法安全的删除它们,甚至无法安全的读取它们。唯一能对它们做的安全事情就是付出许多调试能量找出错误的起源。

令人高兴的是,让operator=具备“异常安全性”往往自动获得“自我赋值安全”的回报。因此越来越多人对“自我赋值”的处理态度是倾向不去管它,把焦点放在实现“异常安全性”上。例如下代码,我们只需注意在赋值pb所指东西之前别删除pb:

Widget& Widget::operator=(const Widget& rhs)
{
	Bitmap* pOrig = pb;//记住原先的pb
	pb = new Bitmap(*rhs.pb);//令pb指向*pb的一个复件
	delete pOrig;//删除原先的pb
	return *this;
}
现在,如果“new Bitmap”抛出异常,pb保持原状。即使没有认同测试,这段代码还是能够处理自我赋值,因为我们对原bitmap做了一份复件、删除原bitmap、然后指向新制造的那个复件。它或许不是处理“自我赋值”的最高效办法,但它行得通。


要点:

1.确保当对象自我赋值时operator=有良好行为。其中技术包括比较“来源对象”和“目标对象”的地址、精心周到的语句顺序、以及copy-and-swap。

2.确定任何函数如果操作一个以上的对象,而其中多个对象是同一个对象时,其行为仍然正确。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值