以後的C++編譯器有沒有可能使用C#來編寫?

01-05

c的編譯器都是用c++來寫，go也是用自己來編寫，那麼如題呢？

我理解說行的人的邏輯。但其實是不行，原因是沒有優勢。

比如說你用 C 寫了一個 C compiler version 1。然後你又寫了一個 version 2，這個 version 2 的主要功能之一是編譯出來的目標碼更優化。這時你可以用 version 1 編譯 version 2 的源碼，然後再用編譯出來的結果再編譯 version 2 的源碼。這時你有了一個不僅生成目標碼更優化，而且編譯速度也更快的編譯器。

所以用 C 來寫 C compiler 的好處是大多數對目標碼的優化都能體現到新版的編譯速度上。

而用非自舉方式寫的編譯器則不然。你用 C# 寫了一個 C compiler，就算目標碼優化做得再好，也反映不到 compiler 本身的編譯速度上。

為啥不行，C++的編譯器只需要輸出二進位碼就可以了，所有可以操作二進位文件的語言都可以寫C++編譯器。當然了我認為實際上這種情況很難發生的。C語言之所以用C++來寫編譯器，是因為C和C++都不帶runtime。而倘若你用C#來寫，到時候這個雞生蛋的問題就不好解決了。

用榔頭來炒菜炒得好不代表你能開館子。

用bash寫都行

為啥只要提到編譯器自舉的問題就總會有人覺得不可思議，編譯器就是個轉換器而已，跟別的程序沒有任何本質的區別，別說c#了，你用php寫都沒問題，（逃

當然有可能，當個玩具沒問題。但是真實環境，不大會這麼做。

C/C++有個優勢，就是移植容易，所以各個平台都支持。用C#實現，這個優勢就沒有了。

如果編譯器是C/C++實現的，要移植新平台，只要實現個代碼生成，實現一些基礎的系統庫，在原平台上交叉編譯一下自身，你就有了一個能在新平台使用的編譯器了。

如果編譯器是C#實現的，你實現了新的代碼生成，你有了系統庫，可還是不能在新平台上用，你還需要把.net移植到新平台%*#$@#*……這個工作量大太多了。