The Blog of Nobody

Welcome! You are in the middle of nowhere. Windows Vista + Safari is recommended.
posts - 38, comments - 164, trackbacks - 0, articles - 0
  C++博客 :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理

【翻译】[Effective C++第三版•中文版][第15条]要为资源管理类提供对原始资源的访问权

Posted on 2007-05-13 20:54 ★ROY★ 阅读(509) 评论(0)  编辑 收藏 引用 所属分类: Effective C++

第15条：     要为资源管理类提供对原始资源的访问权

资源管理类的特征是振奋人心的。它构筑起可靠的屏障，有效地防止你的程序发生资源泄漏。对于一个系统的设计方案是否优异，能否预防这样的泄漏可作为一个基本评判标准。在完美的世界里，你可以依靠资源管理类来完成所有的与资源交互的工作，你永远也不能直接访问原始资源。然而世界并不是完美的。许多 API 会直接引用资源，所以除非你发誓不使用这样的 API （这样做显得太不实际了），否则，你必须绕过资源管理类，然后在需要的时候及时手工处理原始资源。

举例说，第 13 条中引入了下面的做法 ：使用诸如 auto_ptr 或者 tr1::shared_ptr 这样的智能指针来保存诸如 createInvestment 这样的工厂函数的返回值：

std::tr1::shared_ptr<Investment> pInv(createInvestment());

                                       // 来自第 13 条

假设，当你使用一个 Investment 对象时，你需要一个这样的函数：

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

你可能希望这样来调用它：

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

但是这段代码无法通过编译：因为 daysHeld 需要一个原始的 Investment* 指针，但是你传递给它的对象的类型却是 tr1::shared_ptr<Investment> 。

你需要一个渠道来 将一个 RAII 类的对 象（在上面的示例中是 tr1::shared_ptr ）转变为它所包含的原始资源（比如说，原始的 Investment* ）。这里实现这一转变有两个一般的方法：显式转换和隐式转换。

tr1::shared_ptr 和 auto_ptr 都提供了一个 get 成员函数来进行显式转换，也就是说，返回一个智能指针对象中的裸指针（的副本）：

int days = daysHeld(pInv.get());       // 工作正常，将 pInv 中的

                                       // 裸指针传递给 daysHeld

似乎所有的智能指针类，包括 tr1::shared_ptr 和 auto_ptr 等等，都会重载指针解析运算符（ operator-> 和 operator* ），这便使得对原始裸指针进行隐式转换成为现实：

class Investment {                 // 投资类型的层次结构中

                                   // 最为根基的部分

public:

  bool isTaxFree() const;

  ...

};

 

Investment* createInvestment();    // 工厂函数

 

std::tr1::shared_ptr<Investment> pi1(createInvestment());

                                   // 使用 tr1::shared_ptr

                                   // 管理资源

bool taxable1 = !(pi1->isTaxFree());

                                   // 通过 operator-> 访问资源

...

 

std::auto_ptr<Investment> pi2(createInvestment());

                                   // 使用 auto_ptr 管理资源

bool taxable2 = !((*pi2).isTaxFree());

                                   // 通过 operator* 访问资源

...

由于 某些时刻你需要获取一个 RAII 对象中的原始资源，所以一些 RAII 类的设计者使用了一个小手段来使系统正常运行，那就是：提供一个隐式转换函数。举例说，以下是一个 C 语言 API 中提供的处理字体的一个 RAII 类：

FontHandle getFont();              // 来自一个 C 语言 API

                                   // 省略参数表以简化代码

 

void releaseFont(FontHandle fh);   // 来自同一个 C 语言 API

 

class Font {                       // RAII 类

public:

  explicit Font(FontHandle fh)     // 通过传值获取资源

  : f(fh)                          // 因为这一 C 语言 API 这样做

  {}

 

  ~Font() { releaseFont(f); }      // 释放资源

 

private:

  FontHandle f;                        // 原始的字体资源

};

假设这里有一个大型的相关的 C 语言 API 仅仅通过 FontHandle 解决字体问题，那么将存在十分频繁的把 Font 对象转换为 FontHandle 的操作。 Font 类可以提供一个显式转换函数，比如 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

由于需要显式请求这样的转换，这样做显得得不偿失，一些程序员也许会拒绝使用这个类。然而这又增加了字体资源泄漏的可能性，这与 Font 类的设计初衷是完全相悖的。

有一个替代方案，让 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 ，然后复制它

现在程序中有一个 FontHandle 资源正在由 Font 对象 f1 来管理，但是仍然可以通过 f2 直接访问 FontHandle 资源。这是很糟糕的。比如说，当 f1 被销毁时，字体就会被释放， f2 也一样。

是 为 RAII 类提供显式转换为其原始资源的方法，还是允许隐式转换，上面两个问题的答案取决于 RAII 类设计用于完成的具体任务，及其被使用的具体环境。最好的设计方案应该遵循第 18 条 的建议，让接口更容易被正确使用，而不易被误用。通常情况下，定义一个类似于 get 的显式转换函数是一个较好的途径，应为它可以使非故意类型转换的可能性降至最低。然而，使用隐式类型转换显得更加自然，人们更趋向于使用它。

你可能已经发现，让一个函数返 回一个 RAII 类内部的原始资源是违背封装性原则的。的确是这样，但是它实际上并不像看上去那样糟糕。 RAII 类并不是用来封装什么的。它们是用来进行一些特别的操作的，那就是资源释放。如果需要，资源封装工作可以放在这一主要功能的最顶端，但是这并不是必需的。另外，一 些 RAII 类 结合了实现封装的严格性和原始资源封装的宽松性。比如 tr1::shared_ptr 对其引用计数机制进行了整体封装，但是它仍然为其所包含的裸指针提供了方便的访问方法。就像其它设计优秀的类一样，它隐藏了客户端程序员不需要关心的内容，但是它使得客户端程序员的确需要使用的部分对其可见。

牢记在心

l  API 通常需要访问原始资源，因此每个 RAII 类都应该提供一个途径来获取它所管理的资源。

l  访问可以通过显式转换或隐式转换来实现。一般情况下，显式转换更安全，但是隐式转换对于客户端程序员来说使用更方便。


标题  
姓名  
主页
验证码 *
内容(提交失败后,可以通过“恢复上次提交”恢复刚刚提交的内容)  
  登录  使用高级评论  新用户注册  返回页首  恢复上次提交      
[使用Ctrl+Enter键可以直接提交]
相关链接:
网站导航: