C 和 C++ 是什么语言？标准库是用什么写的？
C 和 C++ 本身实际上无法做任何事情，它们需要库才能工作。那么这些库是如何创建的呢？汇编语言？
C and C++ by themselves can't actually do anything, they need the libraries to work. So how were the libraries created? Assembly language?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
C 和 C++ 库几乎都是用 C 和 C++ 编写的，C 和 C++ 编译器也是如此。事实上，很多编译器甚至用来编译自己！
这怎么可能？显然，第一个 C 编译器最初不可能是用 C 语言开发的。但是，一旦 C 编译器存在，它就可以用来编译另一个编译器。随着编译器的开发，源代码也在开发中。两者可以并行开发。由于大多数编译器都是对其前身的改进，因此它们通常用于编译自身更好的版本！
然而，对于库来说，这很简单：C 可以实际上做一些事情。虽然一些较低级别的例程可以用汇编程序编写，但绝大多数可以用 C 或 C++ 编写。
C and C++ libraries are almost universally written in C and C++, as are C and C++ compilers. In fact, many compilers are even used to compile themselves!
How is this possible? Well, obviously the first C compiler couldn't have been initially developed in C. However, once a C compiler exists, then it can be used to compile another compiler. And as a compiler is being developed, so is the source code. It's possible to develop both side-by-side. Since most compilers are improvements on their predecessors, they are often used to compile better versions of themselves!
However, with respect to the library, that's easy: C can actually do something. While some lower-level routines may be written in assembler, the vast majority can be written in C or C++.
标准库通常用 C 和 C++ 编写，使用最少的汇编代码以便与操作系统提供的功能进行交互，并且大多数操作系统都是用 C 以及少数汇编语言的混合编写的。不能直接用 C 完成的事情。
更具体的例子...
对于 GNU/Linux，标准库是用 C 和 C++ 编写的。对于需要使用内核的各种事情，最终都会调用 syscall ，它提供了跳转到内核所需的一小段汇编代码，其中用 C 和汇编语言混合编写的代码处理调用。
The standard libraries are typically written in C and C++, using a bare minimum of assembly code in order to interact with the functionality provided by the operating system, and most operating systems are written in C as well as a mix of assembly for a handful of things that cannot be done directly in C.
A more specific example...
For GNU/Linux the standard libraries are written and C and C++. For the various things that require the use of the kernel, there is ultimately an invocation of syscall, which provides the small bit of assembly code needed to jump into the kernel, where code written in a mix of C and assembly handle the call.
这里有一个轻微的误解：编译器负责将 C 或 C++（或其他任何东西）翻译成机器代码。库本身可以用 C 编写，这没有问题。而且，即使编译器本身也可以用C编写，只要存在至少一个C编译器来编译它。 （最大的笑话是，要在 Linux 上“正确”安装 gcc，您需要 gcc 从源代码编译它。）
也许您可能会问“第一个 C 编译器是用什么编写的”。
There's a slight misunderstanding here: The compiler is responsible for translating C or C++ (or anything else) into machine code. The libraries themselves can be written in C, there's no problem with that. Moreover, even the compiler itself can be written in C as long as there exists at least one C compiler to compile it. (The big joke is that to "properly" install gcc on linux, you need gcc to compile it from source.)
You could ask "what was the first C compiler written in", perhaps.
它们是用宿主语言编写的，原因很简单，它们需要与操作系统交互来执行它们自己无法完成的操作，它们将使用操作系统提供的 API 来执行此操作。
C++ 标准库是用 C++ 编写的，因为它的大部分实现都使用模板。
They are written in their host language for the simple reason that they need to interact with the operating system to perform operations they do cannot do on their own, they would do so using the operating system provided API.
The C++ Standard library is written in C++ because most of its implementation uses templates.
在典型情况下，C 标准库主要用 C 编写，C++ 标准库主要用 C++ 编写。
给出一些具体数字，微软的标准库有大约 1050 个 C 和 C++ 文件，以及 37 个汇编语言文件。只要看一眼，我就会说至少有一半的汇编文件也可以用 C 或 C++ 编写；它们使用汇编语言是为了优化，而不是出于必要。
In a typical case, the C standard library is written primarily in C, and the C++ standard library primarily in C++.
To give some concrete numbers, Microsoft's standard library has ~1050 C and C++ files, and 37 assembly language files. Just glancing at them, I'd say at least half those assembly files could be written in C or C++ as well; they're in assembly language for the sake of optimization, not out of necessity.
大多数 C 和 C++ 编译器都是用 C 和 C++ 编写的。这是可能的，因为编译器引导。关于该主题有一个相关的 Stackoverflow 问题：
引导编译器：为什么？
另外，您可能会欣赏 Ken Thompson 的对信任信任的反思。在那篇论文中，汤普森谈到了信任编译代码所固有的困难。
Most compilers for C and C++ are written in C and C++. This is possible because of compiler bootstrapping. There is a related Stackoverflow question on the topic:
Bootstrapping a compiler: why?
Also, you might enjoy Ken Thompson's Reflection on Trusting Trust. In that paper, Thompson talks about the difficulties inherent in trusting compiled code.