使用或不使用C++ 0x特性的

可能重複：
How are you using C++0x today?使用或不使用C++ 0x特性的

我與一隊一個相當新的系統上工作。我們正在討論遷移到MSVC 2010，我們已經遷移到GCC 4.5。這些是我們使用的唯一編譯器，我們沒有計劃在不久的將代碼移植到不同的編譯器。

我建議我們這樣做後，我們開始利用已經提供的一些C++ 0x功能，如auto。我的同事建議反對，建議等到「C++ 0x實際上變成標準。」我不得不不同意，但我可以用他的措辭來看待這個呼籲。儘管如此，我不禁認爲，這種反對論證更多是出於對學習C++ 0x的恐懼和恐懼，而不是對標準化的真正關注。

鑑於系統的新狀態，我希望我們能夠利用可用的新技術。例如，僅僅使用auto就可以讓我們的日常生活變得更輕鬆（只需編寫基於迭代器的for循環，直到基於範圍的循環出現爲止）。

我想錯了嗎？這不像我提出的，我們從根本上改變了我們萌芽的代碼庫，而是在方便的時候開始使用C++ 0x功能。我們知道我們正在使用哪些編譯器，並且沒有立即計劃移植（如果我們移植了代碼庫，那麼當然編譯器也可以使用C++ 0x功能以及目標平臺）。否則，在我看來，似乎在1997年避免使用iostreams，僅僅因爲ISO C++標準尚未發佈，儘管所有編譯器已經以便攜式方式提供了它們。

如果你們都同意，你能否提供我可以用來加強我的立場的論據？如果不是這樣，我可以獲得更多關於這個「直到C++ 0x是標準的」想法的細節嗎？順便說一句，任何人知道這將是什麼時候？

來源

2010-07-02 stinky472

你願意量化你的意思是「很快」嗎？ – 2010-07-02 12:00:49

@Neil直到Windows和Linux的替代品都非常好，他們使GCC/MSVC過時。 – stinky472 2010-07-02 14:28:13

我會根據每個功能做出決定。

請記住，標準是真的接近完成。剩下的只是投票，錯誤修正和更多投票。

因此，像auto這樣的簡單功能不會消失，或者其語義已更改。那麼爲什麼不使用它。

Lambdas足夠複雜，他們可能會改變他們的措辭，並且在一些角落案例中的語義會有一些變化，但總的來說，他們會按照他們今天的方式行事（儘管VS2010有一些有關捕獲變量範圍的錯誤，MS聲明它們是錯誤，因此可能在主要產品發佈版本之外修復）。

如果你想玩它安全，遠離lambda。否則，請在方便的地方使用它們，但避免超級棘手的情況，或者在標準最終完成時準備好檢查您的lambda使用情況。

大多數功能都可以這樣分類，它們要麼非常簡單而且穩定，以至於它們在GCC/MSVC中的實現正是它們在最終標準中的工作方式，或者它們非常棘手以至於它們可能會得到一些應用的錯誤修正，所以他們現在可以使用可以使用，但是在某些邊界情況下可能會遇到一些粗糙的邊緣。

它確實聽起來很愚蠢，以避免C++ 0x功能，因爲它們還沒有正式化。避免您不信任的功能完整，無缺陷且穩定，但請使用其餘的功能。

來源

2010-07-02 13:32:40 jalf

謝謝賈爾夫的建議！我會接受它，看看我能否說服我的同事選擇性地使用C++ 0x的某些功能。爲了提供一些背景知識，我在一個不願意在自己的手動收藏中使用標準庫的團隊。部分原因是他們討厭迭代器語法。越來越多的人開始使用它們，因爲他們意識到沒有理由不這樣做，但仍然有很多關於基於迭代的for循環所涉及的語法的抱怨。我不介意，因爲我鍵入了所有的東西，語法上的冗餘不再 – stinky472 2010-07-02 14:40:53

再次困擾我（只是邏輯上的冗餘），但是如果我們有了，可以幫助更多的人正確使用C++，說，汽車。 – stinky472 2010-07-02 14:41:34

