Effective C++ (二) : 构造/析构/赋值运算

朱雀 2022-05-26 04:12 171阅读 0赞

# 构造/析构/赋值运算 #

## 条款05：了解C++默默编写并调用哪些函数 ##

写一个空类，当自己没声明，编译器会声明一个default构造函数，声明一个copy构造函数，一个copy assignment操作符和一个析构函数。所有这些函数都是public且inline。

class Empty { };
    //等价于
    class Empty {
        public:
                Empty() { ... }                         //default构造函数
                Empty(const Empty& rhs) { ... }         //copy构造函数
                ~Empty() { ... }                        //析构函数
                
                Empty& operator=(const Empty& rhs) { ... }      //copy assignment操作符
    }

Empty e1;               //default构造函数
    Empty e2(e1);           //copy构造函数
    e2 = e1;                //copy assignment操作符

唯有当这些函数被调用时，才会被编译器创建出来。

编译器产生的析构函数是non-virtual的，除非基类声明有virtual析构函数。

举个例子：

//假设NamedObject定义如下，其中nameValue是个reference to string,objectValue是个const T
    template <typename T>
    class NamedObject {
        public:
            NamedObject(std::string& name, const T& value); 
            ....            //假设未声明operator=
        private:
            std::string& nameValue;     //注意，这里是个引用、
            const T objectValue;        //是个const
    };

现在考虑下面发生的事：

std::string newDog("Persephone");
    std::string oldDog("Satch");
    
    NamedObject<int> p(newDog,2); 
    NamedObject<int> s(odlDog,36);
    /* 此时, p.nameValue 和 s.nameValue分别指向string对象 */
    
    p = s;      //现在p发生了什么？

p = s赋值之后，p.nameValue应该指向s.nameValue所指的那个string吗？也就是说reference自身可被改动吗？

C++并不允许“让reference改指向不同对象”。若p.nameValue所指的string对象被修改，进而影响“持有pointers或references指向该string"的其它对象。

例如：

int a = 10, b = 5;
    int &c = a;
    int &d = b;
    c = d;      //现在a,b,c,d都是5

总结：

\-编译器可以暗自为class创建default构造函数，copy拷贝构造函数，copy assignment拷贝赋值操作符，以及析构函数。

## 条款06：若不想使用编译器自动生成的函数，就该明确拒绝 ##

所有编译器产出的函数都是public的，如果你不想使用自动生成的函数或者操作符，你在类中手动把它们声明为private。

藉由明确声明一个成员函数，阻止了编译器暗自创建其专属版本；而令这些函数为private的，使你得以成功阻止了人们调用它。

这个做法也不一定绝对安全，因为成员函数和friend函数还是可以调用private。

class HomeForSale {
        public:
            ...
        private:
            ...
            HomeForSale(const HomeForSale&);            //阻止copy构造函数
            HomeForSale& operator=(const HomeForSale&); //阻止copy操作符
    }

有了以上class定义，企图拷贝HomeForSale对象，编译器会阻挠。

如果不慎在member函数或friend函数中这么做，就轮到连接器抱怨啦～

为了阻止member函数和friend函数的copying动作，我们需要做的是继承类：

class Uncopyable {
        protected:
            Uncopyable(const Uncopyable&);              //阻止copying
            Uncopyable& operator=(const Uncopyable&);
    };
    
    class HomeForSale: private  Uncopyable {            //class不再声明copy构造函数或copy assignment操作符
        ...     
    };

此时当任何对象尝试拷贝HomeForSale对象，会尝试调用基类中的对应函数，但是这些调用会被拒绝，因为基类的拷贝函数是private

总结：  
\-为驳回编译器自动（暗自）提供的机能，可将相应的成员函数声明为private并且不予实现。使用像Uncopyable这样的base class的基类也是一种做法。

## 条款07：为多态基类声明virtual析构函数 ##

