根據Herb Sutter的博客 Trip report: Winter ISO C++ standards meeting (Kona)，範圍應該是確定了，包括Modules和Coroutines等功能特性都已加入。想問下正常情況下，主流編譯器的支持會在什麼時候完成？有可能同步在明年推出，還是得延後一兩年？

GCC和Clang這對兒冤家有點意思。

GCC實現了除module和coroutine之外的大部分特性，而Clang早早支持了coroutine，module也做了一大半，然而其它的c++20特性大部分沒做完。

感情它倆是要逼人做二選一？

C++ Standards Support in GCC?

gcc.gnu.org

C++17, C++14, C++11 and C++98 Status?

clang.llvm.org

非常高興看到協程正式進入標準。私認為微軟的協程提案是非常穩健，並且具有豐富應用經驗的。畢竟，借鑒自C#，而且，C#本質上也是一樣的實現套路。

在協程提案上，Google當了一回攪屎棍。提議了一個毫無新意，差不多就是要關鍵字不一樣的提案。說好聽點，是因為反微軟才是政治正確的；說不好聽點，這是Google的陰謀。企圖通過阻撓C++的協程進展，從而維護自己golang在協程方面的優勢。

這個猜測非常邪惡，但如果猜對了，事情更邪惡。我比較喜歡這個猜測。因為golang的東西，除了協程部分，其他方面於我而言，都是可以用C++較容易實現的。一旦C++協程落定，肯定會有部分golang程序員迴流到C++的。

最後，回答下問題：私認為vs2019會通過一個更新，在2019年秋冬季時提供支持。畢竟，主要的提案部分，VS早就有了。只需要把名字空間using到std里就好了。clang也會最晚2020年提供支持。gcc不好說，特別是coroutine部分。

C++20兩個最大的新特性就是Modules和Coroutine。

Modules

我覺得當前Modules進入C++標準有點早了，我更希望能夠在後期有個更加簡單直接的辦法。如果要對那麼多的歷史代碼改成Modules，各種工具鏈都得修改，makefile也跑不掉，還有考慮與頭文件兼容，以後第三方開源庫怎麼發布，我覺得這些都是問題，當前的Modules還是複雜了，對新手也有一定的門檻。

Coroutine

這個就有點意思了，現在也有很多第三方的實現。之前google也提了一個我認為是反微軟的Coroutine提案，最後委員會還是採用了微軟的提案，兩個提案相比我覺得微軟的提案更加簡明要點（參考C#）。

私以為C++20部分特性將會在VS2019秋冬季更新，clang可能會同步跟上，gcc估計會晚一點。

目前 MSVC，Clang 都支持 Coroutine TS，而且 cppwinrt 大量使用了 Coroutine TS , 目前就可以使用 Coroutine 了。等 C++20 發布時，只需要少量修改即可。MSVC，Clang 均由 ? Gor Nishanov 實現。

我覺得比較遺憾的是網路庫已經在進 C++ 標準的路上蹉跎了十幾年了，如果真的如悲觀預期那樣 C++26 才進入標準，那真的花了二十年了。

2019-02-26 更新：目前 Clang 主線已經對 C++2a 開啟了 Coroutine ,詳情可以查看 rL354736: Enable coroutines under -std=c++2a. 以及 Enable coroutines under -std=c++2a. · llvm-mirror/clang@db44dfe

Module和CoRoutine能進入C++20倒是挺讓我意外的，我一直以為以C++標準化委員會的尿性，C++20應該和C++14/17一樣只會增加一些不痛不癢的特性，所以算是個驚喜吧，希望能早日在主流編譯器中使用。

至於Reflection沒能進標準，還是有點失望的，使用代碼生成自己做反射還是很麻煩的，如果有反射，即使是編譯期反射，也是很有幫助的。

至於網路庫，我倒是覺得無所謂，C++發展了這麼多年，誰還沒幾個趁手的網路庫輪子，何況asio這種框架，要是塞到標準庫裡面，我覺得還是有點違和感的。

推薦閱讀：
相关文章