zoukankan      html  css  js  c++  java
  • 在operator=中对所有数据成员赋值

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

    代码
    template<class t> // 名字和指针相关联的类的模板
    class namedptr { // (源自条款12)
    public:
    namedptr(
    const string& initname, t *initptr);
    namedptr
    & operator=(const namedptr& rhs);
    private:
    string name;
    *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
    = 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=
    = 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=
    = 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部分也将被拷贝了。
  • 相关阅读:
    解读AppIcon图标设置置信息和App内存警告临界值
    我在外包公司做增删改查有前途么?
    浅议Grpc传输机制和WCF中的回调机制的代码迁移
    2019.NET Conf China(中国.NET开发者峰会)活动全纪录:.NET技术之崛起,已势不可挡
    一位年轻而优秀的.NET开发者的成长点滴
    领域驱动设计-让程序员心中有码(九)
    2019.NET Conf,我们在共同期待
    码农的技术小世界
    .NET Core使用gRPC打造服务间通信基础设施
    坚持写了一年的博客,我有哪些收获
  • 原文地址:https://www.cnblogs.com/lancidie/p/1856742.html
Copyright © 2011-2022 走看看