簡單的代碼，復雜的問題。
環(huán)境：VC6SP5,Win2kPro
int b = 10; //已經(jīng)賦值為有效數(shù)據(jù)
const char * str = "1234567890ABCDEF"; //已經(jīng)賦值為有效的字符串。
int a = (b - strlen(str) ) / 2;
經(jīng)過了這樣的計算，a的值究竟是多少？
結果當然不是 (10-16)/2 的 -3，而是一個天文數(shù)字。。。。
a = 2147483645 或者，16進制的 0x7ffffffd
真正的問題代碼只有一行，但是結果卻令人不快。
這里分析一下產生這個問題的原因：
一個隱含的問題是，strlen的返回值，類型是size_t，也就是unsigned int。這是個無符號類型。
當unsigned int 和 int混合運算的時候，編譯器會認為，unsigned int的表達長度比較長，因而結果的類型是unsigned int。
所以 b - strlen(str) 的結果不是 -6，而是和-6具有相同內存布局的unsigned int 值：0xfffffffa，也就是正的4294967290
如果這個數(shù)值直接賦值給int，會因為內存布局相同，而避免問題的產生－－問題存在，但是不產生不良效果。但是隨后的/2操作把問題徹底暴露出來了。。
/2操作可以認為是一次移位，對于無符號類型，移位后高位補0，于是把原本有符號類型賴以利用的符號位清零了。。最終這個數(shù)值賦值給int類型的時候，結果就變成了前面提到的那個可怕的數(shù)值。。
有符號數(shù)字和無符號數(shù)字混合運算的時候，存在一些默認的轉換規(guī)則，符合這些規(guī)則的轉換，都不會引發(fā)編譯器警告或者錯誤，因此這類問題是難以覺察的。但是，我們需要經(jīng)常使用的庫函數(shù)太多了，當參與運算的時候，為每個函數(shù)調用都指定一個固定類型的返回值，似乎是不可能的任務。因此如果你的程序中充滿各種不同類型的整型運算，那么還是盡量小心一些吧。。。