*任何*流行的编程语言解释器的主要实现都是用 C++ 编写的吗？
目前我正在考虑是否重写我用C++维护的编程语言解释器。解释器目前是用 C 语言实现的。
但我想知道，它的主要实现是——因为，当然，人们使用原始作者使用的语言以外的语言制作了许多解释器的版本。目前使用的任何流行编程语言解释器都是用 C++ 编写的吗？
如果没有，是否有充分的理由不使用 C++ 编写解释器？据我了解，如果编写正确，C++ 代码可以非常可移植，并且可以编译运行，与执行相同操作的已编译 C 代码一样快。
At the moment I am considering whether or not to rewrite a programming language interpreter that I maintain in C++. The interpreter is currently implemented in C.
But I was wondering, is the primary implementation—because, certainly, people have made versions of many interpreters using a language other than the one used by the original authors—of any popular programming language interpreter currently in use today written in C++?
And, if not, is there a good reason for not writing an interpreter in C++? It is my understanding that C++ code, if written correctly, can be very portable and can potentially compile to run just as fast as compiled C code that does the same thing.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
我认为我不能（或不想）对此表示“是”。我认为这是实用主义与个别语言的需求相结合的问题，并且还取决于它是编译语言（或字节码编译）还是解释语言，或者......
如果您正在尝试编写跨平台代码，那么您会发现最小公分母通常是C编译器（由于CPU架构不同，汇编器不适合部署到许多平台）。由于 C++ 被编码为位于大多数 C 基础结构之上（例如使用名称修饰将类型重载适应 C 链接器理解的内容），因此它通常是即使在嵌入式系统上也可用的最小公分母 OO 语言。这使得它成为那些想要以高级、可维护的方式编写语言的人们的流行选择。
此外，大多数编程语言都有其存在的理由，希望以不同的方式解决问题（毕竟更好必然意味着不同），这意味着它们对于代码需要能够做什么有相当不寻常的需求，并且不这样做不要使用另一种实现语言提供的大量支持设施，因为他们对其没有足够的控制权。因此，考虑到您无论如何都想重新实现很多内容，例如对象模型和数据类型，C++ 的低级方面实际上是一个优势。
也就是说，许多语言都是从用 C++ 编写的第一个版本开始的，例如第一个简单的编译器，然后在该简单版本中编写下一个版本（“引导”）。这样做的好处是你可以使用自己的语言来扩展它。为了移植它，他们只修改编译器以交叉编译到所需的平台，然后使用此交叉编译器构建编译器，结果是新平台的完整语言的本机版本。
往往不这样做的语言通常主要是脚本语言，它们往往保留为解释型 C++ 实现的语言（尽管其他人提到了流行的例外）。
选择 C++ 的另一个常见原因是现有基础设施。例如，如果你想绑定到现有的系统框架，你通常需要降级到 C++，或者如果你想利用现有的编译器后端（如 LLVM，它是用 C++ 编写的），或者即使它们只使用 C，通常，C++ 是最合适的类 OO 实现语言，可以轻松地与系统的 C 部分进行交互。
因此，您想问自己的问题可能是：我的需求是什么，哪种语言最适合这些需求？
有些语言只是另一种语言的预处理器（C++ 和 Objective-C 都是作为 C 之上的预处理器开始的）。他们添加自己的语法或功能，将其翻译成实现语言，然后使用现有编译器编译修改后的代码。如果一种语言已经满足了您想要的所有功能，那么这可能是一个更好的方法，并且可以让您利用使用另一种语言的工程师的经验，将您的工作时间结合起来，超出您单独提供的时间。
I don't think I can (or want) to give this a blanket "yes". I think it's a matter of pragmatism combined with needs of the individual language, and also depends on whether it is a compiled language (or bytecode-compiled) or interpreted, or...
If you are trying to write cross-platform code, you will find that the lowest common denominator is usually a C compiler (due to different CPU architectures, assemblers are not suitable for deploying to many platforms). Since C++ was coded to sit on top of most C infrastructure (like using name mangling to fit type overloads into something a C linker understands), it is usually the lowest-common-denominator OO language that's available even on embedded systems. That makes it a popular choice for people who want to write their language in a high-level, maintainable fashion.
Also, most programming languages have a reason for existing, want to solve problems in a different way (better necessarily means different, after all), which means they have rather unusual needs regarding what their code needs to be able to do, and don't use a lot of the support facilities another implementation language offers, because they wouldn't have enough control over it. So given you'll want to reimplement a lot of e.g. the object model and data types anyway, the low-level aspects of C++ actually are an advantage.
That said, many languages start out with their first version written in C++, a first simple compiler for instance, and then write the next version in that simple version ("bootstrapping"). This has the advantage that you can use your own language to extend it. To port it, they then modify only their compiler to cross-compile to the desired platform, then build the compiler with this cross-compiler, and the result is a native version of the full language for the new platform.
The languages that tend to not do this are usually mainly the scripting languages, which tend to remain as interpreted C++-implemented languages (Though others have mentioned popular exceptions).
Another common reason to pick C++ is existing infrastructure. E.g. if you want to bind to existing system frameworks, you often need to drop down to C++, or if you want to take advantage of existing compiler backends (like LLVM, which is written in C++), or even if they only use C, often C++ is the most suitable OO-like implementation language that can easily talk to the C parts of a system.
So the question you want to ask yourself is likely: What are my needs, and what language best suits those?
Some languages are simply preprocessors on another language (C++ and Objective-C both started out as preprocessors on top of C). They add their own syntax or features, translate those into the implementation language, then compile that modified code using an existing compiler. If a language already does all you want, that may be a better approach, and let you leverage the experience of the engineers working on that other language, combining your work-hours into more than you alone could provide.
我用 C++ 编写了一个解释器（多年来用 C 编写了许多解释器），我认为 C++ 是一种不错的语言。关于实现，我只会回到过去并改变我对实现同时运行多个不同解释器（每个解释器都是多线程）的可能性的选择，仅仅是因为它使代码变得更加复杂，而且它是从未使用过的东西。多线程非常有用，但是解释器的多个实例毫无意义...
但是现在我最大的遗憾确实是我编写了该解释器，因为现在它在生产中使用，编写了相当多的代码以及接受过相关培训的人员，并且因为该语言比 python 更丑陋且功能更弱……但现在切换到 python 会增加成本。它没有我所知的错误......但它比 python 更糟糕，这是一个错误（除了已经无缘无故支付编写它的成本所犯的错误之外）。
我只是应该最初使用 python （或者 lua 或任何其他可以轻松嵌入并且具有合理许可的现成解释器）...我唯一的借口是我当时不了解 python 或 lua时间。
虽然编写解释器作为编程练习是一件有趣的事情，但我建议您避免为生产编写自己的解释器，特别是（请不要个人认为）如果低级复杂性所需的照顾超出了您的能力范围（例如，我发现一些内存泄漏的存在非常令人震惊）。
C++ 仍然是一种低级语言，虽然您可以获得一些帮助，例如在内存处理方面，但该语言的主要假设是您的代码 100% 正确，因为不会出现运行时错误帮助你（仅限未定义的行为守护进程）。
如果你错过了 C（一种更简单的语言）代码 100% 正确的假设，那么我不知道你如何能确信你会在 C++ 中编写正确的代码（相比之下，C++ 是一个复杂的怪物）。我怀疑你最终会得到另一个有缺陷的解释器，你必须扔掉它。
I wrote an interpreter in C++ (after many in C over the years) and I think that C++ is a decent language for that. About the implementation I only would travel back in time and change my choice of implementing the possibility to have several different interpreters running at the same time (every one multithreaded) simply because it made the code more complex and it's something that was never used. Multithreading is quite useful, but multiple instances of the interpreter was pointless...
However now my big regret is indeed the very fact I wrote that interpreter because now it's used in production with a fairly amount of code written and persons trained for it, and because the language is quite uglier and less powerful that python... but switching to python now would add costs. It has no bugs known to me... but yet it's worse than python and this is a bug (in addition to the error already made of paying the cost of writing it for no reason).
I simply should have used python initially instead (or lua or any other ready made interpreter that can easily be embedded and that has a reasonable licensing)... my only excuse for this is that I didn't know about python or lua at that time.
While writing an interpreter is a funny thing to do as a programming exercise I'd suggest you to avoid writing your own for production, especially (please don't take it personally) if the care that low level complexity requires is out of your reach (I find for example the presence of several memory leaks quite shocking).
C++ is still a low level language and while you can get some help for example on the memory handling side still the main assumption of the language is that your code is 100% right as no runtime error is going to help you (only undefined behaviour daemons).
If you missed this assumption of 100% correct code for C (a much simpler language) then I don't see how can you be confident you'll write correct code in C++ (a complexity monster in comparison). I suspect you would just end up with another buggy interpreter that you'll have to throw away.
如果您编写了当前的实现并且 - 正如您在评论中所说 - 它具有：
那么用 C++ 重写对你没有帮助。首先尝试理解为什么当前的实现会出错。另一方面，如果您不是原始开发人员，那么只需选择您最了解的语言并进行移植即可。
更新：
我认为某条评论 正确解释了为什么许多语言是用 C 而不是 C++ 实现的。关于完全重写的主题，留意 Joel Spolsky 的话。
If you wrote the current implementation and -as you say in your comment- it has:
Then rewriting in c++ is not going to help you. First try to understand why the current implementation goes wrong. On the other hand, if you are not the original developer then just choose whichever language you know best and port.
Update:
I think sth's comment explains properly why many languages are implemented in C rather than C++. On the topic of complete rewrites, heed the words of Joel Spolsky.
是的，很多都是。 IIRC Hotspot Java VM 是用 C++、Haskells ghc 编写的，...
正如这里许多人所指出的那样，您确实应该看看 LLVM，它是一个用于构建编译器、解释器和虚拟机的工具包。您基本上完成了前端工作（即在 LLVM IR 中解析您的语言 + 语义分析 + 代码生成），LLVM 将立即为您提供针对不同平台的构建、jit、优化、编译为本机代码……
它还具有一些用于解析和 AST 以及错误处理和通知的工具（但也许这是 Clang 子项目的一部分。）
Yes, many are. IIRC the Hotspot Java VM is written in C++, Haskells ghc, ...
As many here have noted You should really have a look at LLVM, it is a toolkit for building compiler, interpreter and virtual machines. You basically do the frontend work, (i.e. parsing your language + semantic analysis + codegen in LLVM IR) and LLVM will immediately give you building for different platforms, jit, optimization, compiling to native code, ...
It also has some tools for parsing and AST, and error handling and notification (but maybe that is part of the Clang subproject.)
大多数流行的编程语言都是在出现许多优秀的 C++ 编译器之前就开始创建的。因此，这些语言的主要解释器并不是从 C++ 开始的，一旦您在一个可用的解释器上投入了大量工作，您通常不会仅仅因为它现在也可以用 C++ 编写而将其丢弃。
如果您为用 C++ 编写的解释器启动一个新项目，那么它必须走很长的路才能成为主要实现。
Most popular programming languages started to be created before there were many good C++ compilers available. Therefore the primary interpreters of those languages did not start out in C++, and once you have put a lot of work into a working interpreter, you usually don't throw that away just because it could now also be written in C++.
And if you start a new project for a interpreter written in C++ it is has to go a long way to become the primary implementation.
Google Chrome V8 Javascript 引擎实现了 ECMA-262，并且速度非常快。也许您可以用 C++ 重写它，但您应该考虑其他功能，例如实现字节码规范，而不是用 C++ 重写自动化。重写它只会有助于组织代码（这对于团队工作来说是一件好事），但对性能没有任何帮助。
Google Chrome V8 Javascript Engine Implements ECMA-262 and it's extremely fast. Maybe you could rewrite it in C++ but you shold think about other features like implement a bytecode specification instead rewriting your automates in C++. Rewrite it will just help to organize the code (which is a great thing for group working), but nothing in performance.
GNU 基金会最近刚刚宣布所有新版本的 gcc 都将用 c++ 编写。
The GNU foundation has just recently announced that all the new versions of gcc will be written in c++.
Tamarin - Adobe 和 Mozilla ECMAScript 解释器是用 C++ 编写的。作为原始语言作者负责的语言，它可能被认为是主要的（IIRC ECMA 参考实现是用 OCaml 编写的，但除了作为参考之外，实际上并没有使用）
Tamarin - Adobe and Mozilla ECMAScript interpreter is written in C++. Being the one for which the original language author has responsibility, it might be considered the primary one (IIRC the ECMA reference implementation is written in OCaml, but that isn't actually used except as a reference)
Sun 的Java 实现似乎主要是用C++ 编写的。
Sun's Java implementation seems to be written in C++ mostly.
如果内存泄漏是当前程序的唯一问题，请尝试使用 valgrind。我的软件中从未出现过 valgrind 无法为我追踪的内存泄漏。事实上，它多次拯救了我的屁股。
这是一个教程
http://www.cprogramming.com/debugging/valgrind.html
If memory leaks are your only problem with your current program then try valgrind on it. I've never had a memory leak in my software that valgrind could not track down for me. In fact it has saved my butt on so many occasions.
Here is a tutorial
http://www.cprogramming.com/debugging/valgrind.html