Effective C++ 学习笔记 条款15 在资源管理类中提供对原始资源的访问

资源管理类很棒。它们是你对抗资源泄露的堡垒。排除这样的泄漏是良好设计系统的根本性质。在一个完美的世界中你将倚赖这样的class来处理和资源之间的所有互动，而不是玷污双手直接处理原始资源（raw resources）。但这个世界并不完美。许多API直接指涉资源，所以除非你发誓（这其实是一种没有价值的举动）永不使用这样的API，否则只得绕过资源管理对象直接访问原始资源。

举个例子，条款13导入一个观念：使用智能指针如auto_ptr或tr1::shared_ptr保存factory函数如createInvestment的调用结果：

std::tr1::shared_ptr<Investment> pInv(createInvestment());    // 见条款13

假设你希望以某个函数处理Investment对象，像这样：

int daysHeld(const Investment *pi);    // 返回投资天数

你想要这么调用它：

int days = daysHeld(pInv);    // 错误！

却通不过编译，因为daysHelo需要的是Investment *指针，你传给它的却是个类型为tr1::shared_ptr<Investment>的对象。

这时候你需要一个函数可将RAII class对象（本例为tr1::shared_ptr）转换为其所内含的原始资源（本例为底部的Investment *）。有两个做法可以达成目标：显式转换和隐式转换。

tr1::shared_ptr和auto_ptr都提供一个get成员函数，用来执行显式转换，即它会返回智能指针内部的原始指针的副本：

int days = daysHeld(pInv.get());    // 将pInv内的原始指针传给daysHeld

就像几乎所有智能指针一样，tr1::shared_ptr和auto_ptr也重载了指针取值（pointer dereferencing）操作符（operator->和operator*），它们允许隐式转换至底部原始指针：

class Investment    // investment继承体系的根类
{
public:
    bool isTaxFree() const;
    // ...
};

Investment *createInvestment();    // factory函数
std::tr1::shared_ptr<Investment> pi1(createInvestment());    // 令tr1::shared_ptr管理一笔资源
bool taxable1 = !(pi1->isTaxFree());    // 经由operator->访问资源
// ...
std::auto_ptr<Investment> pi2(createInvestment());    // 令auto_ptr管理一笔资源
bool texable2 = !((*pi2).isTaxFree());    // 经由operator*访问资源
// ...

取得RAII对象内的原始资源时，某些RAII class设计者的做法是提供一个隐式转换函数。考虑下面这个用于字体的RAII class（对C API而言字体是一种原生数据结构）：

FontHandle getFont();    // 这是个C API，为简化省略参数

void releaseFont(FontHandle fh);    // 来自同一组C API

class Font    // RAII class
{
public:
    explicit Font(FontHandle fh) : f(fh)    // 获得资源，采用pass-by-value，因为C API这样做
    {
    }
    
    ~Font() 
    {
        releaseFont(f);    // 释放资源
    }

private:
    FontHandle f;    // 原始（raw）字体资源
};

假设有大量与字体相关的C API，它们处理的是FontHandle，那么“将Font对象转换为FontHandle”会是一种很频繁的需求。Font class可为此提供一个显式转换函数，像get那样：

class Font
{
public:
    // ...
    FontHandle get() const    // 显式转换函数
    {
        return f;
    }
    // ...
};

不幸的是这使得客户每当想要使用API时就必须调用get：

void changeFontSize(FontHandle f, int newSize);    // C API
Font f(getFont());
int newFontSize;
// ...
changeFontSize(f.get(), newFontSize);    // 显式将Font转换为FontHandle

某些程序员可能会认为，这样到处要求显式转换，让人倒尽胃口，不愿再使用这个class，从而增加了泄露字体的可能性，而Font clsss的主要设计目的就是为了防止资源（字体）泄漏。

另一个办法是令Font提供隐式转换函数，转型为FontHandle：

class Font
{
public:
    // ...
    operator FontHandle() const    // 隐式转换函数
    {
        return f;
    }
    // ...
};

这使得客户调用C API时比较轻松且自然：

Font f(getFont());
int newFontSize;
// ...
changeFontSize(f, newFontSize);    // 将Font隐式转换为FontHandle

但是这个隐式转换会增加错误发生机会。例如客户可能会在需要Font时意外创建一个FontHandle：

Font f1(getFont());
// ...
FontHandle f2 = f1;    // 原意是要拷贝一个Font对象，却反而将f1隐式转换为其底部的FontHandle，然后才复制它
// 此处感觉有点问题，假设管理的资源是int，资源管理类是ResourceManage
// 那么我在需要一个int时不会写int i = ResourceManageObj的
// 只会在有隐式转换时获取资源管理类管理的资源副本时这样写
// 但如果此时f1被销毁，其中保存的资源被回收，则f2是否有效取决于f1中保存的资源的性质
// 如果被保存的资源复制时需要深拷贝，则f1回收资源时会把深拷贝的内容回收，导致f1中指向深拷贝资源的指针失效
// 如果f1保存的资源在复制时都是浅拷贝，如int、不需深拷贝的class，则f2还是有效的

以上程序有个FontHandle由Font对象f1管理，但那个FontHandle也可通过直接使用f2取得。那几乎不会有好下场，例如当f1被销毁，字体被释放，而f2因此成为“虚吊的”（dangle）。

是否该提供一个显式转换函数（例如get成员函数）将RAII class转换为其底部资源，或是应该提供隐式转换，答案主要取决于RAII class被设计执行的特定工作，以及它被使用的情况。最佳设计很可能是坚持条款18的忠告：“让接口容易被正确使用，不易被误用”。通常显式转换函数如get是比较受欢迎的路子，因为它将“非故意的类型转换”的可能性最小化了。然而有时候，隐式类型转换所带来的“自然用法”也会引发天平倾斜。

你可能认为，RAII class内的那个返回原始资源的函数，与“封装”发生矛盾。这是真的，但一般而言它谈不上是什么设计灾难。RAII class并不是为了封装某物而存在；它们的存在是为了确保一个特殊行为——资源释放——会发生。如果一定要，当然也可以在这基本功能之上再加上封装资源功能，但那并非必要。此外也有某些RAII class使用松散的底层资源封装来实现，例如tr1::shared_ptr将它的所有引用计数机构封装了起来，但还是让外界很容易访问其所含的原始指针。就像多数设计良好的class一样，它隐藏了客户不需要看的部分，但备妥客户需要的所有东西。

请记住：
1.API往往要求访问原始资源，所以每一个RAII class应该提供一个“取得其所管理之资源”的办法。

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