provide access to raw resources in resources-managing classes
資源管理類(resource-managing classes)很棒.它們是對抗資源洩露的堡壘.在乙個良好的環境中將依賴這樣的classes來處理和資源之間的所有互動.而不是直接處理原始資源,但這個環境並不完美,許多api直接涉及資源,因此有時只能繞過資源管理物件直接訪問原始資源(raw resources).
例如,條款13匯入乙個觀念:使用智慧型指標如auto_ptr或tr1::shared_ptr儲存factory函式如createinvestment的呼叫結果:
std::tr1::shared_ptrpinv(createinvestment());int daysheld(const investment* pi); // 返回投資天數int days = daysheld(pinv); // 錯誤這時候需要乙個函式將raii class 物件(本例為tr1::shared_ptr)轉換為其所含的原始資源(本例為底部的investment*).有兩個做法可以達成目標:顯式轉換和隱式轉換.
tr1::shared_ptr和auto_ptr都提供乙個get成員函式,用來執行顯式轉換,即它會返回智慧型指標內部的原始指標(的副本):
int days = daysheld(pinv.get()); // 將pinv內的原始指標傳給daysheld注意:
api往往要求訪問原始資源(raw resources),所以每乙個raii class 都應該提供乙個"取得其所管理的資源"的辦法.
對原始資源的訪問可能經由顯式轉換或隱式轉換.一般而言顯式轉換比較安全,但隱式轉換對客戶比較方面.
Effective C 條款8 第2章
prevent exception from leving destructors.c 並不禁止析構函式吐出異常,但它不鼓勵這樣做.這是有原因的,考慮以下 class widget 假設這個可能吐出乙個異常 void dosomething v在這裡被自動銷毀當vector v被銷毀,它有責任銷毀其...
Effective C 條款23 第4章
prefer non member non friend functions to member functions 想象有個 class 用來表示網頁瀏覽器,這樣的 class 可能提供眾多函式,如下所示 class webbrowser 許多使用者會想一整個執行所有這些動作,因此webbrows...
Effective C 條款24 第4章
令 class 支援隱式型別轉換通常是個糟糕的主意,當然這條規則有其例外,最常見的例外是在建立數值型別時.假設設計乙個 class 用來表現有理數,允許整數 隱式轉換 為有理數似乎頗為合理.的確,它並不比c 內建從 int 至 double 的轉換來得不合理.假設這樣開始rational class...