boost::implicit_cast



boost::implicit_cast

在stackoverflow上看到這個帖子, 於是發現了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); // 想要調用"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的參數類型修改了一下:

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) {
    // ... 過了一個月, 這裏已經添加了很多代碼.
    foo(static_cast<mid_a&>(arg));
}

int main() {
    top x;
    bar(x);
    return 0;
}

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

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

這個時候輪到boost::implicit_cast出場了. 把bar裏面的那句foo調用改一改:

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

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

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

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

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

而它的代碼呢? 簡單到令人髮指:

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的存在使得函數模板的參數類型推導失效, 因爲要推導出T, 首先得知道identity是什麼, 而identity又是依賴於T的. 於是就形成了循環依賴, 參數類型推導就失效了. 於是編譯器就要求你顯式地指定T的類型.

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章