Item 15: 在資源管理類中準備訪問裸資源（raw resources） · Effective C++

# Item 15: 在資源管理類中準備訪問裸資源（raw resources）作者：Scott Meyers 譯者：fatalerror99 (iTePub's Nirvana) 發布：http://blog.csdn.net/fatalerror99/ 資源管理類真是太棒了。他們是你防御資源泄漏的防波堤，沒有這樣的泄漏是設計良好的系統的基本特征。在一個完美的世界中，你可以在所有與資源的交互中依賴這樣的類，從來不需要因為直接訪問裸資源（raw resources）而玷污你的手。但是這個世界并不完美，很多 API 直接涉及資源，所以除非你計劃堅決放棄使用這樣的 API（這種事很少會成為實際），否則，你就要經常繞過資源管理類而直接處理裸資源（raw resources）。例如，Item 13 介紹的使用類似 auto_ptr 或 tr1::shared_ptr 這樣的智能指針來持有調用類似 createInvestment 這樣的 factory 函數的結果： ``` 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! ``` 但是這代碼不能編譯：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 的一個顯式轉換函數是更可取的方式，因為它將意外的類型轉換的機會減到最少。偶爾的，通過隱式類型轉換提高使用的自然性將使天平向那個方向傾斜。你可能已經意識到，函數返回一個 RAII 類內部的裸資源破壞了封裝。這是正確的，但這并非像它開始看上去那樣是個設計的禍患。RAII 類的存在并非為了封裝什么東西；它的存在是為了確保一個特殊的動作——資源釋放——的發生。如果你希望，封裝資源的地位也可以提高到這個主要功能之上，但這并非必需。此外，一些 RAII 類將實現的真正封裝和底層資源的非常寬松的封裝結合在一起。例如，tr1::shared_ptr 封裝了它的引用計數的全部機制，但它依然提供對它所包含的資源的簡單訪問。就像大多數設計良好的類，它隱藏了客戶不需要看到的，但它也讓客戶的確需要訪問的那些東西可以利用。 Things to Remember * API 經常需要訪問裸資源，所以每一個 RAII 類都應該提供取得它所管理的資源的方法。 * 訪問可以通過顯式轉換或者隱式轉換進行。通常，顯式轉換更安全，而隱式轉換對客戶來說更方便。