为什么C是编译器的语言——当方案子集看起来更适合时?

我不会费心听40分钟的广播来更彻底地理解你的问题,但我会声称恰恰相反。只有少数编译器是用C语言编写的。我更倾向于认为(至少在适当的情况下),大多数编译器是用它们要编译的语言实现的。

C不必是编译器的语言,但它确实有一些优势。C在几乎所有的平台上都可用,这使得移植和引导编译器变得容易。C更接近于硬件,并使许多在其他语言中难以实现的优化成为可能。用C语言编写的编译器很容易与其他语言、库和系统共存,因为它们大多数都提供C接口。由于C是系统程序员的世界语,其他人也很容易扩展编译器。

好吧,一个原因是在不受支持的体系结构上引导编译器的问题。这通常需要一个适用于该体系结构的编译器,这通常意味着C。我记得我试图从源代码处编译MIT方案,我非常恼火的是,它要求在我构建MIT方案之前安装MIT方案。

顺便说一下,我不确定我是否同意你的前提…C显然是最广泛部署的语言,但其他语言编译器(例如MIT方案)通常都是用这些语言实现的。

这可能是多种因素的组合:

1. 几乎每个平台都有C编译器,这使得为新语言构建新的编译器变得更加容易。
2. 历史:C是一种非常流行的语言,所以很多项目都是C语言(不管项目是什么)。
3. 具体来说,该方案非常不受欢迎(与C相比)。

C有 Flex and Yacc 这有助于实现编译器的前端(解析器和lexer),如果我记得正确的话,它们的输出仅限于C代码

今天的许多编译器都是用C语言以外的语言(如Scheme)编写的。为了使它们可移植,它们最初生成C代码作为目标语言。

我认为很多事情都与后端有关。有人提到了flex和yacc,但是还有gcc和llvm可以帮助您处理许多其他重要的事情,比如优化。