《Effective C++》读书笔记 3.资源管理

资源管理

条款13:以对象管理资源

把资源放进对象内，我们便可倚赖C++的析构函数自动调用机制确保资源被释放

现考虑有个f函数

void f()
{
	Investment* pInv=createInvestment();
	...
	delete pInv;
}

这看起来妥当，但若干情况下f可能无法删除它取得自createInvestment的投资对象-------或许是因为“…”区域内的一个过早的return语句。就算谨慎编写程序防止这类错误也无法保证后来的维护者能做到有效的资源管理。

RAII：Resource Acuisition Is Initialization
“以对象管理资源”的观念常被称为“资源取得时机便是初始化时机”

为了防止资源泄漏，请使用RAII对象，它们在构造函数中获得资源并在析构函数中释放资源

两个常被使用的RAII class分别是tr1::shared_ptr和auto_ptr。前者通常是较佳选择，因为其copy行为比较直观。若选择auto_ptr，复制动作会使它（被复制物）指向null

auto_ptr：copy构造和copy assigment操作符会导致被复制的那个auto_ptr资源变为null

shared_ptr：引用计数的智能指针，但是无法打破环状引用

void f()
{
	...
	std::tr1::shared_ptr<Investment>
	pInv(createInvestment());
	...
}//经由shared_ptr析构函数自动删除pInv

两种智能指针析构函数做的都是delete不是delete[]

定义类外的函数返回raw pointer，是一个不好的行为，调用者极易忘记delete

---

条款14:在资源管理类中小心copying行为

偶尔需要自己建立资源管理类
比如我们使用C API函数处理类型为Mutex的互斥器对象，我们想要做的释放动作是解除锁定而非删除

复制RAII对象必须一并复制它所管理的资源，所以资源的copying行为决定RAII对象的copying行为

普遍而常见的RAII class copying行为是：抑制copying、施行引用计数法。不过其他行为也可能被实现

对于非heap-based的资源，auto_ptr和shared_ptr不适合作为资源的掌管者

当一个RAII对象被复制，导致内部资源的不确定性，防止资源被复制的两种方法：禁止复制；使用引用计数法

如果无论如何需要复制资源，注意：复制底部资源（深拷贝）

---

条款15：在资源管理类中提供对原始资源的访问

APIs往往要求访问原始资源，所以每一个RAII class应提供一个“取得其所管理的资源”的方法

对原始资源的访问可能经由显式转换或隐式转换。一般而言显式转换比较安全，但隐式转换对客户比较方便

shared_ptr和auto_ptr提供一个get成员函数，用来执行显式转换，也就是会返回智能指针内部的原始指针（的复件）

shared_ptr和auto_ptr也重载了指针取值操作符，允许隐式转换至底部原始指针（注意，隐式转换会增加错误发生机会）

是否该提供显式转换函数将RAII class转换为底部资源，或是应该提供隐式转换，主要取决于RAII class被设计执行的特定工作以及被使用的情况

---

条款16：成对使用new和delete时要采用相同形式

new操作：分配内存；针对此内存会有一个（或多个）构造函数被调用

delete操作：针对此内存会有一个（或多个）析构函数被调用，然后内存被释放

如果对new采用delete[]，delete对读取若干内存并将它解释为”数组大小“，然后多次调用析构函数

---

条款17：以独立语句将newed对象置入智能指针

以独立语句将newed对象存储于（置入）智能指针内。

如果不这样做，一旦异常被抛出，有可能导致难以察觉的资源泄漏

int priority();
void processWidget(std::tr1::shared_ptr<Widget>pw,int priority);
//现考虑调用processWidget:
processWidget(std::tr1::shared_ptr<Widget>(new Widget),priority());

对于同一条语句，如果行为上没存在必然的顺序性，则编译器执行的次序不是固定的。有可能导致”资源被创建“和”资源被转换为资源管理对象“两个时间点之间发生异常干扰，导致资源被创建，然后指针遗失，从而产生泄露