C++特性問題？

01-02

C++新的標準出來後會帶來新的特性或者改變，但是有些特性確要很久才能被編譯器支持，我的理解是，當委員會在制定新的標準時，只是理論上設計那些特性嗎？並沒有實際的代碼或者數據表示可行，說白了就是他們覺得可以這樣(例如，我說我要設計一架會飛的飛機，我只是在紙上覺得可行，但是我並沒有設計出飛機飛上天，然後告訴你們，是的，我的設計可行，我飛給你看)。如果不是，那麼在新的標準出來的時候完全可以把相應代碼公布或者說相應已經實現功能的編譯器公布。這樣理解對嗎？順帶確認一下：vs2013並沒有完全支持C++ 11吧，例如constexpr和using(別名)關鍵字就沒被支持....

謝邀，這真的是個有趣的問題。我看過很多C++的提案，以我的經驗觀察，坦白的講，你的說法有對有不對吧，有些東西是能夠給出代碼演示的，尤其是庫的擴展，一般這些作者都會給出一個可能的實現，然後會附註給出現有的C++標準會有哪些要改，這些都算比較好的提案，而有些不好的提案就是直接一張紙，全文字的（&這樣的我發現一般最後都會被幹掉&）。而你所提到的constexpr等，無法編譯器驗證的怎麼辦呢？一般這樣的話，會按這樣的思路，首先是背景介紹（也就是現有的痛苦之類的balabala)，然後有了我這個會有多好（也就是你的代碼性能速度一下就上去了，你編程的感受一下就舒服很多了balabala)，隨後就給出這篇提案的核心點，如constexpr，那麼就會給出一些示範例子，並且很重要的是會說明這樣的例子的理想輸出是什麼。同時也會給出一些錯誤的例子，並且解釋為什麼是錯的。一般舉這些例子，就是告訴你我這個到底可以做什麼，有什麼效果，做編譯器的人實現這個東西也要有這樣的輸出，最後也會給出會涉及到哪些現有標準文檔部分的修改。而最後能不能通過，是C++標準委員會的委員一起討論投票決定的，而這裡面的人一般也會有做編譯器的代表，會權衡出編譯器難度。而constexpr這東西其實是很難的，而這個提案當時能通過，也是Facebook的大牛， Modern C++ Design的作者Andrei Alexandrescu比較力推，因為他說D語言就能做（&當然實際情況是確實覺得這東西能提高性能&）。不過現在實現constexpr一般都是使用了一些Hack的辦法。

好吧，其實大部分新特性並不是拍腦門，比如move語義，nullptr，lambda就是為了處理一些很噁心的問題。大量c++11新特性都能在boost中找到相應的實現，在沒有這些新特性的時候，boost解決了一部分問題，現在等於把這些成熟的東西，放到語言級層面來支持。至於VS2013嘛，可以去看看官方blog，有詳細的支持列表，雖然沒有完整支持，但是使用起來應該問題不大，至於什麼時候完整支持，我看VS2015做的不錯XD

光明正大的拒絕進步

這樣理解不對。

我覺得那幫爺的思路是這樣的（以lambda為例）：

A：嘿，我發現Haskell語言里的lambda表達式不錯，知道的人越來越多了，要不咱也把它寫進標準里吧。

B：嗯，確實，我聽見不少麻瓜們都開始叨叨lambda演算了。

A：那咱們加進去唄。 //所以lambda表達式就進標準了。

C：等等，這東西好像跟對象生命周期有衝突，咱們C++又沒有GC和closure，這變數東西怎麼傳進去呀？什麼時候釋放呀？

A：艹，打個補丁，加上[a, =b] 來表示引用和拷貝傳遞吧。

C：牛呀！又優雅又精確，真棒！

D：老子的泛型編程里想要用lambda，發現你這貨跟模板不搭呀！

A：艹，你丫還用模板？！ //所以C++14有了多態lambda……

C++不是激進的，試驗性的語言，它裡邊的feature一般都是久經檢驗的老兵們。而且這些feature單個來看都不複雜，那幫爺可能都以比較hack的方式實現過。那為什麼編譯器不能直接使用他們的原型代碼，而是要花不短的時間組織實現呢？我也不知道，但我只覺得這樣我更安心一點……C＋＋有幾百個feature，互相之間糾結不清，他們還是慢慢體會，慢慢寫吧，否則編譯器都信不過的時候，怎麼debug?!!現在可沒多少漢子能直接讀彙編了……

順帶答一個：VS2013我不熟，不知道……

標準定義和標準實現是兩個不同的內容，其實就C＋＋而言，很多時候是標準實現在前，標準定義只是追認。例如boost::thread等庫，又比如variable macro arguments在GCC中已經早就實現了。

相比之下，商業公司（特指）要功利一些，不會主動實現新特性，而是會按自己商業規劃實現一些莫名的東西（CLR C++?）。

標準組織要討論的問題（除了成員之間的利益），主要是特性是否真的有用，有沒有BUG，以及兼容性。實現難度其實只在有兩個提案同時解決同一個問題時才會比較。

先有指令集還是先有CPU？