1.为什么需要访问资源管理类中的原生资源
资源管理类是很奇妙的。它们是防止资源泄漏的堡垒，没有资源泄漏发生是设计良好的系统的一个基本特征。在一个完美的世界中，你需要依赖这样的类来同资源进行交互，绝不要直接访问原生（raw）资源而玷污你的双手。但是世界不是完美的，许多API会直接引用资源，所以除非你放弃使用这样的API（这是不实际的想法），你将会绕开资源管理类而时不时的处理原生资源。
2. 如何获取原生资源——通过显示转换和隐式转换
2.1 一个例子
举个例子，Item 13中介绍了使用像auto_ptr或者tr1::shared_ptr这样的智能指针来存放调用createInvestment工厂函数的返回结果:
std::tr1::shared_ptr<Investment> pInv(createInvestment()); // from Item 13
假设你想使用一个同Investment对象一起工作的函数，如下：
int daysHeld(const Investment *pi); // return number of days // investment has been held
你会像下面这样调用它：
int days = daysHeld(pInv); // error!
代码将不能通过编译：dayHeld想要使用一个原生Investment*指针，你却传递了一个tr1::shared_ptr<Investment>类型的对象。
你需要一种方法将一个RAII类对象（在这个例子中是tr1::shared_ptr）转换成它所包含的原生资源类型。有两种常见的方法来实现它：显示转换和隐式转换。
2.2 使用智能指针的get进行显示转换
Tr1::shared_ptr和auto_ptr都提供了一个get成员函数来执行显示转换，也就是返回智能指针对象内部的原生指针：
int days = daysHeld(pInv.get()); // fine, passes the raw pointer // in pInv to daysHeld
2.3 使用智能指针的解引用进行隐式转换
事实上像所有的智能指针一样，tr1::shared_ptr和auto_ptr也重载了指针的解引用运算符（operator->和operator*）,这就允许将其隐式的转换成底层原生指针：
class Investment { // root class for a hierarchy
public: // of investment types
bool isTaxFree() const;
...
};
Investment* createInvestment(); // factory function
std::tr1::shared_ptr<Investment> // have tr1::shared_ptr
pi1(createInvestment()); // manage a resource
bool taxable1 = !(pi1->isTaxFree()); // access resource
// via operator->
...
std::auto_ptr<Investment> pi2(createInvestment()); // have auto_ptr
// manage a
// resource
bool taxable2 = !((*pi2).isTaxFree()); // access resource
// via operator*
2.3 自己实现get进行显示转换
因为有时候获取RAII对象中的原生资源是必要的，一些RAII类的设计者通过提供一个隐式转换函数来顺利达到此目的。举个例子，考虑下面的字体RAII类，字体对于C API来说是原生数据结构：
FontHandle getFont(); // from C API — params omitted
// for simplicity
void releaseFont(FontHandle fh); // from the same C API
class Font { // RAII class
public:
explicit Font(FontHandle fh) // acquire resource;
: f(fh) // use pass-by-value, because the
{} // C API does
~Font() { releaseFont(f ); } // release resource
... // handle copying (see Item 14)
private:
FontHandle f; // the raw font resource
};
假设有大量的字体相关的C API用于处理FontHandles,因此会有频繁的需求将Font对象转换成FontHandles对象。Font类可以提供一个显示的转换函数，比如说：get:
class Font {
public:
...
FontHandle get() const { return f; } // explicit conversion function
...
};
不幸的是，如果它们想同API进行通讯，每次都需要调用get函数：
void changeFontSize(FontHandle f, int newSize); // from the C API Font f(getFont()); int newFontSize; ... changeFontSize(f.get(), newFontSize); // explicitly convert // Font to FontHandle
一些程序员发现显示请求这些转换是如此令人不愉快以至于不想使用RAII类。但是这会增加泄漏字体资源的机会，这正是设计Font类要预防的事情。
2.3 自己实现operator() 进行隐式转换
一种替代的方法是让Font提供一个隐式转换到FontHandle的函数：
class Font {
public:
...
operator FontHandle() const // implicit conversion function
{ return f; }
...
};
这会使C API的调用变得容易并且很自然：
Font f(getFont()); int newFontSize; ... changeFontSize(f, newFontSize); // implicitly convert Font // to FontHandle
缺点是隐式转换增加了出错的机会。举个例子，客户端本来想要一个Font却创建了一个FontHandle：
Font f1(getFont()); ... FontHandle f2 = f1; // oops! meant to copy a Font // object, but instead implicitly // converted f1 into its underlying // FontHandle, then copied that
现在程序拥有一个被Font对象 f1管理的FontHandle，但是直接使用f2也可以获得这个FontHandle。这就不好了。例如：当f1被销毁，字体资源被释放，f2就变成了悬挂指针。
3.隐式转换和显示转换如何选择？
提供从RAII类对象到底层资源的显示转换（通过一个get成员函数）还是提供隐式转换依赖于设计出来的RAII类需要执行的特殊任务以及使用的场景。最好的设计看上去要遵守Item 18的建议：使接口容易被正确使用，很难被误用。通常情况下，像get一样的显示转换函数会是更好的选择，因为它减少了类型误转换的机会。然而有时候，使用隐式类型转换的自然特性会使局面发生扭转。
4.访问原生资源和封装背道而驰？
函数返回一个RAII类中的原生资源同封装是背道而驰的，这已经发生了。这不是设计的灾难，RAII类的存在不是用来封装一些东西；他们的存在是用来保证资源的释放会发生。如果需要，资源封装可以在这个基本功能之上进行实现，但这不是必要的。此外，一些RAII类将实现的真正封装同底层资源非常松散的封装组合到一块。举个例子：tr1::shared_ptr封装了所有的引用计数，但是仍然可以非常容易的访问它所包含的原生指针。像一些设计良好的类，它隐藏了客户没有必要看到的东西，但是它提供了客户端确实需要访问的东西。
5.总结
- API通常需要访问原生资源，所以每个RAII类应该提供一个获得它所管理的原生资源的方法。
- 访问原生资源可以通过显式转换或者隐式转换来达到。一般情况下，显示转换更加安全，隐式转换对客户端来说更加方便。