//设计一个TimeKeeper base class和一些derived classes作为不同的计时方法。
    class TimeKeeper {
        public:
            TimeKeeper();
            ~TimeKeeper();
            ...
    };
    class AtomicClock: public TimeKeeper { ... };       //原子钟
    class WaterClock: public TimeKeeper { ... };        //水钟
    class WristWatch: public TimeKeeper { ... };        //腕表

设计一个函数，返回一个base class指针，指向新生成的derived class对象：

TimeKeeper* getTimeKeeper();                        //返回一个指针，指向一个TimeKeeper派生类的动态分配对象

TimeKeeper* ptk = getTimeKeeper();                  //从TimeKeeper继承体系,获得一个动态分配对象，运用它。。
    ...
    delete ptk;                 //释放，避免内存泄漏。

问题出在，getTimeKeeper()返回的指针指向一个derived class对象，而那个对象却由一个base class指针(ptk)被删除，而基类中析构函数不是虚函数。

C++明确指出，当derived class对象经由一个base class指针被删除，而base class带着non-virtual析构函数，其结果无定义。

实际执行时通常发生的是对象的derived成分没被销毁。

消除这个问题的做法很简单：给base class一个virtual析构函数。此后消除则会消除整个对象。包括derived class成分。

class TimeKeeper {
        public:
            TimeKeeper();
            virtual ~TimeKeeper();
            ...
    };
    TimeKeeper* ptk = getTimeKeeper();
    ...
    delete ptk;                         //现在，行为正确

virtual函数的目的是允许derived class的实现得以客制化。

如果class不含virtual函数，通常表示它并不意图被用做一个base class。

欲实现出virtual函数，对象必须携带某些信息，主要用来在运行期决定哪一个virtual函数该被调用。

这份信息通常由一个vptr(virtual table pointer)虚函数表指针指出。vptr指向一个由函数指针构成的数组，称为vtbl(虚函数表); 每一个带有virtual函数的class都有一个相应的vtbl。当对象调用某一virtual函数，实际被调用的函数取决于该对象的vptr所指的那个vtbl-编译器在其中寻找适当的函数指针。

无端地将所有classes的析构函数声明为virtual，就像从未声明它们为virtual一样，都是错误的。

即使class完全不带virtual函数，也可能会出问题。

例如：标准string不带任何virtual函数，但有时候程序员会错误地把它当作基类：

class SpecialString: public std::string {   //str::string有个non-virtual析构函数
        ...
    };
    
    SpecialString* pss = new SpecialString("Impending Doom");
    std::string* ps;
    ...
    ps = pss;           //SpecialString* => std::string*
    ...
    delete ps;          //未有定义，*ps的SpecialString资源会泄漏，因为SpecialString的析构函数没被调用。

相同的分析适用于任何不带virtual析构函数的class，包括所有STL容器如vector,list,set,tr1::unordered\_map等等。

有时候令class带有 纯虚数析构函数，会非常便利。纯虚数函数导致抽象类。抽象类总被当作一个基类。

为你希望成为抽象的那个class声明一个纯虚数析构函数。

例子：

class AWOV {
        public:
            virtual ~AWOV() = 0;        //声明pure virtual析构函数
    };
    AWOV::~AWOV() { }               //pure virtual析构函数的定义

析构函数的运作方式是：

最深层派生的那个class其析构函数最先被调用，然后是其每一个基类的析构函数被调用。

给基类一个虚析构函数这个规则只适用于带多态性的基类身上。

总结：  
polymorphic(带多态性质的) base classes应该声明一个virtual析构函数。如果class带有任何virtual函数，它就应该拥有一个virtual析构函数。

Classes的设计目的如果不是作为base classes使用，或不是为了具备多态性，就不该声明virtual析构函数。

## 条款08：别让异常逃离析构函数 ##

C++不喜欢析构函数吐出异常！如果你的析构函数必须执行一个动作，而该动作可能会在失败时抛出异常，怎么办？

例子：假设使用一个class负责数据库连接

class DBConnection {    
        public:
            ...
            static DBConnection create();           //这个返回返回DBConnection对象；
            
            void close();                           //力求简化暂略参数。关闭联机；失败则抛出异常。
    };

