何時使用Q_NULLPTR？

Question

我看到Q_NULLPTR在Qt源代碼和示例中被大量使用，但是我沒有找到關於它究竟是什么以及什么時候應該使用的文檔。

例如，在新的Qt v5.6中添加的新Qt SerialBus模塊的官方演示中：

if (!m_canDevice->connectDevice()) {
    delete m_canDevice;
    m_canDevice = Q_NULLPTR;

在C ++ 11中添加之前，這是否符合nullptr的目的？ 如果是這樣，既然我們有C ++ 11，我應該使用Q_NULLPTR嗎？

PS：我嘗試在Qt源代碼中搜索宏的定義，但未能找到它。

Answer 1

Q_NULLPTR是一個宏，如果編譯器支持c ++ 11則替換為nullptr如果不支持，則替換為NULL （替換為0 ）。 如果使用c ++ 11，則可以編寫nullptr ; 如果不這樣做，請使用NULL 。

Answer 2

在C ++ 11中添加之前，這是否符合nullptr的目的？ 如果是這樣，既然我們有C ++ 11，我應該使用Q_NULLPTR嗎？

是（有些）和否。

C ++在當時還很缺乏，所以Qt有自己的東西，后來隨着C ++趕上了這些功能而變得過時了。

話雖這么說， Q_NULLPTR在功能上與nullptr ，（正如Andrei指出的，如果支持C ++ 11，它會擴展為nullptr ）它沒有給你類型安全，只是語法“糖”。 它向讀取代碼的人說明了意圖，而不是像nullptr那樣向編譯器說明。

Answer 3

使用Q_NULLPTR保持編譯器獨立性。

如果您現在決定使用nullptr ，則您的代碼將無法使用較舊的c ++ 98編譯器進行編譯。 如果您決定使用NULL ，則即使在當前編譯器中可用，也會失去c ++ 11類型的安全性。

出於同樣的原因，存在像qMove(x)和相應的定義Q_COMPILER_RVALUE_REFS這樣的宏。

Answer 4

實際上Q_NULLPTR只有一個目的：允許使用nullptr而不失去對沒有C ++ 11 / C ++ 0x支持的編譯器的支持，因為直接使用nullptr會導致這種設置出錯。 缺點是它的回退到NULL （或者在較舊的Qt版本中為0 ）存在歧義，這可能導致意外的運行時行為並限制與nullptr相比支持的用例。

在極少數情況下，您定位非C ++ 11兼容編譯器，使用Q_NULLPTR但確保在禁用C ++ 11功能時代碼運行良好。 在所有其他情況下， nullptr是更好的選擇，因為它與遺留編譯器一起使用時會導致編譯錯誤而不是錯誤的運行時行為。 Qt 5.7及更高版本在沒有C ++ 11的情況下放棄了對編譯的支持，因此如果您依賴這些版本則不需要Q_NULLPTR 。

還有其他一些功能，如qMove或Q_DECL_OVERRIDE ，當用於支持編譯器而不破壞舊編譯器上的編譯時，可以提供改進的語義。