Effective C++ 2e Item16

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

条款16: 在operator=中对所有数据成员赋值

条款45说明了如果没写赋值运算符的话,编译器就会为你生成一个,条款11则说明了为什么你会经常不喜欢编译器为你生成的这个赋值运算符,所以你会想能否有个两全其美的办法,让编译器生成一个缺省的赋值运算符,然后可以有选择地重写不喜欢的部分。这是不可能的!只要想对赋值过程的某一个部分进行控制,就必须负责做赋值过程中所有的事。

实际编程中,这意味着写赋值运算符时,必须对对象的每一个数据成员赋值:

template<class T>          // 名字和指针相关联的类的模板
class NamedPtr {           // (源自条款12)
public:
  NamedPtr(const string& initName, T *initPtr);
  NamedPtr& operator=(const NamedPtr& rhs);

private:
  string name;
  T *ptr;
};

template<class T>
NamedPtr<T>& NamedPtr<T>::operator=(const NamedPtr<T>& rhs)
{
  if (this == &rhs)
    return *this;              // 见条款17

  // assign to all data members
  name = rhs.name;             // 给name赋值

  *ptr = *rhs.ptr;             // 对于ptr,赋的值是指针所指的值,
                               // 不是指针本身

  return *this;                // 见条款15
}

初写这个类时当然很容易记住上面的原则,但同样重要的是,当类里增加新的数据成员时,也要记住更新赋值运算符函数。例如,打算升级NamedPtr模板使得名字改变时附带一个时间标记,那就要增加一个新的数据成员,同时需要更新构造函数和赋值运算符。但现实中,因为忙于升级类的具体功能和增加新的成员函数等,这一点往往很容易被忘记。

当涉及到继承时,情况就会更有趣,因为派生类的赋值运算符也必须处理它的基类成员的赋值!看看下面:

class Base {
public:
  Base(int initialValue = 0): x(initialValue) {}

private:
  int x;
};

class Derived: public Base {
public:
  Derived(int initialValue)
  : Base(initialValue), y(initialValue) {}

  Derived& operator=(const Derived& rhs);

private:
  int y;
};

逻辑上说,Derived的赋值运算符应该象这样:

// erroneous assignment operator
Derived& Derived::operator=(const Derived& rhs)
{
  if (this == &rhs) return *this;    // 见条款17

  y = rhs.y;                         // 给Derived仅有的
                                     // 数据成员赋值

  return *this;                      // 见条款15
}

不幸的是,它是错误的,因为Derived对象的Base部分的数据成员x在赋值运算符中未受影响。例如,考虑下面的代码段:

void assignmentTester()
{
  Derived d1(0);                      // d1.x = 0, d1.y = 0
  Derived d2(1);                      // d2.x = 1, d2.y = 1

  d1 = d2;         // d1.x = 0, d1.y = 1!
}

请注意d1的Base部分没有被赋值操作改变。

解决这个问题最显然的办法是在Derived::operator=中对x赋值。但这不合法,因为x是Base的私有成员。所以必须在Derived的赋值运算符里显式地对Derived的Base部分赋值。

也就是这么做:

// 正确的赋值运算符
Derived& Derived::operator=(const Derived& rhs)
{
  if (this == &rhs) return *this;

  Base::operator=(rhs);    // 调用this->Base::operator=
  y = rhs.y;

  return *this;
}

这里只是显式地调用了Base::operator=,这个调用和一般情况下的在成员函数中调用另外的成员函数一样,以*this作为它的隐式左值。Base::operator=将针对*this的Base部分执行它所有该做的工作——正如你所想得到的那种效果。

但如果基类赋值运算符是编译器生成的,有些编译器会拒绝这种对于基类赋值运算符的调用(见条款45)。为了适应这种编译器,必须这样实现Derived::operator=:

Derived& Derived::operator=(const Derived& rhs)
{
  if (this == &rhs) return *this;

  static_cast<Base&>(*this) = rhs;      // 对*this的Base部分
                                        // 调用operator=
  y = rhs.y;

  return *this;
}

这段怪异的代码将*this强制转换为Base的引用,然后对其转换结果赋值。这里只是对Derived对象的Base部分赋值。还要注意的重要一点是,转换的是Base对象的引用,而不是Base对象本身。如果将*this强制转换为Base对象,就要导致调用Base的拷贝构造函数,创建出来的新对象(见条款M19)就成为了赋值的目标,而*this保持不变。这不是所想要的结果。

不管采用哪一种方法,在给Derived对象的Base部分赋值后,紧接着是Derived本身的赋值,即对Derived的所有数据成员赋值。

另一个经常发生的和继承有关的类似问题是在实现派生类的拷贝构造函数时。看看下面这个构造函数,其代码和上面刚讨论的类似:

class Base {
public:
  Base(int initialValue = 0): x(initialValue) {}
  Base(const Base& rhs): x(rhs.x) {}

private:
  int x;
};

class Derived: public Base {
public:
  Derived(int initialValue)
  : Base(initialValue), y(initialValue) {}

  Derived(const Derived& rhs)      // 错误的拷贝
  : y(rhs.y) {}                    // 构造函数

private:
  int y;
};

类Derived展现了一个在所有C++环境下都会产生的bug:当Derived的拷贝创建时,没有拷贝其基类部分。当然,这个Derived对象的Base部分还是创建了,但它是用Base的缺省构造函数创建的,成员x被初始化为0(缺省构造函数的缺省参数值),而没有顾及被拷贝的对象的x值是多少!

为避免这个问题,Derived的拷贝构造函数必须保证调用的是Base的拷贝构造函数而不是Base的缺省构造函数。这很容易做,只要在Derived的拷贝构造函数的成员初始化列表里对Base指定一个初始化值:

class Derived: public Base {
public:
  Derived(const Derived& rhs): Base(rhs), y(rhs.y) {}

  ...

};

现在,当用一个已有的同类型的对象来拷贝创建一个Derived对象时,它的Base部分也将被拷贝了。

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

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

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

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

effective C++ 目录(第三版)

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

《Effective C++》读后感

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

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

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

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

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

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

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

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

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

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

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

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

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

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