为确保不忘记在DBConnection对象身上调用close(),创建一个管理DBConnection资源的class,并在其析构函数中调用class。

class DBConn {                                  //这个class用来管理DBConnection对象
        public:
            ...
            ~DBConn()                               //确保数据库连接总是会被关闭
            {
                db.close();
            }
        private:
            DBConnection db;
    };

这便允许客户写出这样的代码：

{                                           //开启一个区块
        DBConn dbc(DBConnection::create());     //建立DBConnection对象并交给DBConn对象以便管理。
                                                //通过DBConn的接口，使用DBConnection对象，
                                                //在区块结束前，DBConn对象被销毁，
                                                //因而自动为DBConnection对象调用close
        ...
    }

只要close成功，一切都还好。如果该调用导致异常，DBConn析构会传播该异常，也就是允许它离开这个析构函数。会抛出难以驾驭的麻烦。

两种办法避免这个问题，DBConn析构函数可以：

1.如果close抛出异常就结束程序，通常通过调用abort完成：

DBConn::~DBConn ()
    {
        try { db.close(); }
        catch (...) {
            //制作运转记录,记下对close的调用失败
            std::abort();
        }
    }

调用abort可以抢先制”不明确行为“于死地。

2.吞下因调用close而发生的异常：

DBConn::~DBConn()
    {
        try { db.close(); }
        catch (...) {
            //制作运转记录，记下对close的调用失败
        }
    }

一般而言，将异常吞掉是个坏主意，压制了某些动作失败的重要信息。为了让这成为一个可行方案，程序必须能够继续可靠地执行，即使在遭遇并忽略一个错误之后。

最佳策略（敲黑板！！重点！！！）

重新设计DBConn接口，使其客户有机会对可能出现的问题作出反应。

class DBCoon {
        public:
            ...
            void close()                    //供客户使用的新函数
            {
                db.close();
                closed = true;
            }
            ~DBCoon()
            {
                if (!closed) {
                    try {                   //关闭连接
                        db.close();
                    }
                    catch(...) {                //如果关闭失败,记录下来并结束程序或吞下异常
                        //制作运转记录，记下对close的调用失败
                        ...
                    }
                }
            }
        private:
            DBConnection db;
            bool closed;
    };

把close的责任从DBConn析构函数上移到DBConn客户手上。

析构函数吐出异常就是危险，总会带来”过早结束程序"或“发生不明确行为”的风险。

总结：

\-析构函数绝不要吐出异常，如果一个被析构函数调用的函数可能抛出异常，析构函数应该捕捉任何异常，然后吞下它们或结束程序

\-如果客户需要对某个操作函数运行期间抛出的异常作出反应，那么class应该提供一个普通函数执行该操作。

## 条款09：绝不在构造和析构过程中调用virtual函数 ##

有个class继承体系，用来股市交易如买进、卖出订单等。交易要经过审计。所以每当创建一个交易对象，在审计日志中也需要创建一笔记录。做法：

class Transaction {                         //所有交易的base class 
        public: Transaction(); 
        virtual void logTransaction() const = 0; //纯虚函数作为日志文件，因为类型不同而不同 
        ...
    };
    Transaction::Transaction()                  //base calss构造函数的实现·
    {
        ...
        logTransaction();                       //最后动作是志记这笔交易
    }；
    class BuyTransaction: public Transaction {       //derived class· 
        public:
            virtual void logTransaction() const;    //志记此型交易· 
            ...
    };
    class SellTransaction: public Transaction {     //derived class· 
        public:
            virtual void logTransaction() const;    //志记此型交易
            ...
    };

当执行：

BuyTransaction b;

先调用BuyTransaction构造函数，但首先Transaction构造函数一定会更早调用。而Transaction直接调用了一个virtual函数，这违反了本条款。因为logTransaction函数在Transaction内是纯虚数，除非被定义，否者连接器找不到必要的Transaction::logTransaction的实现代码。

在基类的构造期间，virtual函数不是virtual函数。

