為什麼VS對C++11 C++14的特性支持的那麼慢?

01-14

RT...還有不少遺留的C++bug沒修復- -
bug==========================
fuction綁定成員函數

std::function not compiling in VS2012一直未修復
另外這幾天玩模板...搞掛cl.exe3次...都是編譯器內部錯誤...
STL Bugs Fixed In Visual Studio 2012這是已經修復的STL bug
Compiler Bugs Fixed In Visual Studio 2012這是已經修復的編譯器bug

C++11/14 Core Language Features in VS 2013 and the Nov 2013 CTP特性支持
gcc4.8.1就完全支持C++11了clang也早支持了...gcc的模板報錯真不能看- -

vs做錯事是要負責任的，誰讓你收人家錢，引入新特性要確保萬無一失，如果對正則表達式的實現像GCC一樣，微軟它敢推出來嗎？

其實還真不能說慢，比起以前對C99的支持速度來說已經快的太多了，主要是在VC上跨平台開發的人現在多起來了（當然比例還是不如在別的平台需要兼容Windows的），微軟內部就有不少(Office for Mac，Skype之類），基本除了界面層之外都是一套標準C++代碼在不同編譯器上跑。

對於微軟外部的程序員來說，碰到編譯器不兼容標準的問題就得寫ifdef的hack然後上connect提bug，不過對於微軟自己的各個產品組來說，當然是叫VC項目組把標準實現了維護費用比較低啦，不用在代碼里到處放ifdef。不過feature request多了VC項目組也不是都處理的過來就是，光掃描一下現有的問題看是不是重複提交就很費時間，所以都是挑影響大的請求先實現，要你關注的問題排在前面的話，去http://connect.microsoft.com投下你自己的一票吧。

為了不讓你用VC++像在用g++一樣感到痛苦（我就經常感到這種痛苦）：看到g++支持某個feature我剛好需要很喜歡，然後一用，發現我必須的用法g++支持起來竟然有bug，而且這個bug在bugzilla裡面已經留了好幾個版本了沒有修！

其實g++這樣支持也等於沒支持，只是人家廣告做得好而已，不需要新feature的人覺得高大上。開源的人都善於做廣告，這點微軟需要向他們學習。

MSVC用的人太多，兼容性壓力大啊。隨便改點東西都要照顧無數語法不正確或疑似不正確的舊代碼，添加新功能這事只能慢慢來了。

@vczh 的答案明顯有傾向性。首先g++/Clang的實現雖然不完美，但早已做到基本可用。而用C++11寫出來的新代碼為了不放棄MSVC兼容，不得不做一些相當醜陋的hack。更何況，MSVC自己的bug也少不到哪去。追求zero bug的話，就別搞什麼C++11，專註於C99還有那麼一點點機會。

目前C++編譯器的世界和前些年web瀏覽器對HTML5標準的支持有相似之處。把MSVC和IE類比，GCC和Firefox類比，Clang和Chrome類比，是不是容易理解一些？

（鑒於問題更新並添加了詳細信息，這裡就不吐槽了）

你要知道GCC x.y.z z越大越穩定，有些平台自舉都有壓力，特別是 y換代的時候，總不能讓那些搞編譯器的忽悠你，特性全部支持很牛逼很牛逼，到底是怎樣就是怎樣，越接觸越多坑，我用基於PowerShell的ClangSetupvNext自動化構建LLVM，一連幾次失敗，最後發現，有開發者把LLD的CMakeFileList改壞了，後來mail-list裡面特別提到了。GCC std::string還在用COW，libcxx一直不鳥Windows平台 http://llvm.org/builds 說了要支持的，每次svn up，Windows的代碼幾乎沒改動。

做什麼業務用什麼平台寫什麼代碼。Windows下Ribbon ,Windows RT,還有很多API, COM介面還是用VC++好。

VS不僅僅是一個C++的編譯器，還有智能提示等等問題要解決，比單純的實現一個編譯器要麻煩得多。