2013-06-02 44 views
6

我們正在努力的是用C++開發的模塊上,但考慮到新的C++ 11,我正在考慮遷移到這一點。如何將現有的C++代碼,C++ 11

如何繼續?兩者是相同還是有一些編譯器依賴?

我的軟件目前支持Windows和Linux。我正在使用Microsoft Visual Studio以及GCC來構建它。

總體而言,什麼樣的變化需要如果有的話?

+2

在開始移植之前,您不會知道需要哪些更改。很可能,不需要進行任何更改,但是您可以利用諸如完美轉發,安置等方式獲得優勢(通常避免分配/複製/空閒週期)。 –

+4

除非您使用'auto'關鍵字作爲存儲時間說明符(它已更改爲用於C++ 11中的類型推斷),我不認爲您需要更改任何內容。 – jrok

+1

我知道'C++ 11'向後兼容新功能',但是有沒有特定更改的示例編譯器版本? –

回答

9

舊的C++是用C++ 11編譯器

  • 回顧你如何使用迭代工作(也許你可以移動到範圍換)如果你使用函數指針
  • 評論(也許你可以使用lamdaes)
  • 評論類啓動器(也許你可以寫初始化列表)
  • 審查指針使用(也許你可以切換到的SmartPtr)
  • 審查您的使用與指針NULL也許你可以移動到nullpt [R
+0

寫得很好的舊C++將*可能*與C++ 11編譯器的工作方式相同。即使你沒有任何未定義的行爲,仍然有一些突破性的改變。徹底測試所有內容非常重要,以確保一切仍按預期工作。 –

2

編譯器的問題很少,而且很容易工作,通過。這比採用新的編譯器要容易得多。如果你有選擇,堅持使用標準庫使用了,然後更新標準庫後,你的程序編譯爲C++ 11。如果動態加載,您可能需要堅持舊版本的庫。

如果你想利用新的功能,看看cpp11-migrate。當你也準備充分致力於C++ 11(假設你的編譯器支持所有這些功能)此工具可以自動採取一些適合你的新功能。

2

遷移?我認爲WG21努力保持所有的兼容性。除非您使用導出,否則不需要遷移,現有代碼就沒有問題。

我猜你真的意味着問題的重構現有代碼拿起C++ 11種功能。在這裏,我想套用一般的智慧約重構 - 沒有一個適當的目標,並基於價值的動機從來沒有做到這一點。

只是,新的閃亮的功能得到了介紹您的代碼不徵收技術的債務。

我建議你開始在新代碼中使用新功能,並且應用更自由的更改,因爲無論如何你都要重構不同的原因。只有在多種風格被認爲是一種真正的痛苦時,纔會開始思考整體變形。 (C++的多範型性質,通常應該讓相當多的自由,並強制統一的方法,只是偶爾。)

從的新功能是什麼我會專注於:

  • 汽車。我所有的新代碼充滿了auto constauto const&當地人省略類型。好的,有人建議globalreplace與我之前說過的相反:如果你有for循環使用它們,用auto替換iterator用法。
  • lambda表達式,如果你使用交易算法以一杆的功能
  • 新線程的東西,尤其是std::future是否適用於項目

如果你碰巧使用「的std :: auto_ptr的」,可能是一個很好的候選爲全球更換。

我遺漏了移動語義,因爲我還沒有跳過它們,不確定影響,所以我把它留給其他人來提出或不提出。

+0

「*我認爲WG21努力保護所有兼容性*」 - 當然,但是一些編譯器正在慢慢執行一致性 - 這是他們改進一致性並迫使我們更新程序的好時機。另外,在使用std.C++ 11進行編譯時,一致性程序會產生錯誤(縮小轉換是一個示例),這裏有一些突破性更改。 – justin

+1

@justin:我剛剛重讀了C.2部分,並再次得出結論,如果任何更改顯示在我的代碼庫上,它現在已經有一個潛在的錯誤。 (IUC縮小的轉換更改僅適用於brace-init,我期望匹配類型。)從我的推斷來說,遷移不應該是一個值得一提的事情,而現實生活對我們來說卻是常見的問題。但我不會辯論任何人的不同經歷或意見。收集真實故事將會很有趣。 –

+0

請參閱Ali的鏈接以獲取更完整的重大更改列表。我只是不同意這種模糊的「出口」是唯一真正關心的問題。在這裏,我估計每50,000條物理代碼行約需要一個小時,以便在一個編譯器和一個兼容C++ 11的std庫上增加對C++ 11的支持,使其可以建立並鏈接OK。以下庫/編譯器運行速度更快。維護較差的代碼庫和項目速度較慢。測試省略。採用階段可能會使大部分團隊花費幾天 - 最多幾周,而低端幾小時。 (續) – justin