[轉]http://m.shnenglu.com/tiandejian/archive/2007/09/13/ec_27.html
第27條： 盡量不要使用類型轉換
C++ 的設計初衷之一就是：確保代碼遠離類型錯誤。從理論上來講，如果你的程序順利地通過了編譯，那么它就不會對任何對象嘗試去做任何不安全或無意義的操作。這是一項非常有價值的保證。你不應該輕易放棄它。
然而遺憾的是，轉型擾亂了原本井然有序的類型系統。它可以帶來無窮無盡的問題，一些是顯而易見的，但另一些則是極難察覺的。如果你是一名從 C 、 Java 或者 C# 轉向 C++ 的程序員的話，那么請注意了，因為相對 C++ 而言，轉型在這些語言中更加重要，而且帶來的危險也小得多。但是 C++ 不是 C ，也不是 Java 、 C# 。在 C++ 中，轉型是需要你格外注意的議題。
讓我們從復習轉型的語法開始，因為實現轉型有三種不同但是等價的方式。 C 風格的轉型是這樣的：
函數風格的轉型如下：
T( 表達式 ) // 將表達式轉型為 T 類型的
兩者之間在含義上沒有任何的區別。這僅僅是你把括號放在哪兒的問題。我把這兩種形式稱為“懷舊風格的轉型”。
C++ 還提供了四種新的轉型的形式（通常稱為“現代風格”或“ C++ 風格”的轉型）：
const_cast< T>( 表達式 )
dynamic_cast< T>( 表達式 )
reinterpret_cast< T>( 表達式 )
static_cast< T>( 表達式 )
四者各司其職：
l const_cast 通常用來脫去對象的恒定性。 C++ 風格轉型中只有它能做到這一點。
l dynamic_cast 主要用于進行“安全的向下轉型”，也就是說，它可以決定一個對象的類型是否屬于某一個特定的類型繼承層次結構中。它是唯一一種懷舊風格語法所無法替代的轉型。它也是唯一一種可能會帶來顯著運行時開銷的轉型。（稍候會具體講解。）
l reinterpret_cast 是為底層轉型而特別設置的，這類轉型可能會依賴于實現方式，比如說，將一個指針轉型為一個 int 值。除了底層代碼以外，要格外注意避免這類轉型。此類轉型在這本書中我只用過一次，而也是在討論如何編寫一個針對未分配內存的調試分配器（參見第 50 條）用到。
l static_cast 可以用于強制隱式轉換（比如說，將一個非 const 的對象轉換為 const 對象（就像第 3 條中的一樣）， int 轉換為 double ，等等）。它可以用于大多數這類轉換的逆操作（比如說， void* 指針轉換為包含類型的指針，指向基類的指針轉換為指向繼承類的指針），但是它不能進行從 const 到非 const 對象的轉型。（只有 const_cast 可以。）
懷舊風格的轉型在 C++ 中仍然是合法的，但是這里更推薦使用新形式。首先，它們在代碼中更加易于辨認（不僅對人，而且對 grep 這樣的工具也是如此），對于那些類型系統亂成一團的代碼，這樣做可以減少我們為類型頭疼的時間。其次，對每次轉型的目的更加細化，使得編譯器主動診斷用法錯誤成為可能。比如說，如果你嘗試通過轉型脫去恒定性的話，你只能使用 const_cast ， 如果你嘗試使用其它現代風格的轉型，你的代碼就不會通過編譯。
需要使用懷舊風格轉型的唯一一個地方就是：調用一 個 explicit 的構造函數來為一個函數傳遞一個對象。比如：
class Widget {
public:
explicit Widget(int size);
...
};
void doSomeWork(const Widget& w);
doSomeWork(Widget(15)); // 使用函數風格轉型
// 創建一個 int 的 Widget
doSomeWork(static_cast<Widget>(15)); // 使用 C++ 風格轉型
// 創建一個 int 的 Widget
出于某些原因，手動創建一個對象“感覺上”并不類似于一次轉型，所以在這種情況下應更趨向于使用函數風格的 轉型而不是 static_cast 。同時，當你寫下的代碼可能會導致 core dump[1] 時，你仍然會感覺你有充足的理由那樣做，因此你可能要忽略你的直覺，自始至終使用現代風格的轉型。
許多程序員相信轉型只是告訴編譯器將一個類型作為另一種來對待，僅此而已，但殊不知任何種類的類型轉換（無論是顯式的還是通過編譯器隱式進行的）通常會在運行時引入一些新的需要執行的代碼。比如說，再下面的代碼片斷中：
int x, y;
...
double d = static_cast<double>(x)/y; // x 除以 y ，用浮點數保存商值
int x 向 double 的轉型幾乎一定要引入新的代碼，因為在絕大多數架構中， int 與 double 的底層表示模式是不同的。這并不那么令人吃驚，但是下面的示例也許會讓你的眼界更加開闊些：
class Base { ... };
class Derived: public Base { ... };
Derived d;
Base *pb = &d; // 隱式轉換： Derived* => base*
這里我們創建了一基類的指針，并讓其指向了一個派生類的對象，但是某些時候，這兩個指針值并不會保持一致。如果真的這樣了，系統會為 Derived* 指針應用一個偏移值來取得正確的 Base* 指針的值。
最近的一個實例顯示了一個單獨的對象（比如一個 Derived 的對象）可能會擁有一個以上的地址（比如，一個 Base* 指針指向它的地址和一個 Derived* 指針指向它的地址）。這件事在 C 語言中是絕不會發生的。同樣在 Java 或 C# 中均不會發生。但在 C++ 中的的確確的發生了。實際上，在使用多重繼承時這件事是必然的，但在單繼承環境下也有可能發生。這意味著你應該避免去假設或推定 C++ 放置對象的方式，同時你應該避免基于這樣的假設來進行轉型。比如，如果你將對象地址轉型為 char* 指針，然后再對其進行指針運算，通常都會使程序陷入無法預知的行為。
但是請注意，我說過“某些時候”才需要引入偏移值。對象放置的方法、它們的地址的計算方法都是因編譯器而異的。這就意味著，僅僅由于你“知道對象如何放置”，你對在某一個平臺上轉型的做法可能充滿信心，但它在另一些平臺上卻是一錢不值。世界上有許多程序員為此付出了慘痛的代價。
關于轉型的一件有趣事情是：你很容易編寫一些 “看上去正確”的東西，但實際上它們是錯誤的。舉例說，許多應用程序框架需要在派生類中實現一個虛擬成員函數，并首先讓這些函數去調用基類中對應的函數。假設我們有一個 Window 基類和一個 SpecialWindow 派生類，兩者都定義了虛函數 onResize 。繼續假設： SpecialWindow 的 onResize 首先會調用 Window 的 onResize 。以下是實現方法，它乍看上去是正確的，其實不然：
class Window { // 基類
public:
virtual void onResize() { ... } // 基類 onResize 的實現
...
};
class SpecialWindow: public Window { // 派生類
public:
virtual void onResize() { // 派生類 onResize 的實現
static_cast<Window>(*this).onResize(); // 將 *this 轉型為 Window ，
// 然后調用它的 onResize ，
// 這樣不會正常工作！
... // 完成 SpecialWindow 獨有的任務
}
...
};
上面代碼中的轉型操作已經用黑體字標出。（這是一個現代風格的轉型，但是如果使用懷舊風格的話也不會帶來任何影響。）如果一切如你所愿，代碼將會 將 *this 轉型為一個 Window ，同時此過程帶來一次 onResize 的調用，將會是 Window::onResize 。你一定沒有想到，當前對象并沒有調用這一函數。取而代之的是，轉型過程創建了一個新的， *this 中基類部分的一個臨時副本，然后調用這一副本的 onResize 。上面的代碼將不會調用當前對象的 Window::onResize ，然后進行對象中的具體到 SpecialWindow 的動作；而是再對當前對象進行 SpecialWindow 行為之前，去調用當前對象的基類部分的副本中的 Window::onResize 。如果 Window::onResize 希望修改當前對象（這也不是完全不可行，因為 onResize 是一個非 const 的成員函數），實際上當前對象不會受到任何影響。取而代之的是，這一對象的那個副本將會被修改。然而，如果 SpecialWindow::onResize 希望修改當前對象，當前對象將會被修改，這將導致下面的情景：代碼將會使當前對象處于病態之中——它基類部分的修改沒有進行，而派生類部分的修改卻完成了。
解決方案就是：避免轉型。轉而使用你真正需要的類型。你并不希望欺騙編譯器將一個 *this 識別為一個基類對象；你需要做的是：對當前對象調用 onResize 的基類版本。所以你應該這樣編寫：
class SpecialWindow: public Window {
public:
virtual void onResize() {
Window::onResize(); // 對 *this 調用 Window::onResize
...
}
...
};
這個示例同時告訴我們：如果你需要進行轉型，上面的代碼就會發出警告：你可能正在以錯誤的方式工作。尤其是 dynamic_cast 。
在深入探究 dynamic_cast 的實現設計方式之前，有必要先了解一下大多數 dynamic_cast 的實現運行的速度是非常緩慢的。比如說，至少有一種通用實現是通過比較各個類名的字符串。如果你正在針對一個四層深的單一繼承層次結構中的一個對象進行 dynamic_cast ，那么這種實現方式下，每一次 dynamic_cast 都會占用四次調用 strcmp 的時間用于比較類名。顯然地，更深的或者使用多重繼承的層次結構的開銷將會更為顯著。一些實現以這種方式運行也是有它的根據的（它們這樣做是為了支持動態鏈接）。在對性能要求較高的代碼中，要在整體上時刻對轉型持謹慎的態度，你應該特別謹慎地使用 dynamic_cast 。
一般說來，在你期望對那些你確認屬于派生類的對象進行派生類操作，但此時你只有一個指針或者一個指向基類的引用能操作這一對象， dynamic_cast 將派上用場。一般有兩條途徑來避免這一問題。
首先，可以使用容器來保存直接指向派生類對象的指針（通常是指能指針，參見第 13 條），這樣就在對這些對象進行操作時就無需通過基類接口。比如說，在我們的 Window/SpecialWindow 層次結構中，如果只有 SpecialWindow 支持閃爍效果，我們也許可以這樣做：
class Window { ... };
class SpecialWindow: public Window {
public:
void blink();
...
};
typedef std::vector<std::tr1::shared_ptr<Window> > VPW;
// 關于 tr1::shared_ptr 的信息請參見第 13 條
VPW winPtrs;
...
for (VPW::iterator iter = winPtrs.begin(); // 不好的代碼。
iter != winPtrs.end(); // 使用 dynamic_cast
++iter) {
if (SpecialWindow *psw = dynamic_cast<SpecialWindow*>(iter->get()))
psw->blink();
}
但是有更好的解決方案：
typedef std::vector<std::tr1::shared_ptr<SpecialWindow> > VPSW;
VPSW winPtrs;
...
for (VPSW::iterator iter = winPtrs.begin();// 更好的代碼
iter != winPtrs.end(); // 無需 dynamic_cast
++iter)
(*iter)->blink();
當然，在使用這一方案時，在同一容器中放置 的 Window 派生對象的類型是受到限制的。為了使用更多的 Window 類型，你可能需要多個類型安全的容器。
一個可行的替代方案是：在基類中提供虛函數，然后按需配置。這樣對于所有可能的 Window 派生類型，你都可以通過基類接口來進行操作了。比如說，盡管只有 SpecialWindow 可以閃爍，但是在基類中聲明這一函數也是有意義的，可以提供一個默認的實現，但不去做任何事情：
class Window {
public:
virtual void blink() {} // 默認實現不做任何事情；
... // 第 34 條將介紹：
}; // 提供默認實現可能是個壞主意
class SpecialWindow: public Window {
public:
virtual void blink() { ... }; // 在這一類型中
... // blink 函數會做一些事情
};
typedef std::vector<std::tr1::shared_ptr<Window> > VPW;
VPW winPtrs; // 容器中保存著（指向）
... // 所有可能的 Window 類型
for (VPW::iterator iter = winPtrs.begin(); iter != winPtrs.end(); ++iter)
// 請注意這里沒有 dynamic_cast
(*iter)->blink();
上面的這兩種實現（使用類型安全的容器，或者在層次結構的頂端添加虛函數）都不是萬能的。但在大多數情況下，它們是 dynamic_cast 良好的替代方案。如果你發現其中一種方案可行，大可以欣然接受。
關于 dynamic_cast 有一件事情自始至終都要注意，那就是：避免級聯使用。就是說要避免類似下面的代碼出現：
class Window { ... };
... // 此處定義派生類
typedef std::vector<std::tr1::shared_ptr<Window> > VPW;
VPW winPtrs;
...
for (VPW::iterator iter = winPtrs.begin(); iter != winPtrs.end(); ++iter)
{
if (SpecialWindow1 *psw1 =
dynamic_cast<SpecialWindow1*>(iter->get())) { ... }
else if (SpecialWindow2 *psw2 =
dynamic_cast<SpecialWindow2*>(iter->get())) { ... }
else if (SpecialWindow3 *psw3 =
dynamic_cast<SpecialWindow3*>(iter->get())) { ... }
...
}
這樣的代碼經編譯后得到的可執行代碼將是冗長而性能低下的，并且十分脆弱，這是因為每當 Window 的類層次結構有所改變時，就需要檢查所有這樣的代碼，以斷定它們是否需要更新。（比如說，如果添加了一個新的派生類，上面的級聯操作中就需要添加一個新的條件判斷分支。）這樣的代碼還是由虛函數調用的方式取代為好。
優秀的 C++ 代碼中使用轉型應該是十分謹慎的，但是一般說來并不是要全盤否定。比如說，本書 118 頁 [2] 中從 int 向 double 的轉型，就是一次合理而有用的轉型，盡管它并不是必需的。（代碼可以這樣重寫：生命一個新的 double 類型的變量，并且用 x 的值對其進行初始化。）和其他絕大多數可以結構一樣，轉型應該盡可能的與其它代碼隔離，典型的方法是將其隱藏在函數中，這些函數的的接口就可以防止調用者接觸其內部復雜的操作。
銘記在心
l 盡可能避免使用轉型，尤其是在對性能敏感的代碼中不要使用動態轉型 dynamic_cast 。如果一個設計方案需要使用轉型，要嘗試尋求一條不需要轉型的方案來取代。
l 在必須使用轉型時，要嘗試將其隱藏在一個函數中。這樣客戶端程序員就可以調用這些函數，而不是在他們自己的代碼中使用轉型。
l 要盡量使用 C++ 風格的轉型，避免使用懷舊風格的轉型。現代的轉型更易讀，而且功能更為具體化。
[1] 在編寫一個程序時，出于種種原因經常會自動關閉或出錯。雖然操作系統沒出問題，但考慮到下次仍可能遇到相同的問題，操作系統就會把程序出錯時的內存（ core ）中的內容轉移（ dump ）出來供調試人員參考。此為 core dump 。——譯注。
[2] 前文中的 doSomeWork(Widget(15)) ， 使用函數風格轉型創建一個 int 的 Widget 。 —— 譯注