条款05、了解C++默默编写并调用哪些函数
什么时候empty class(空类)不再是个empty class呢?当C++ 处理过它之后。是的,如果你自己没有声明,编译器就会为它声明(编译器版本的)一个copy析构函数、一个copy assignment操作符和一个析构函数。此外如果你没有声明任何构造函数,编译器也会为你声明一个default析构函数。所有这些函数都是public和inline的。因此,如果你写下:
class Empty{ };
这就好像你写下这样的代码:
class Empty{
public:
Empty(){...} //default 构造函数
Empty(const Empty & rhs){...} // copy 析构函数
~Empty(){...} //析构函数,是否该是virtual 间稍后说明
Empty& operator=(const Empty &rhs) {...} //copy assignment 操作符
};
唯有当这些函数被需要(被调用),它们才会被编译器创建出来。程序中需要它们是很平常的事情。下面代码造成上述每一个函数被编译器产出:
Empty e1; //default 析构函数
//析构函数
Empty e2(e1); //copy 构造函数
e2=e1; //copy assignment 操作符
至于copy 构造函数和copy assignment 操作符,编译器创建的版本只是单纯地将来源对象的每一个non-static成员变量拷贝到目标对象。
举个例子,假设NameObject定义如下,其中nameValue是个reference to string,objectValue是个const T:
template<class T>
class NameObject{
public:
//以下构造函数如今不再接受一个const 名称,因为nameValue
//如今是个reference-to-non-const string。先前那个char* 析构函数
//已经过去了,因为必须有个string 可供指涉。
NameObject(std::string* name,const T& value);
... //如前,假设并未声明operator=
private:
std::string& nameValue;//这如今是个reference
const T objectValue;//这如今是个const
};
现在考虑下面会发生什么事:
std::string newDog("Persephone");//
std::string oldDog("Satch");
NameObject<int> p(newDog,2);//当初撰写至此,我们的狗Persephone
//即将度过其第二个生日
NameObject<int> s(oldDog,36);//我小时候养的狗Satch则是36岁,--如果它还活着
p=s; //现在p的成员变量该发生什么事
赋值之前,不论p.nameValue和s.nameValue都指向string对象(当然不是同一个)。赋值动作该如何影响p.nameValuep呢?赋值之后p.nameValue应该指向s.nameValue所指向的那个string吗?也就是说reference自身可以被改动吗?如果是,那就可以开辟新天地,因为C++并不允许“让reference改指向不同对象”。换一个想法,p.nameValue所指的那个string对象 该被修改,进而影响“持有pointers或reference而且指向该string”的其他对象吗?也就是对象不被直接牵扯到赋值操作内?编译器生成copy assignment究竟该怎么做呢?
面对这个难题,C++的响应是拒绝编译那一行赋值动作。如果你打算在一个“内含reference成员”的class内支持赋值操作(assignment),你必须自己定义copy assinment操作符。如果某个base classes将copy assignment操作符声明为private,编译器将拒绝为其derived classes (派生类)生成一个copy assignment操作符。
请记住:
1、编译器可以暗自为class创建default析构函数、copy构造函数、copy assignment(拷贝赋值)操作符,以及析构函数。
条款06、若不想使用编译器自动生成的函数,就该明确拒绝
如果有些场景需要禁止copying动作,就要禁用用户使用copy构造函数和copy assignment操作符。但是如果你不声明copy构造函数或copy assignment操作符,编译器可能为你产出一份,于是你的class支持copying。如果你声明它们,你的class还是支持copying。但这里的目标却是要阻止copying!
答案的关键是,所有编译器产出的函数都是public。为阻止这些函数被创建出来,你需要自行声明它们,但这里并没有什么需求是你必须将它们声明为public。因此你可以将copy构造函数或copy assignment操作符声明为private。藉由明确声明一个成员函数,你阻止了编译器暗自创建其专属版本:而令这些函数为private,使你得以成功阻止人们调用它。
以下是一般做法:
这种做法并不绝对安全,因为成员函数和友元函数还是可以调用你的private函数。
class HomeForSale {
public:
...
private:
...
HomeForSale(const HomeForSale&);只有声明
HomeForSale& operator = (const HomeForSale&)
};
有了上述class定义,当客户企图拷贝HomeForSale对象,编译器会阻挠他。如果你不慎在成员函数或友元函数之内那么做,轮到链接器发出抱怨。
将链接期错误移至编译器是可能的,只要将copy构造函数和copy assignment操作符声明为private就可以办到,但不是在HomeForSale自身,而是在一个专门为了阻止copying动作而设计的base class内。这个base class非常简单:
class Uncopyable{
protected:
Uncopyable(){} //允许devived 对象构造和析构
~Uncopyable(){}
private:
Uncopyable(const Uncopyable&);//但阻止copying
Uncopyable & operator=(const Uncopyable&);
};
为求阻止HomeForSale对象被拷贝,我们唯一需要做的就是继承Uncopyable:
class HomeForSale:private Uncopyable//class 不再声明copy构造函数或copy assign. 操作符
{
...
};
请记住:
1、为驳回编译器自动(暗自)提供的机能,可将相应的成员函数声明为private并且不予实现。使用像Uncopyable也是一种做法。
条款07、为多态基类声明virtual析构函数
有许多种做法可以记录时间,因此,设计一个TimeKeeper base class和一些derived classed 作为不同的计时方法,相当合情合理:
class TimeKeeper{
public:
TimeKeeper();
~TimeKeeper();
...
};
class AtomicClock:public TimeKeeper{...};//原子钟
class WaterClock:public TimeKeeper{...};//水钟
class WristClock:public TimeKeeper{...};//腕表
许多客户只想在程序中使用时间,不想操心时间如何计算等细节,这时候我们可以设计factory(工厂)函数,返回指针指向一个计时对象。Factory函数会“返回一个base class指针,指向新生成之derived class 对象”:
TimeKeeper * getTimeKeeper();//返回一个指针,指向一个TimeKeeper派生类的动态分配对象。
为了遵守factory函数的规矩,被getTimeKeeper()返回的对象必须位于heap。因此为了避免泄露内存和其他资源,将factory函数返回的每一个对象适当地delete掉很重要:
TimeKeeper *ptk= getTimeKeeper();///从TimeKeeper继承体系获得一个动态分配对象。
... //运用它...
delete ptk;//释放它,避免资源浪费
依赖客户执行delete动作,基本上便带有某种错误倾向。
问题出在getTimeKeeper返回的指针指向一个derived class 对象,而那个对象却经由一个base class指针被删除,而目前的base class有个non-virtual析构函数。 C++指出当devired class对象经由一个base class指针被删除,而该base class带着一个non-virtual析构函数,其结果未有定义——实际执行时通常发生的是对象的derived成分没有被销毁。这属于“局部销毁”对象。会造成资源泄漏、败坏之数据结构、在调试器上浪费许多时间的绝佳途径。
消除这个问题的做法很简单:给base class一个简单virtual析构函数。此后删除derived class对象就会如你想要的那般。是的,它会销毁整个对象,包括所有的derived class成分:
class TimeKeeper{
public:
TimeKeeper();
virtual ~TimeKeeper();
...
};
TimeKeeper *ptk= getTimeKeeper();
... //运用它...
delete ptk;//现在,行为正确
像TimeKeeper 这样的base class除了析构函数之外通常还有其他virtual函数,因为virtual函数的目的不允许derived class的实现得以客制化。例如TimeKeeper就可能拥有一个virtual gerCurrentTime,它在不同的derived classes中有不同的实现码。任何class 只要带有virtual函数都几乎确定应该也有一个virtual 析构函数。
如果class 不含virtual 函数,通常表示它并不意图被用作一个base class .。当class 不企图被当作base class,令其析构函数为virtual往往是个馊主意。
只有当class内含至少一个virtual函数,才为它声明virtual析构函数。
class SpecialString:public std::string{//馊主意
...
};
如果你在程序某处将一个pointer-to-SpecialString转换成std::string ,然后将转换的那个string 指针delete掉,你立刻被流放到“行为不明确”的恶地上:
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声明一个pure virtual析构函数。下面是个例子:
class AWOV{
public:
virtual ~AWOV()=0;//声明pure virtual析构函数
};
这个class有个prue virtual函数,所以它是一个抽象class,又由于它有个virtual析构函数,所以你不需要担心析构函数的问题。然而,这里有个窍门:你必须为这个pure virtual析构函数提供一个定义:
AWOV::~AWOV(){ }//prue virtual析构函数的定义
析构函数的运作方式是,最深层派生的那个class其析构函数最先被调用,然后是其每一个base class的析构函数被调用。
请记住:
1、polymorphic(带多态性质的)base classes应该声明一个virtual析构函数。如果class带有任何virtual函数,它就应该拥有一个virtual析构函数。
2、Classes 的设计目的如果不是作为base classes 使用,或不是为了具备多态性(polymorphically ),就不该声明virtual 析构函数。
条款08、别让异常逃离析构函数
这就很容易理解,但如果你的析构函数必须执行一个动作,而该动作可能会在失败时抛出异常,该怎么办?举个例子,假设你一个class负责数据库连接:
class DBConnection{
public:
...
static DBConnection create();//这个函数返回DBConnection对象;
//为求简化暂略参数。
void close(); //关闭联机;失败则抛出异常
};
为了确保客户不忘记DBConnection 对象身上调用close(),一个合理的想法是创建一个用来管理DBConnection资源的class,并在其析构函数中调用close。这一类用于资源管理的class在第三章讨论,这里只要考虑它们的析构函数长相就够了:
class DBConn{//这个class 用来管理DBConnection对象
public:
...
DBConn(){
db.close();
}
private:
DBConnection db;
};
就便允许客户写出这样的代码:
{//开启一个区块(block)
DBConn dbc(DBConnection::create());
//建立DBConnection对象并
//交给DBConn对象以便管理。通过DBConn的接口使用DBConnection对象。
}//在区块结束点,DBConn对象被销毁,因而自动为DBConnection对象调用close
只要调用close成功,一切都美好。但是如果该调用导致异常,DBConn析构函数会传播该异常,也就是允许它离开这个析构函数。那就会造成问题,因为那就是抛出了难以驾驭的麻烦。
一个较佳策略是重新设计DBConn接口,使其客户有机会对可能出现的问题作出反应。例如DBConn自己可以提供一个close函数,因而赋予客户一个机会得以处理“因该操作而发生的异常”。DBConn也可以追踪其所管理之DBConnection是否已被关闭,并在答案为否的情况下由其析构函数关闭之。这可以防止遗失数据库连接。
然而如果DBConnection析构函数调用close失败,我们又将退回“强迫结束程序”或“吞下异常”的老路:
class DBConn{//这个class 用来管理DBConnection对象
public:
...
void close(){//供客户使用的新函数
db.close();
closed=true;
}
~DBConn(){
if(!closed){
try {//关闭连接(如果客户不那么做的话)
db.close();
} catch (...) {//如果关闭动作失败
制作运转记录,记下对close的调用失败;//记录下来并结束程序
...//或吞下异常
}
}
}
private:
DBConnection db;
bool closed;
};
本例要说明的是,由客户自己调用close并不会对他们带来负担,而是给他们一个处理错误的机会,否则他们没有机会响应。如果他们不认为这个机会有用(或许他们坚信不会有错误发生),可以忽略它,倚赖DBConn析构函数去调用close。如果真有错误发生——如果close的确抛出异常——而且DBConn吞下该异常或者结束程序,客户没有立场抱怨,毕竟他们曾有机会第一手处理问题,而他们选择放弃。
请记住:
1、析构函数绝对不要吐出异常。如果一个被析构函数调用的函数可能抛出异常,析构函数应该捕捉任何异常,然后吞下它们(不传播)或结束异常。
2、如果客户想要对某个操作函数运行期间抛出的异常做出反应,那么class应该提供一个普通函数(而非在析构函数中)执行改该操作。
条款09:绝不在构造函数和析构函数过程中调用virtual函数
假设你有一个继承体系,用来塑模股市交易如买进、卖出的订单等等。这样的交易一定要经过审计,所以每当创建一个交易对象,在审计日志中也需要创建一笔适当记录。下面是一个看起来颇为合理的做法:
class Transaction{//所有交易的base class
public:
Transaction();
virtual void logTransaction() const =0;//做出一份因类型不同而不同的日志记录
...
};
Transaction::Transaction(){//base class 构造函数之实现
...
logTransaction();//最后动作是志记这笔交易
}
class BuyTransaction:public Transaction(){//derived class
public:
virtual void logTransaction() const;//志记(log)此型交易
...
};
class SelfTransaction:public Transaction(){//derived class
public:
virtual void logTransaction() const;//志记(log)此型交易
...
};
现在,当以下这行被执行,会发生什么事情:
BuyTransaction b;
无疑地会有一个BuyTransaction构造函数被调用,但首先Transaction构造函数一定会更早被调用;是的,derived class对象内的base class成分会在derived class自身成分被构造之前先构造妥当。Transaction构造函数的最后一行调用virtual 函数logTransaction,这正是引发惊奇的起点。这时候调用的logTransaction是Transaction内的版本,不是BuyTransaction内的版本——即使目前即将建立的对象类型是BuyTransaction。是的,base class 构造期间virtual函数绝不会下降到derived class阶层。取而代之的是,对象的作为就像隶属base 类型一样。非正式的说法或者比较恰当:在base class构造期间,virtual 函数不是virtual函数。
确定你的构造函数和析构函数都没有调用virtual 函数,而他们调用的所有函数也都服从同一约束。
一种做法是class Transaction内将logTransaction函数改为non-virtual ,然后要求derived class构造函数传递必要的信息给Transaction构造函数,而后那个构造函数便可安全地调用non-virtual logTransaction。像这样:
class Transaction{//所有交易的base class
public:
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(){//derived class
public:
BuyTransaction(parameters):Transaction(parameters)){//将log信息传给base class 构造函数
...
}
...
private:
static std::string createLogString(parameters);
};
由于无法使用virtual函数从base classes向下调用,在构造期间,你可以藉由“令 derived classed 将必要的构造信息向上传递至base class构造函数”替换之而加以弥补
请记住:
1、在析构和构造函数期间不要调用virtual函数,因为这类调用从不下降至derived class(比起当前执行构造函数和析构函数的那层)
条款10:令operator= 返回一个reference to *this
关于赋值,有趣的是你可以把它们写成连锁形式:
int x,y ,z;
x=y=z=15 ;//赋值连锁形式
同样有趣的是,赋值采用右结合律,所以上述连锁赋值被解析为:
x=(y= (z= 15));
这里15先被赋值给z,然后其结果再次被赋值给y,然后其结果再被赋值给x。
为了实现“连锁赋值”,赋值操作符必须返回一个reference指向操作符的左侧实参。这是你为classes实现赋值操作符时应该遵循的协议:
class Widget{//返回类型是个reference,指向当前对象。
public:
...
Widget &operator=(const Widget& rhs){
...
return *this; //返回左侧对象
}
...
};
这个协议不仅适用于以上的标准赋值形式,也适用于所有赋值相关运算,例如:
class Widget{
public:
...
Widget &operator+=(const Widget& rhs){//这个协议适用于+= , -=,*=,等等
...
return *this;
}
Widget &operator=(int rhs){//此函数也适用,即使此一操作符的参数类型不符合协定
...
return *this;
}
...
};
这个协议被所有内置类型和标准库提供的类型如string,vector,complex,trl::shared_ptr或即将提供的类型共同遵守。
请记住:
令赋值(assignment)操作符返回一个reference to *this。
条款11、在operator= 中处理“自我赋值”
假设你建立一个class用来保存一个指针指向一块动态分配的位图(bitmap):
class Bitmap{ ... };
class Widget{
...
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 == &this) return *this;//证同测试,如果是自我赋值,就不做任何事情。
delete pb;//停止使用当前的bitmap,
pb=new Bitmap (*rhs.pb);//使用rhs's bitmap的副本(复件)。
return *this;
}
这个版本仍然存在异常方面的麻烦。更明确地说,如果“new Bitmap”导致异常(不论是因为分配时内存不足或者因为Bitmap的copy构造函数抛出异常),Widget最终会持有一个指针指向一块被删除的Bitmap。这样的指针有害。你无法安全地删除它们,甚至无法安全地读取它们。唯一能对它们做的安全事情是付出许多调试能量找出错误的起源。
许多人对“自我赋值”的处理态度是倾向于不管“异常安全性”。例如以下代码,我们只需要注意复制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(及其栖身的那个Widget)保持原状。即使没有证同测试,这段代码还是能够处理自我赋值,因为我们对原bitmap做了一份复件、删除原bitmap、然后指向新制造的那个复件。它或许不是处理“自我赋值”的最高效办法,但它行得通。
在operato=函数内手工排列语句(确保代码不但”异常安全“而且“自我赋值安全”)的一个替代方案是,使用所谓的copy and swap技术。这个技术和”异常安全性“有密切关系。然而由于它是一个常见而够好的operator=撰写办法,所以值得看看这种方法:
class Widget{
...
void swap(Widget& rhs);//交换*this 和rhs的数据
};
Widget &Widget::operator=(const Widget & rhs)//
{
Widget temp(rhs);//为rhs数据制作一份复件(副本)
swap(temp); //将*this 数据和上述复件的数据交换
return *this;
}
这个主题的另一个变形乃利用以下事实:(1)某class的copy assignment操作符可能被声明为” 以By value方式接受实参“;(2)以by value方式传递东西会造成一份复件/副本:
Widget &Widget::operator=( Widget rhs)//
{
//rhs是被传对象的一份复件(副本),注意这里是pass By value
swap(rhs); //将*this 数据和复件(副本)的数据交换
return *this;
}
请记住:
1、确保当对象自我赋值时operator = 有良好行为。其中技术包括比较“来源对象”和“目标对象”的地址、精心周到的语句顺序、以及copy-and-swap。
2、确定任何函数如果操作一个以上的对象,而其中多个对象是同一个对象时,其行为仍然正确。
条款12:复制对象时勿忘其每一个成分
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 constructor");
name=rhs.name;//复制rhs的数据
return *this;
}
class PriorityCustomer:public Customer{
public:
PriorityCustomer(const PriorityCustomer & rhs);
PriorityCustomer& operator=(const PriorityCustomer& rhs);
private:
int priority;
};
PriorityCustomer::PriorityCustomer(const PriorityCustomer & rhs)
:Customer (rhs),priority(rhs.priority)
{
logCall("PriorityCustomer copy constructor");
}
PriorityCustomer& PriorityCustomer::operator=(const PriorityCustomer &rhs){
logCall("PriorityCustomer copy assignment operator");
Customer::operator=(rhs);//对base class 成分进行赋值动作
priority =rhs.priority;
return *this;
}
PriorityCustomer是derived class,它的copying函数调用相应base class函数:
” Customer::operator=(rhs);//对base class 成分进行赋值动作“。
当你编写一个copying函数,请确保(1)复制所有local成员变量,(2)调用所有base classes内的适当的copying函数。
你不该令copy assignment操作符调用copy构造函数。反方向——令copy构造函数调用copy assignment操作符——同样无意义。构造函数用来初始化新对象,而assignment操作符只施行于已初始化对象身上。
如果你发现你的copy构造函数和copy assignment 操作符有相近的代码,消除重复代码的做法是,建立一个新的成员函数给两者调用。这样的函数往往是private而且常被命名为init。这个策略可以安全消除copying构造函数和copy assignment 操作符之间的代码重复。
请记住:
1、Copying 函数应该确保复制”对象内的所有成员变量“及”所有base class成分“
2、不要尝试以某个copying函数实现另一个copying函数。应该将共同机能放进第三个函数中,并由两个copying函数共同调用。
来源:Effective C++
仅供学习 ,侵删