唯一能避免此问题的做法就是：确定构造函数和析构函数都没有调用virtual函数，而它们调用的所有元素都服从同一约束。

如何确保每次一有Transaction继承体系上的对象被创建，就会有适宜版本的logTransaction被调用呢？显然，在Transaction构造函数内对着对象调用virtual函数是一个错误做法。

一种做法是在class Transaction内将logTransaction函数改为non-virtual,然后要求derived class构造函数传递必要信息给Transaction构造函数，而后那个构造函数便可安全地调用non-virtual logTransaction。

class Transaction {
        public:
            explicit Transaction(const std::string& logInfo);
            void logTransaction(const std::string& logInfo) const;      //如今是个non-virtual函数
            ...
    };
    
    Transaction::Transaction(const std::string& logInfo)
    {
        ...
        logTransaction(logInfo);                //如今是个non-virtual调用
    }
    
    class BuyTransaction: public Transaction {
        public:
            BuyTransaction( parameters )
            : Transaction(createLogString( parameters ))            //将log信息传给基类构造函数
            { ... }
            ...
        private:
            static std::string createLogString( parameters );       //利用辅助函数createLogString创建值传递给基类构造函数往往比较方便。
    };

换句话说，由于你无法使用virtual函数从base classes向下调用，在构造期间，你可以”令derived classes将必要的构造信息向上传递至base class构造函数“替换之而加以弥补。

总结：

\-在构造和析构期间不要调用virtual函数，因为这类调用从不下降至derived class(比起当前执行构造函数和析构函数的那层)

## 条款10：令operator=返回一个reference to \*this ##

连锁赋值：

x = ( y = ( z = 15 ));

15先被赋值给z,其结果在赋值给y,然后其结果再被赋值给x

为了实现连锁赋值，赋值操作符必须返回一个reference指向操作符的左侧实参。这是你为classes实现赋值操作符时应该遵循的协议。

class Widget {
        public:
            Widget& operator = (const Widget& rhs)              //返回类型是一个reference,指向当前对象
            {
                ...
                return *this;                                   //返回左侧对象
            }
            ...
    };

请记住：

\-令赋值操作符返回一个reference to \*this。

## 条款11：在operator=中处理”自我赋值“ ##

"自我赋值”发生在对象被赋值给自己时：

class Widget { ... };
    Widget w;
    ...
    w = w;                  //赋值给自己

一般而言如果某段代码操作pointers或references而它们被用来”指向多个相同类型的对象“，就需考虑这些对象是否为同一个。

例：

class Bitmap { ... } ;
    class Widget {
        ...
        private:
            Bitmap * pb;                //指针，指向一个从help分配而得的对象
    };

下面是operator=实现代码：

Widget& Widget::operator = (const Widget& rhs)      //不安全的operator=实现版本
    {
        delete pb;                                      //停止使用当前的bitmap
        pb = new Bitmap(*rhs.pb);                       //使用rhs的副本
        return *this;
    }

这里自我赋值会出现的问题是，operator=函数内的\*this (pb指向的对象,赋值的目的端)和rhs有可能是同一对象。若是这样那么delete就不只是销毁当前对象的bitmap,它也销毁了rhs的bitmap。在函数末尾，Widget发现自己持有的一个指针指向一个已被删除的对象！

欲阻止这种错误，在operator= 最前面加一个”证同测试“达到”自我赋值“的检验目的：

Widget& Widget::opertor = (const Widget& rhs)
    {
        if ( this = &rhs )  return *this;           //证同测试
        
        delete pb ;
        pb = new Bitmap(*rhs.pb);
        return *this;
    }

让operator=具备”异常安全性“往往自动获得”自我赋值安全“的回报。异常安全性在条款29上探究。

例如一下代码，不用证同测试也能达到目的：(虽然效率比较低)

Widget& Widget::operator=(const Widget& rhs)
    {
        Bitmap *pOrig = pb;                         //记住原来的pb
        pb = new Bitmap(*rhs.pb);                   
        delete pOrig;                               //删除原来的pb
        return *this;
    }

