對於不確定性問題，要想辦法去確認，否則等待你的將會是Bug-----編程心得
上個月在南京為項目中增加一個控制監視模塊的時候，草草地寫完了代碼，代碼中有一句是這樣的：
[cpp]
if (indicator & 0x8000 == 0x8000) {
do something
}
這裡，indicator是int型。我的意思是，如果indicator的第16位是1，那麼就執行括號裡的語句，即indicator的第16位是一個標志位。寫代碼的時候，我是那麼想的，寫完之後很多天我也是那麼想的。可是在南京的哥們卻跟我說，程序運行並不對。如是我自己再去看代碼，仍然發覺沒有什麼問題。但多次的實踐告訴我，計算機是不會隨便冤枉一個程序媛的。既然程序不對，那麼Bug是千真萬確地存在。經過各方排查，我把焦點轉移集中到了下面這句
[cpp]
task.cur = indicator & 0x7fff;
這句的意圖是將indicator中的標志位去掉，恢復出正確的數值。前面說到indicator是int型的，也就是32的；而0x7fff是16的。所以我很自然地以為這裡計算可能錯了。看到這裡，各位高手可能要笑了，“你丫基礎還真茶經！”。哈哈，事後我也笑了。沒辦法，當找不到元凶的時候，替罪羊是減輕心理壓力的一個好方法。其實，這裡的計算並不會導致錯誤，因為C有類型提升。不過雖然如此，我也還是想知道，編譯器在編譯0x7fff這樣的常量的時候是怎樣處理的。
好，接下來為替罪羊伸張正義，那麼就需要把那個元凶給揪出來了。事情的真相是，“關系運算符的優先級要高於邏輯運算符”。對於運算符優先級的問題，每次看C語言編程方面的書籍的時候，我總會跳過去，太麻煩了。而我很討厭記那些麻煩的東西，所以這變成了我的編程不確定性問題。但是，知道總是好的。不過，我仍然不會去記，我只會給自己留下一個意識。以後碰到這樣的問題，我一律會有括號去解決。所以這句，就算我不知道優先級，我也會這樣寫：
[cpp]
if ((indicator & 0x8000) == 0x8000) {
do something
}
