對於我目前正在使用的代碼,我們有時需要在一些較舊的系統上編譯使用較老的編譯器(例如,我們在舊的IBM BlueGene/L上運行模擬程序,誰的支持合同規定了一些非常古老的C++編譯器)。代碼本身使用shared_ptrs,最初編寫爲使用std :: tr1 :: shared_ptr。在舊的BlueGene機器上編譯時,我很快意識到它沒有tr1 :: implementation,所以我切換到boost :: shared_ptr。原來還有一個boost :: tr1 :: shared_ptr。現在代碼在我們的研究小組之外被廣泛使用,可移植性變得更加重要。如何處理不斷髮展的C++ std :: namespace?例如:std :: tr1 :: shared_ptr vs. std :: shared_ptr vs. boost :: shared_ptr vs. boost :: tr1 :: shared_ptr
在大型代碼庫中處理這些不斷髮展的標準庫問題的最佳實踐是什麼?我假設在新的C++ 11標準中,shared_ptr將不再位於tr1命名空間中,這增加了另一個潛力:std :: shared_ptr,但是我猜測對此的廣泛支持將是一種解決方法。我希望儘可能使用最新的標準,但需要保持可移植性。我應該堅持提升嗎?
現在已經有編譯器,其中'的std :: shared_ptr'可用,如VC2010和最新版本的g ++。如果你需要支持多種不同的編譯器,堅持增強可能是最簡單的。 :) – Sven
只是因爲shared_ptr將被添加到命名空間std ::並不意味着它將被*刪除*從命名空間std :: tr1 ::。我知道gcc/libstdC++會保持前進。事實上,我確信Visual Studio將是一樣的。 – emsr
我想如果你環顧四周,至少在過去的兩年中,大多數編譯器都支持std :: shared_ptr。我會堅持使用std :: first,然後查找std :: tr1 ::然後嘗試按照該順序進行提升。 – emsr