上一部分Effective C++ --3 資源管理

?

18、讓接口容易被正確使用，不易被誤用

? （1）設計接口時要考慮客戶可能可能做出的錯誤輸入，如參數的形式等。

19、設計class猶如設計type

? （1）對象如何被創建和銷毀；對象的初始化和賦值的差別；如果被pass by value使用意味著什么；合法值；繼承圖系；轉換；操作符和函數的類型；什么標準函數設置為私有；什么是未聲明接口；有多么一般化；真的需要不需要新類型。

20、寧以pass-by-reference-to-const替換pass-by-value

? （1）這樣做更加高效，且能避免切割問題。

??（2）不適用于內置類型、stl迭代器和函數對象，此時pass-by-value效率更高。

21、必須返回對象時，別妄想返回其reference

? （1）絕不要返回指針或者引用指向一個局部存放在棧上的對象，或者返回引用指向一個隊分配的對象，或者返回一個指針或者引用指向局部靜態變量而有可能同時需要多個這樣的對象（reference永遠看到的是靜態量的現值）。

22、將成員變量聲明為private

? （1）protected 就和public一樣缺乏封裝性，此時如果成員變量被改變，都會有不可預知的大量代碼收到破壞。切忌將成員變量聲明為private。

23、寧以non-member、non-friend替換member函數

? （1）namespace和class不同，前者可以跨越多個源碼文件（在多文件中分段聲明）而后者必須整體定義，不能被分割為片片段段。

? （2）此種替換方法可以增加封裝性、包裹彈性和機能擴充性。封裝性越高，越少的人可見，就用于越大的彈性去改變，也具有較低的編譯相依度，增加可延展性。當多種函數都提供相同功能時，采用此規則。

24、若所有參數皆需類型轉換，請為此采用non-member函數

?（1）只有當參數列于參數列內，這個參數才是進行隱式類型轉換的合格參與者；而被調用之成員函數所隸屬的對象——this對象，不是隱式類型轉換的合格參與者，所以此時要采用non-member函數使兩者都處于參數位置。

25、考慮寫成一個不拋出異常的swap函數

?（1）通常不允許改變std命名空間中的任何東西，但可以全特化std內的templates，但不可與添加新的templates。

?（2）如果提供一個member swap，也該提供一個non-member swap來調用前者。對于class，也請特化std::swap。

?（3）調用swap時應針對std::swap使用using聲明式進行曝光，然后調用swap并且不帶任何“命名空間資格修飾”。此時編譯器首先找專屬swap，如果沒有就調用std內的swap。

總結

以上是生活随笔為你收集整理的Effective C++ --4 设计与声明的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。