boost::implicit_cast
在stackoverflow上看到這個帖子, 于是發(fā)現(xiàn)了boost::implicit_cast這個小東西.
先來看看這段代碼:
struct top {};
struct mid_a : top {};
struct mid_b : top {};
struct bottom : mid_a, mid_b {};
void foo(mid_a&) {}
void foo(mid_b&) {}
void bar(bottom &arg) {
foo(arg); // 想要調(diào)用"void foo(mid_a&)"
}
int main() {
bottom x;
bar(x);
return 0;
}
是無法編譯通過的, 因為foo的重載解析有歧義. 那么把bar里的代碼改一改, 為了保持C++風格, 我們使用static_cast, 而不是C風格的轉(zhuǎn)換:
foo(static_cast<mid_a&>(arg));
程序編譯通過了, 運行起來也沒有問題, 然而…
一個月以后我把bar的參數(shù)類型修改了一下:
struct top {};
struct mid_a : top {};
struct mid_b : top {};
struct bottom : mid_a, mid_b {};
void foo(mid_a&) {}
void foo(mid_b&) {}
void bar(top &arg) {
// ... 過了一個月, 這里已經(jīng)添加了很多代碼.
foo(static_cast<mid_a&>(arg));
}
int main() {
top x;
bar(x);
return 0;
}
代碼依舊編譯通過, 可是運行時程序掛掉了(假設(shè)這幾個類里面有許多成員, 并且在foo里對其進行了訪問).
發(fā)現(xiàn)問題了嗎? 原因就在于static_cast太強大了, 強大到可以進行”down-cast”. 于是編譯器沒有給你任何警告, 就把一個top類型的引用給強制轉(zhuǎn)換成了min_a的引用.
這個時候輪到boost::implicit_cast出場了. 把bar里面的那句foo調(diào)用改一改:
foo(boost::implicit_cast<mid_a&>(arg));
于是一個月前的代碼依舊可以通過編譯, 而一個月后的代碼中的錯誤被編譯器揪出來了. 原因在于隱式類型轉(zhuǎn)換不允許”down-cast”, 只能”up-cast”.
這里簡要說一下所謂顯式和隱式類型轉(zhuǎn)換的區(qū)別. 在C++世界的英文里, 我們說”convert”通常指”implicit convert”, 而”cast”指”explicit cast”. 隱式類型轉(zhuǎn)換好理解, 就是你寫了個a=b, 而ab不同類型, 編譯又不報錯, 就說明隱式類型轉(zhuǎn)換發(fā)生了, 類似的情況還有在函數(shù)調(diào)用的參數(shù)傳遞時. 而顯式類型轉(zhuǎn)換特指C風格的強制轉(zhuǎn)換((type)obj或者C++中等價的type(obj)), 以及C++風格的四個關(guān)鍵字(static_cast, const_cast, dynamic_cast, reinterpret_cast). 然而這個定義是相當模糊的, 比如一個int類型的x, bool(x)是顯式的, 而!!x是隱式的, 其實效果上并沒有區(qū)別, 只是字面上的不同罷了. (關(guān)于cast和convert的區(qū)別, 參見這里和這里)
所以在bar里我們需要的僅僅是一個隱式類型轉(zhuǎn)換, 然而直接把arg傳遞給foo的話會出現(xiàn)重載歧義, 于是我們需要告訴編譯器到底要進行哪個隱式類型轉(zhuǎn)換. 然而static_cast又太過強大, 它還能做隱式類型轉(zhuǎn)換之外的事情(up-cast), 于是在日后代碼演化的過程中留下了bug.
于是boost::implicit_cast應運而生, 它比static_cast弱, 正如它的名字一樣, 它只能用來告訴編譯器執(zhí)行什么隱式類型轉(zhuǎn)換.
而它的代碼呢? 簡單到令人發(fā)指:
template <typename T>
inline T implicit_cast (typename mpl::identity<T>::type x) {
return x;
}
而mpl::identity的定義也極其簡單:
template<typename T> struct identity { typedef T type; };
有人要問這個identity干什么用的, 看起來很累贅. 如果沒有這個identity, 像”implicit_cast(obj)”這樣的代碼也能通過編譯, 然而它其實什么也沒做, obj的類型仍然沒變. identity的存在使得函數(shù)模板的參數(shù)類型推導失效, 因為要推導出T, 首先得知道identity是什么, 而identity又是依賴于T的. 于是就形成了循環(huán)依賴, 參數(shù)類型推導就失效了. 于是編譯器就要求你顯式地指定T的類型.