@ stinky472：如果你知道你有一個支持它的編譯器，那麼沒有理由不使用C++ 0x。請記住，C++ 0x可以提供許多性能增強功能以及C++ 03無法實現的其他功能。理論上講，功能可能會發生變化。但更新和標準完成時更改它的成本要比不使用右值引用，auto，decltype和variadic模板的成本低很多。 – Puppy 2010-07-02 18:00:26

使用的C++ 0x的理論但不實用缺點：

使得它更難移植到不同的編譯器。
不遵守任何公佈的標準。

實用優勢利用的C++ 0x的：

讓您的生活更輕鬆，從而提高工作效率。

這是理論上正確，什麼是實用之間的爭論。如果你的團隊有任何實際的意圖，實際上應該超過理論的十倍。

來源

2010-07-02 12:01:28 Thomas

特別是，如果您完全確定（您似乎是），那麼您不會將此代碼移植到編譯器尚未理解它的系統中。我可以同情你的同事的「標準是好的」想法（可能有點「太」，好：P），但如果沒有實際的消極後果，這只是一個不必要的障礙。 – shambulator 2010-07-02 12:13:03

使用C++ 0x的理論但不太可能的缺點：由於您正在使用的兩個實現中的錯誤或者所提議的標準中的更改，您的代碼可能會被困在特定版本的gcc/msvc中。例如：如果你在7個月前完成了這個任務並且使用了大量的概念。另請參見：Visual Studio 6. – KitsuneYMG 2010-07-02 12:32:34

如果事件從標準中刪除，但已在編譯器中實現，則可能會將它們編譯爲可選的編譯器擴展，而不是完全刪除。正如你所說，這是一個理論上的但不太可能的缺點。 – Thomas 2010-07-02 12:45:39

我們有完全相同的問題，所以我們妥協了。我們採用了C++ 0x TR1版本，然後只用了我們知道我們想要使用的部分。聽起來像很多工作，但到目前爲止，它運作良好。我們使用正則表達式庫，元組和其他幾個。一旦標準獲得批准，我們將遷移到完整的C++ 0x。這顯然不是最好的解決方案，但它對我們來說工作得很好。

來源

2010-07-02 12:02:59 nathan

+1謝謝nathan，我們可以比較一個例子。我正在尋找一種類似的折中方案：只要去掉已有的FCD功能，而不是那些可以進行進一步修改的更奇特的功能。 – stinky472 2010-07-02 16:30:32

你現在不需要（主要）擔心的一件事是功能被添加或帶走，因爲工作草案在3月份達到了「Final Committee Draft」（FCD）。功能方面應該被凍結，標準委員會不會接受C++ 0x的更多提案。

缺點是它還是一個草案，還沒有最終確定，標準委員會正處於最終確定和發佈ISO標準（預計將於2011年3月發佈）之前進行更正和調整的階段。這可能意味着很小的語法或語義/行爲更改，這些更改可能會導致您的代碼無法編譯或無法正常工作，因爲一旦使用比您在編寫代碼時使用的編譯器更符合標準的編譯器進行編譯。

您可能需要等待VC++ 10等編譯器更新所做的任何更正/調整。

來源

2010-07-02 12:58:13

謝謝，指出FCD是一個好主意！我認爲如果我們有選擇地選擇我們可以使用的C++ 0x功能，也許這可能會讓我在這場辯論中贏得一些人。 – stinky472 2010-07-02 14:38:28

如果你打算在一個不太遠的將來使你的系統開源，那麼這是一個不使用太多出血性功能的論點。運行Debian或Red Hat的生產系統不一定會安裝流血的編譯器。

你說

如果我們將代碼移植基地，那麼可以肯定的編譯器將可與的C++ 0x功能，以及針對目標平臺

但是編譯器存在對於一個平臺來說，並不總是意味着它被安裝/使用/需要，特別是在生產系統上。

另一方面，如果您打算自己編譯所有內容，這不是問題。

來源

2010-07-02 13:48:47 Lajnold

+1謝謝Lajnoid，我沒有考慮linux發行版。我們可能希望支持可能僅限於舊版GCC的其他發行版。我將不得不提出這一點作爲考慮的合理問題，但我希望我們可以儘快使用一些基本的C++ 0x功能，而不是等待幾年才能從中受益。 – stinky472 2010-07-03 11:59:36

使用或不使用C++ 0x特性的

回答

相關問題