您如何看待通常编译语言的解释器？
我使用 C++ 解释器 (CINT) 工作，我的经历是灾难性的。它充满了错误、错误行为，而不是标准......我得出了一个结论：为一种天生要编译的语言创建一个解释器是错误的，因为我认为语言的设计严格限于事实它将被解释或编译。
你对此有何看法？
I worked with a C++ interpreter (CINT) and my experience was disastrous. It's full of bugs, strage behaviours, not standards... and I'm arrived to a conclusion: it's wrong to create an interpreter of a language born to be compiled because I think that the design of a language is strictly bounded to the fact that it will be interpreted or compiled.
What do you think about it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
编译器和解释器之间的唯一区别是性能。当然，某个特定的 C++ 解释器存在错误，但这并不意味着所有 C++ 解释器都一定存在错误。我认为这与 C++ 是否“意味着”要编译（由谁？）关系不大，而与 C++ 本身就是一种极其难以编译的语言有关。
（只要我们认为，我认为 C++ 既不应该编译也不应该解释，而应该翻译成不同的语言。但这只是我的观点。）
The only difference between a compiler and an interpreter is performance. Sure, one particular C++ interpreter is buggy, but that does not mean that all C++ interpreters must be buggy. I think this has less to do with whether C++ is "meant" to be compiled (by whom?) and more to do with the fact that C++ is a extremely difficult language to compile to begin with.
(As long as we're opining, I think that C++ should neither be compiled nor interpreted, but translated into a different language instead. But that's just me.)
没有这样的动物。 C++ 生来就是 C 的预处理器，当时它被称为“C with Classes”。任何创建的语言都可以编译或解释，尽管在某些情况下动态语言很难有效编译。所以我可能会相信“生来就被解释”的想法，但绝不相信“生来就被编译”。
更严重的是，创建蹩脚的解释器是错误的，就像创建蹩脚的编译器是错误的一样。句号。
我用过的最好的系统之一是 Saber-C 系统： C 语言的解释器，你可能会说这种语言生来就是为了编译的。太棒了。我仍然怀念它。
Ain't no such animal. C++ was born to be a preprocessor to C, back when it used to be called "C with Classes". Any language ever created can be compiled or interpreted, although there are cases of dynamic languages that are very hard to compile efficiently. So I might buy the idea of "born to be interpreted", but never "born to be compiled".
More seriously, it's wrong to create crappy interpreters, just as it's wrong to create crappy compilers. Full stop.
One of the best systems I ever used was the Saber-C system: an interpreter for C, a language which you might say was born to be compiled. It was great. I still miss it.
嗯，我的想法是，这是很有可能的。我认为您遇到的是正在解释的语言的绝对复杂性。即使在编译时，C++ 也有各种边缘条件和其他怪癖，更不用说解释了。
更简单的语言（想想 Boo、F#) 虽然是编译语言，但仍然可以解释。
Well, my thoughts are that this is very possible. I think what you encountered is the sheer complexity of the language being interpreted. C++ has all kinds of edge conditions and other quirks even when being compiled, let alone being interpreted.
Simpler languages (think Boo, F#), while being compiled languages, can still be interpreted.
这里的“错误”在于创建一个有缺陷的实现（尽管从复杂的语言开始是一个坏主意）；拥有可脚本语言确实有一些用户案例，但我的观点是，已经有很多脚本语言在多个平台上具有合理的实现。如果我需要一种脚本语言，我可能会选择其中一种。
顺便说一句，IIRC C# 规范指出该规范预期与编译器一起使用，但这不是必需的，并且合法的解释版本是可能的。
The "wrong" here is in creating an implementation that is buggy (although starting with a complex language is a bad idea); having a scriptable language does have some user-cases, but my view is that there already are plenty of scribt languages with reasonable implementations on multiple platforms. If I needed a script language, I'd probably aim to use one of those.
As an aside, IIRC the C# spec calls out that the spec anticipates to be used with a compiler, but that this is not a requirement, and that a legal interpreted version would be possible.
如果它们是为了编译而编写的，那么你为什么要逆流而上:)
If they were written to be compiled then why should you swim against the tide :)
不，这没有错，但你为什么要这么做呢？ C 和 C++ 等语言的构建非常接近机器。因此，如果你想构建一个解释器，你应该构建一个完整的虚拟机。这并没有错，但还有更有用的项目。
No its not wrong, but why should you. Languages like C and C++ are build very close to the machine. So if you want to build an interpretor you should build a full virtual machine. Which is not wrong but there are more usefull projects.