在operator=函数内手工排列语句（确保代码不但安全并且自我赋值安全）的一个替代方案是，使用所谓的copy and swap技术。

class Widget {
        ...
        void swap(Widget& rhs);                     //交换*this和rhs的数据
        ...
    };
    
    Widget& Widget::operator=(const Widget& rhs)
    {
        Widget temp(rhs);                           //为rhs数据制作一份副本
        swap(temp);                                 //将*this数据和上述副本的数据交换
        return *this;
    }

这个主题的另一个变奏曲利用以下事实：

\-某class的copy assignment操作符可能被声明为"以by value方式接受实参”；

\-以by value方式传递东西会造成一份复件/副本:

Widget& Widget::operator=(Widget rhs)       //rhs是被传对象的一个副本
    {
        swap(rhs);                              //这里是pass by value
        return *this;                           //将*this的数据和复件/副本的数据互换
    }

请记住：

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

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

## 条款12：复制对象时勿忘其每一个成分 ##

设计良好之面向对象系统会将对象的内部封装起来，只留两个函数负责对象拷贝（复制），那便带着适切名称的copy构造函数和copy assignment操作符，我们称它们为copying函数。

考虑一个class用来表现顾客，其中手工写出copying函数，使得外界对它们的调用会被志记下来：

void logCall(const std::string& funcName);              //制造一个log entry
    class Date { ... };                     //日期
    class Customer {
        public:
            ...
            Customer(const Customer& rhs);
            Customer& operator=(const Customer& rhs);
            ...
        private:
            std::string name;
            Date lastTransaction;
    };
    Customer::Customer(const Customer& rhs) : name(rhs.name)                //复制rhs的数据
    {
        logCall("Customer copy constructor");
    }
    
    Customer& Customer::operator=(const CUstomer& rhs)
    {
        logCall("CUstomer copy assignment operator");
        name = rhs.name;
        return *this;
    }

现在既有的copying函数执行的是局部拷贝：的确复制了name,但没有复制新添加的lastTransaction..

结论很明显：如果你为class添加一个成员变量，你必须同时修改copying函数。

一但发生继承，可能会造成此主题最暗中肆虐的一个潜藏危机：

class PriorityCustomer: public Customer {                           //一个derived class
        public:
            ...
            PriorityCustomer(const PriorityCustomer& rhs);
            PeiorityCustomer& operator=(const PriorityCustomer& rhs);
            ...
        private:
            int priority;
    };
    PriorityCustomer::PriorityCustomer(const PriorityCustomer& rhs) : priority(rhs.priority)
    {
        logCall("PriorityCustomer copy constructor");
    }
    PriorityCustomer&
    PriorityCustomer::operator=(const PriorityCustomer& rhs)
    {
        logCall("PriorityCustomer copy assignment operator");
        //Customer::operator=(rhs);                 //pass by value
        priority = rhs.priority;
        return *this;
    }

PriorityCustomer的copying函数看起来好像是复制了所有的PriorityCustomer声明的成员变量。但是PriorityCustomer还内含它继承的Customer成员变量复件，而那些成员变量却未被复制。

PriorityCustomer中的构造函数也没有指定实参传给基类构造函数。所以Customer成分会被Customer default默认构造函数初始化。

所以，任何时候你都要承担起“为derived class写copying函数”的重大责任。

在第10行成员初值列后加入：Customer(rhs);

在operator=拷贝构造运算符的函数中Customer::operator=(rhs); //对base class成分进行赋值动作

当编写一个copying函数：

\-复制所以local成员变量

\-调用所以base classes内的适当的copying函数。

令copy assignment操作符调用copy构造函数是不合理的。

反过来：令copy欧早函数调用copy assignment操作符同样无意义。

如果发现copy构造函数和copying assignment操作符有相近的代码，消除重复代码的做法是：建立一个新的成员函数给两者用调用。这样的函数往往是private且常被命名为init。这种策略可以消除copy构造函数和copy assignment操作符之间的代码重复。

请记住：