Error

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風格的轉換:

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;
}

代碼依舊編譯通過, 可是運行時程序掛掉了(假設這幾個類里面有許多成員, 并且在foo里對其進行了訪問).

發(fā)現(xiàn)問題了嗎? 原因就在于static_cast太強大了, 強大到可以進行”down-cast”. 于是編譯器沒有給你任何警告, 就把一個top類型的引用給強制轉換成了min_a的引用.

這個時候輪到boost::implicit_cast出場了. 把bar里面的那句foo調(diào)用改一改:

foo(boost::implicit_cast<mid_a&>(arg));

于是一個月前的代碼依舊可以通過編譯, 而一個月后的代碼中的錯誤被編譯器揪出來了. 原因在于隱式類型轉換不允許”down-cast”, 只能”up-cast”.

這里簡要說一下所謂顯式和隱式類型轉換的區(qū)別. 在C++世界的英文里, 我們說”convert”通常指”implicit convert”, 而”cast”指”explicit cast”. 隱式類型轉換好理解, 就是你寫了個a=b, 而ab不同類型, 編譯又不報錯, 就說明隱式類型轉換發(fā)生了, 類似的情況還有在函數(shù)調(diào)用的參數(shù)傳遞時. 而顯式類型轉換特指C風格的強制轉換((type)obj或者C++中等價的type(obj)), 以及C++風格的四個關鍵字(static_cast, const_cast, dynamic_cast, reinterpret_cast). 然而這個定義是相當模糊的, 比如一個int類型的x, bool(x)是顯式的, 而!!x是隱式的, 其實效果上并沒有區(qū)別, 只是字面上的不同罷了. (關于cast和convert的區(qū)別, 參見這里和這里)

所以在bar里我們需要的僅僅是一個隱式類型轉換, 然而直接把arg傳遞給foo的話會出現(xiàn)重載歧義, 于是我們需要告訴編譯器到底要進行哪個隱式類型轉換. 然而static_cast又太過強大, 它還能做隱式類型轉換之外的事情(up-cast), 于是在日后代碼演化的過程中留下了bug.

于是boost::implicit_cast應運而生, 它比static_cast弱, 正如它的名字一樣, 它只能用來告訴編譯器執(zhí)行什么隱式類型轉換.

而它的代碼呢? 簡單到令人發(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的類型.