**
隱式型別轉換是c++的乙個既好又壞的特性。它給人以方便，但可能造成一些十分隱晦的錯誤。
型別轉換提供了乙個型別向另乙個型別的構造。
[cpp]
view plain
copy
[cpp]
view plain
copy
class
x
};
void
func(
int) {}
intwmain()
上面的**中，x可以隱式地轉換為int，於是函式func可以接受x型別的引數，x0與x1也可以用+來做運算。
在實際的程式設計工作中，乙個更常見的例子是，我們自己定義的字串類（記為string）過載了operator const wchar_t*()：
[cpp]
view plain
copy
[cpp]
view plain
copy
class
string
};
從而，如果乙個函式需要const wchar_t*型別的引數，就可以直接傳入乙個string例項。
但是，過載型別轉換也不是萬無一失的。比如，過載operator bool()。
過載operator bool()所帶來的問題比較多，以至於很多企業的編碼規範中，都不提倡甚至禁止過載operator bool()。
由於bool屬於算數型別，所以過載了operator bool()的類的例項可以被用在任何需要算術型別的上下文中。
[cpp]
view plain
copy
[cpp]
view plain
copy
class
y {}
operator bool
() const
noexcept
};
intwmain()
; y y1;
auto n = y0 + y1; // !!!
std::cout << n << std::endl;
return
0;
}
毫無意義的y0 + y1竟然（無警告地）編譯通過，而且還通過+產生了乙個int，這實在不合理。可能程式作者想要的是y(38)，更可能的是後來維護**的人根本無法知道原作者想幹什麼。隨著**的規模變大，這些細微的隱患會越埋越深，或許，將來花費兩天時間找到的bug就是由它引起的。
為了防止這樣的異常情況，c++11引入了顯式的型別轉換運算子。
[cpp]
view plain
copy
[cpp]
view plain
copy
class
x
};
void
func(
int) {}
intwmain()
用explicit修飾的型別轉換運算子，則相應的型別轉換必須顯式地進行。c式（正確1），函式式（正確2），static_cast（正確3）都行。
但是，顯式的型別轉換有乙個例外。如果表示式被用作條件，那麼顯式的operator bool()也可以隱式地進行（僅限轉換到bool）。「被用作條件」即：
由於轉換到bool一般被用作條件，所以operator bool()一般用explicit來修飾。
[cpp]
view plain
copy
[cpp]
view plain
copy
class
k
};
intwmain()
else
return
0;
}
C 隱式型別轉換操作符
前幾天看mfc時碰到了乙個讓我困惑不已的問題 cdc rectangle的某乙個原型如下 bool rectangle lpcrect lprect 其中lpcrect是const rect 但是諸如如下所示的呼叫也能通過編譯 mydc.rectangle crect p1,p2 其中crect是r...
轉換操作符
有兩種轉換，我一向比較陌生，用得少嘛！並且都是編譯器自動轉換。第一種 內建資料型別 大多數 到類的轉換。最經典的是c型別字串到string類物件的轉換。如 fun string str fun wangyi 編譯器呼叫了string char 自動轉換。如果希望編譯器不自動呼叫具有此引數的建構函式，...
C 顯式轉換
標準c 包含乙個顯式的轉換語法 static cast 用於 良性 和 適度良性 的轉換，包括不用強制轉換 const cast 用於 const 和 或 volatile 進行轉換 reinterpret cast 轉換為完全不同的意思。為了安全的使用它，關鍵必須轉換回原來的型別。轉換成的型別一般...