unique_ptr，nullptr和支持gcc 4.5.x和4.6.x

我正在研究一個庫，它有兩個不同的最終用戶，其中一個使用gcc 4.5.3，另一個剛搬到gcc 4.6.3。該庫使用新的C++ 11智能指針（特別是unique_ptr），並在gcc 4.5.3上編譯得很好。但是，在這兩個版本之間，gcc開始支持nullptr，因此unique_ptr的API更改爲與標準更緊密匹配。在現在這樣做下面的代碼從細去曖昧unique_ptr，nullptr和支持gcc 4.5.x和4.6.x

unique_ptr up(new int(30)); 
... 
if(up == 0) // ambiguous call now to unique_ptr(int) for 0

是否有一個乾淨的（即，下句）的方式來改變上面的if語句使其作品既沒有nullptr？我想，以避免可能的話

#if defined NULLPOINTER_AVAILABLE 
    #define NULLPTR (nullptr) 
#else 
    #define NULLPTR (0) 
#endif

一個配置檢查，然後宏像下面這樣（我認爲將工作）或這讓我期待的行爲的唯一途徑？

來源

2012-06-02 bpw1621

你碰到了什麼錯誤？

#include <iostream> 
#include <memory> 
int main() { 
using namespace std; 
unique_ptr<int> up(new int(30)); 
if (up == 0) 
    cout << "nullptr!\n"; 
else cout << "bam!\n"; 
}

用g++ -std=c++0x -Wall nullptr.cpp -o nullptr（gcc 4.6.2）編譯得很好。

而且，經過N2431紙通過Stroustrup的和薩特上nullptr其中類似的使用（與0比較）在實施例之一被明確列出。

來源

2012-06-02 17:17:24 dirkgently

你是對的，你的例子工作（和我的問題陳述），所以它必須與我實際使用的類型（我沒有使用「int」，而是一個模板類）有關。我會看看如果我能找到一個更好的例子，導致我所看到的，如果沒有，我會標記這是正確的。 – bpw1621

@ bpw1621：我確定這是與實際類型有關的事情。他們* MoveConstructible *和* MoveAssignable *？你可以用適當的'type_traits'成員來檢查它，比如'is_move_constructible'。 – dirkgently

如果它們是導致模糊性的類型？我確實看到了我認爲的重載集合中的移動構造函數。 – bpw1621

unique_ptr，nullptr和支持gcc 4.5.x和4.6.x

回答

相關問題