開發一個 C++ 編譯器的難度有多大，難點又在哪裡？

01-03

很好奇開發一款編譯器的難度，比如開發Clang這樣的編譯器，需要多少人，多少時間？程序員的水平又是怎樣的？

C++的前端是出了名的複雜度和可靠性要求並駕齊驅的軟體。

（這兩點都比它高一個數量級的大概就只有OS了）

對於這種系統，唯一的辦法就是燒錢。

燒錢的作用主要包括：

1.留人；

2.填坑；

3.買買買。

先說留人：複雜度一般是「細節」的代名詞。現實中的編譯器大多數以遞歸下降為主，自底向上的歸納推導為輔。這兩樣在教科書上也就是幾頁紙的事情。但是現實總是很殘酷的，人們總想讓語言更加「易用」，這就意味著各種上下文相關的情況都會出現。

對於C++來說，你要判斷一個符號是類型或者變數（比如這個符號被用在模板參數中），要看前面的聲明/定義。這就是一個上下文相關的推導。然後你就會寫大量的if else switch case之類的代碼來解決各種各樣的可能分支。寫它的人當然知道它是做什麼的，但是如果這個人離職了，新來一個人，就呆掉了，這寫的都是什麼煞筆玩意兒。因為它不知道現實中怎樣的需求會導致奇形怪狀的邏輯。所以人員的穩定，對於這種長周期迭代、邏輯複雜的項目是很重要的。但是人的水平要求高嗎？不算高也不算低。總結來說就是：有邏輯，知好歹。技術什麼都可以培養，但是態度和基本智商是比較難培養起來的。

至於怎麼保證人員穩定？很簡單：加薪。

再說填坑：編譯器是對正確性要求很高的基礎軟體。這裡的正確性既包括產生的代碼的正確性，也包括編譯器自身對於各種問題的容忍度和足夠豐富的錯誤提示。容錯和錯誤提示本身也是代碼，也有很大的出錯幾率。所以這些軟體，bug少不了。但是作為基礎軟體，你又不能隨便就2+3搞成了2*3，這樣還怎麼讓別人相信愛情。所以要燒很多錢來養一幫debugger。

再說買買買：古人日：我們不用很麻煩很辛苦也可以成佛。既然這麼費神我們自己做幹什麼，不如買別人的吧。於是MS就乾脆不自己做了，直接去EDG整了個前端，這樣就可以少了不少人年。這就是傳統土豪和水果這種新暴發戶想的不一樣的地方。

傳統土豪想的是：我們有這麼多錢為什麼還要自己解決問題呢？買買買！

水果新貴則是：啊呀，不小心有了這麼多錢，我們要不要給自己製造點問題好把這些錢花出去？

很難。

如果你指Clang，我就說C++編譯器前端吧，我也更了解一些。這個難點在很多方面吧，多到我腦海中瞬間冒出來很多難點，竟不知道第一個該說什麼了。對於一個C++編譯器，首先需要符合C++標準，這是首要的。而C++標準非常細緻，很多地方都是相關聯的，那麼這個就是非常考驗的地方，你不能遺漏（所以這裡需要測試的配合，報給開發者defect)。C++編譯器難在C++本身確實太複雜了，支持面向對象，泛式編程等多種範式，要實現它非常傷腦細胞，個人覺得泛式編程的模板是比較難搞的地方。同時，被很多人拿來面試的對象模型也算一塊吧，另外還有內存模型。難點確實太多，我就不列舉了。

需要多少人？多少人都不為過，關鍵在於很難招到合適的人。

時間？這個不好說，與開發人員的水平密切相關。Clang似乎是從2005開發，2007放出了第一個版本。[cfe-dev] New LLVM C front-end: "clang"，人數未知。而編譯器其實是一個長期的項目，需要不斷跟著標準一起迭代，不是直接Release一下，然後就撒手不管了。

程序員水平？這個不必誇大編譯器開發人員的程序水平，其實基本功紮實、C++熟練、編譯原理與操作系統這些不要掉隊基本就可以了。做編譯器確實是在與代碼做鬥爭，C++編譯器尤其是，這一塊需要耐得住寂寞，並且對編譯器有熱情的程序員，但是確實比較難招到合適的人。EDG做的比較好，我覺得非常大的一個原因就是那個團隊夠穩定。

先試著搞個預處理器還沒開搞編譯器就崩潰了

C++這樣的語言真是奇葩，而且還在不斷加新東西進去

一些基本的概念比如lexer和parser是通用的，主要是c++語法比較複雜，相應的定義和測試也比較複雜，但我覺得還主要是個skill方面的問題，人再多也沒有什麼幫助。團隊規模不需要很大。

確實難，CLang還只是編譯器的前端,後端用的是LLVM，難度小了很多。

後端更難，因為最終將中間代碼轉換成可執行的機器碼，完全和硬體體系相關， 32位和64位不同，x86和arm的差別就更大了。

LLVM的出現讓編譯器的門檻降低了許多，現在各種語言的爆發也和這個有關，只需要做好前端，生成IR code, 其他的交由LLVM處理。