reinterpret_cast運(yùn)算符是用來處理無關(guān)類型之間的轉(zhuǎn)換；它會產(chǎn)生一個新的值，這個值會有與原始參數(shù)（expressoin）有完全相同的比特位。
什么是無關(guān)類型？我沒有弄清楚，沒有找到好的文檔來說明類型之間到底都有些什么關(guān)系（除了類的繼承以外）。后半句倒是看出了reinterpret_cast的字面意思：重新解釋（類型的比特位）。我們真的可以隨意將一個類型值的比特位交給另一個類型作為它的值嗎？其實不然。
IBM的C++指南里倒是明確告訴了我們reinterpret_cast可以，或者說應(yīng)該在什么地方用來作為轉(zhuǎn)換運(yùn)算符：
不過我在Xcode中測試了一下，事實上reinterpret_cast的使用并不局限在上邊所說的幾項的，任何類型的指針之間都可以互相轉(zhuǎn)換，都不會得到編譯錯誤。上述列出的幾項，可能 是Linux下reinterpret_cast使用的限制，也可能是IBM推薦我們使用reinterpret_cast的方式
所以總結(jié)來說：reinterpret_cast用在任意指針（或引用）類型之間的轉(zhuǎn)換；以及指針與足夠大的整數(shù)類型之間的轉(zhuǎn)換；從整數(shù)類型（包括枚舉類型）到指針類型，無視大小。
（所謂"足夠大的整數(shù)類型",取決于操作系統(tǒng)的參數(shù)，如果是32位的操作系統(tǒng)，就需要整形（int）以上的；如果是64位的操作系統(tǒng)，則至少需要長整形（long）。具體大小可以通過sizeof運(yùn)算符來查看）。
從上邊對reinterpret_cast介紹，可以感覺出reinterpret_cast是個很強(qiáng)大的運(yùn)算符，因為它可以無視種族隔離，隨便搞。但就像生物的準(zhǔn)則，不符合自然規(guī)律的隨意雜交只會得到不能長久生存的物種。隨意在不同類型之間使用reinterpret_cast，也之后造成程序的破壞和不能使用。
比如下邊的代碼typedef int (*FunctionPointer)(int);
int value = 21;
FunctionPointer funcP;
funcP = reinterpret_cast<FunctionPointer> (&value);
funcP(value);
我先用typedef定義了一個指向函數(shù)的指針類型，所指向的函數(shù)接受一個int類型作為參數(shù)。然后我用reinterpret_cast將一個整型的地址轉(zhuǎn)換成該函數(shù)類型并賦值給了相應(yīng)的變量。最后，我還用該整形變量作為參數(shù)交給了指向函數(shù)的指針變量。
這個過程編譯器都成功的編譯通過，不過一旦運(yùn)行我們就會得到"EXC_BAD_ACCESS"的運(yùn)行錯誤，因為我們通過funcP所指的地址找到的并不是函數(shù)入口。
由此可知，reinterpret_cast雖然看似強(qiáng)大，作用卻沒有那么廣。IBM的C++指南、C++之父Bjarne Stroustrup的FAQ網(wǎng)頁和MSDN的Visual C++也都指出：錯誤的使用reinterpret_cast很容易導(dǎo)致程序的不安全，只有將轉(zhuǎn)換后的類型值轉(zhuǎn)換回到其原始類型，這樣才是正確使用reinterpret_cast方式。
這樣說起來，reinterpret_cast轉(zhuǎn)換成其它類型的目的只是臨時的隱藏自己的什么（做個臥底？），要真想使用那個值，還是需要讓其露出真面目才行。那到底它在C++中有其何存在的價值呢？
MSDN的Visual C++ Developer Center 給出了它的使用價值：用來輔助哈希函數(shù)。下邊是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位的系統(tǒng)，可能需要將unsigned int改成 unsigned long才能運(yùn)行。 這段代碼適合體現(xiàn)哈希的思想，暫時不做深究，但至少看Hash函數(shù)里面的操作，也能體會到，對整數(shù)的操作顯然要對地址操作更方便。在集合中存放整形數(shù)值，也要比存放地址更具有擴(kuò)展性（當(dāng)然如果存void *擴(kuò)展性也是一樣很高的），唯一損失的可能就是存取的時候整形和地址的轉(zhuǎn)換（這完全可以忽略不計）。
不過可讀性可能就不高，所以在這種情況下使用的時候，就可以用typedef來定義個指針類型：typedef unsigned int PointerType;
這樣不是更棒，當(dāng)我們在64位機(jī)器上運(yùn)行的時候，只要改成：typedef unsigned long PointerType;
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 constness FunctionPointer funcP = reinterpret_cast<FunctionPointer> (pointer);}例子里，我們像前面const_cast一篇舉到的例子那樣，希望將指向const的指針用運(yùn)算符轉(zhuǎn)換成非指向const的指針。但是當(dāng)實用reinterpret_cast的時候，編譯器直接報錯組織了該過程。這就體現(xiàn)出了const_cast的獨(dú)特之處。
但是，例子中還有一個轉(zhuǎn)換是將指向const int的指針付給指向函數(shù)的指針，編譯順利通過編譯，當(dāng)然結(jié)果也會跟前面的例子一樣是無意義的。
如果我們換一種角度來看，這似乎也是合理的。因為const int* p = &value;
int * const q = &value;
這兩個語句的含義是不同的，前者是"所指內(nèi)容不可變"，后者則是"指向的地址不可變"（具體參考此處）。因此指向函數(shù)的指針默認(rèn)應(yīng)該就帶有"所指內(nèi)容不可變"的特性。
畢竟函數(shù)在編譯之后，其操作過程就固定在那里了，我們唯一能做的就是傳遞一些參數(shù)給指針，而無法改變已編譯函數(shù)的過程。所以從這個角度來想，上邊例子使用reinterpret_cast從const int * 到FunctionPointer轉(zhuǎn)換就變得合理了，因為它并沒有去除const限定
