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

构造/析构/赋值运算

条款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

连锁赋值：

1

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操作符之间的代码重复。

 

请记住：

-copying函数应该确保复制“对象内所有成员变量”及”所有base class成分“

-不要尝试以某个copying函数实现另一个copying函数，应该将共同机能放进第三个函数，并由两个copying函数共同调用。