C++標準轉換運算子reinterpret_cast

reinterpret_cast <new_type> (expression)

reinterpret_cast運算子是用來處理無關類型之間的轉換；它會產生一個新的值，這個值會有與原始參數（expressoin）有完全相同的位元位。

什麼是無關類型？我沒有弄清楚，沒有找到好的文檔來說明類型之間到底都有些什麼關係（除了類的繼承以外）。後半句倒是看出了reinterpret_cast的字面意思：重新解釋（類型的位元位）。我們真的可以隨意將一個類型值的位元位交給另一個類型作為它的值嗎？其實不然。

IBM的C++指南裡倒是明確告訴了我們reinterpret_cast可以，或者說應該在什麼地方用來作為轉換運算子：

• 從指標類型到一個足夠大的整數類型
• 從整數類型或者枚舉類型到指標類型
• 從一個指向函數的指標到另一個不同類型的指向函數的指標
• 從一個指向對象的指標到另一個不同類型的指向對象的指標
• 從一個指向類函數成員的指標到另一個指向不同類型的函數成員的指標
• 從一個指向類資料成員的指標到另一個指向不同類型的資料成員的指標

不過我在Xcode中測試了一下，事實上reinterpret_cast的使用並不局限在上邊所說的幾項的，任何類型的指標之間都可以互相轉換，都不會得到編譯錯誤。上述列出的幾項，可能 是Linux下reinterpret_cast使用的限制，也可能是IBM推薦我們使用reinterpret_cast的方式

所以總結來說：reinterpret_cast用在任意指標（或引用）類型之間的轉換；以及指標與足夠大的整數類型之間的轉換；從整數類型（包括枚舉類型）到指標類型，無視大小。

（所謂"足夠大的整數類型",取決於作業系統的參數，如果是32位的作業系統，就需要整形（int）以上的；如果是64位的作業系統，則至少需要長整形（long）。具體大小可以通過sizeof運算子來查看）。

reinterpret_cast有何作用

從上邊對reinterpret_cast介紹，可以感覺出reinterpret_cast是個很強大的運算子，因為它可以無視種族隔離，隨便搞。但就像生物的準則，不符合自然規律的隨意雜交只會得到不能長久生存的物種。隨意在不同類型之間使用reinterpret_cast，也之後造成程式的破壞和不能使用。

比如下邊的代碼

typedef int (*FunctionPointer)(int);

int value = 21;

FunctionPointer funcP;

funcP = reinterpret_cast<FunctionPointer> (&value);

funcP(value);


我先用typedef定義了一個指向函數的指標類型，所指向的函數接受一個int類型作為參數。然後我用reinterpret_cast將一個整型的地址轉換成該函數類型並賦值給了相應的變數。最後，我還用該整形變數作為參數交給了指向函數的指標變數。

這個過程編譯器都成功的編譯通過，不過一旦運行我們就會得到"EXC_BAD_ACCESS"的運行錯誤，因為我們通過funcP所指的地址找到的並不是函數入口。

由此可知，reinterpret_cast雖然看似強大，作用卻沒有那麼廣。IBM的C++指南、C++之父Bjarne Stroustrup的FAQ網頁和MSDN的Visual C++也都指出：錯誤的使用reinterpret_cast很容易導致程式的不安全，只有將轉換後的類型值轉換回到其原始類型，這樣才是正確使用reinterpret_cast方式。

這樣說起來，reinterpret_cast轉換成其它類型的目的只是臨時的隱藏自己的什麼（做個臥底？），要真想使用那個值，還是需要讓其露出真面目才行。那到底它在C++中有其何存在的價值呢？

MSDN的Visual C++ Developer Center 給出了它的使用價值：用來輔助雜湊函數。下邊是MSNDN上的例子：

                // expre_reinterpret_cast_Operator.cpp// compile with: /EHsc#include <iostream>// Returns a hash code based on an addressunsigned short Hash( void *p ) {unsigned int val = reinterpret_cast<unsigned int>( p );return ( unsigned short )( val ^ (val >> 16));}using namespace std;int main() {int a[20];for ( int i = 0; i < 20; i++ )cout << Hash( a + i ) << endl;}//如果跟我一樣是64位的系統，可能需要將unsigned int改成 unsigned long才能運行。            

這段代碼適合體現雜湊的思想，暫時不做深究，但至少看Hash函數裡面的操作，也能體會到，對整數的操作顯然要對地址操作更方便。在集合中存放整形數值，也要比存放地址更具有擴充性（當然如果存void *擴充性也是一樣很高的），唯一損失的可能就是存取的時候整形和地址的轉換（這完全可以忽略不計）。

不過可讀性可能就不高，所以在這種情況下使用的時候，就可以用typedef來定義個指標類型：
typedef unsigned int PointerType;

這樣不是更棒，當我們在64位機器上啟動並執行時候，只要改成：

typedef unsigned long PointerType;


當reinterpret_cast面對const

IBM的C++指南指出:reinterpret_cast不能像const_cast那樣去除const修飾符。
這是什麼意思呢？代碼還是最直觀的表述：

int main() {typedef void (*FunctionPointer)(int);int value = 21;const int* pointer = &value;//int * pointer_r = reinterpret_cast<int*> (pointer); // Error: reinterpret_cast from type 'const int*' to type 'int*' casts away constnessFunctionPointer funcP = reinterpret_cast<FunctionPointer> (pointer);}

例子裡，我們像前面const_cast一篇舉到的例子那樣，希望將指向const的指標用運算子轉換成非指向const的指標。但是當實用reinterpret_cast的時候，編譯器直接報錯組織了該過程。這就體現出了const_cast的獨特之處。

但是，例子中還有一個轉換是將指向const int的指標付給指向函數的指標，編譯順利通過編譯，當然結果也會跟前面的例子一樣是無意義的。

如果我們換一種角度來看，這似乎也是合理的。因為

const int* p = &value;
int * const q = &value;

這兩個語句的含義是不同的，前者是"所指內容不可變"，後者則是"指向的地址不可變"（具體參考此處）。因此指向函數的指標預設應該就帶有"所指內容不可變"的特性。

畢竟函數在編譯之後，其操作過程就固定在那裡了，我們唯一能做的就是傳遞一些參數給指標，而無法改變已編譯函數的過程。所以從這個角度來想，上邊例子使用reinterpret_cast從const int * 到FunctionPointer轉換就變得合理了，因為它並沒有去除const限定

Director: Jim Fawcett

1. C++ Language Tutorial - Type Casting
2. Object Oriented Design
3. IBM Complilers - XL C/C++ V9.0 for Linux - The reinterpret_cast operator (C++ only)
4. Bjarne Stroustrup's C++ Style and Technique FAQ
5. MSDN Visual C++ Developer Center - reinterpret_cast Operator