C 箴言：在资源管理类中准备访问裸资源

　　资源管理类真是太棒了。他们是您防御资源泄漏的防波堤，没有这样的泄漏是设计良好的系统的基本特征。在一个完美的世界中，您能够在任何和资源的交互中依赖这样的类，从来无需因为直接访问裸资源（raw resources）而玷污您的手。但是这个世界并不完美，很多 API 直接涉及资源，所以除非您计划坚决放弃使用这样的 API（这种事很少会成为实际），否则，您就要经常绕过资源管理类而直接处理裸资源（raw resources）。

　　例如，以前介绍的使用类似 auto_ptr 或 tr1::shared_ptr 这样的智能指针来持有调用类似 createInvestment 这样的 factory 函数的结果： std::tr1::shared_ptr<Investment> pInv(createInvestment());

　　假设您打算使用的一个和 Investment 对象一起工作的函数是这样的：

int daysHeld(const Investment *pi); // return number of days
// investment has been held

　　您打算像这样调用他，

int days = daysHeld(pInv); // error!

　　但是这代码不能编译：daysHeld 需要一个裸的 Investment* 指针，但是您传给他一个类型为 tr1::shared_ptr<Investment> 的对象。

　　您需要一个将 RAII 类（当前情况下是 tr1::shared_ptr）的对象转化为他所包含的裸资源（例如，底层的 Investment*）的方法。有两个常规方法来做这件事。显式转换和隐式转换。

　　tr1::shared_ptr 和 auto_ptr 都提供一个 get 成员函数进行显示转换，也就是说，返回一个智能指针对象内部的裸指针（raw pointer）（或他的一个副本）：

int days = daysHeld(pInv.get()); // fine, passes the raw pointer
// in pInv to daysHeld

　　就像实际上的任何智能指针类相同，tr1::shared_ptr 和 auto_ptr 也都重载了指针解引用操作符（pointer dereferencing operators）（operator-> 和 operator*），而这样就允许隐式转换到底层的裸指针（raw pointers）：

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*

...

　　因为有些时候有必要取得 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

　private:
　　FontHandle f; // the raw font resource
};

　　假设有一个巨大的和字体有关的 C API 只能和 FontHandle 打交道，这就需要频繁地将 Font 对象转换为 FontHandle。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

　　一些程式员可能发现对显式请求这个转换的需求足以令人郁闷而避免使用这个类。反过来，设计 Font 类又是为了预防泄漏字体资源的机会的增长。

　　可选择的办法是为 Font 提供一个隐式转换到他的 FontHandle 的转换函数：

class Font {
　public:
　　...
　　operator FontHandle() const { return f; } // implicit conversion function
　　...
};

　　这样就能够使对 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，但是这个 FontHandle 也能通过直接使用 f2 来加以利用。这几乎绝对不会成为什么好事。例如，当 f1 被销毁，字体将被释放，f2 则被悬挂（dangle）。

　　关于是否提供从一个 RAII 类到他的底层资源的显式转换（例如，通过一个 get 成员函数）或允许隐式转换的决定，要依靠 RAII 类被设计履行的具体任务和他被计划使用的细节而做出。最好的设计很可能就是坚持 Item 18 的建议（使接口易于正确使用，而难以错误使用）的那一个。通常，类似 get 的一个显式转换函数是更可取的方式，因为他将意外的类型转换的机会减到最少。偶尔的，通过隐式类型转换提高使用的自然性将使天平向那个方向倾斜。

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有