用C++编写的*any*流行编程语言解释器的主要实现是什么？

Question

目前我正在考虑是否要重写我在C++中维护的编程语言解释器.解释器目前在C中实现.

但我想知道,这是主要的实现 - 因为,当然,人们已经使用了一种语言而不是原始作者所使用的语言 - 现在使用C++编写的任何流行的编程语言解释器？

如果没有,是否有充分的理由不在C++中编写解释器？据我所知,如果编写正确,C++代码可以非常轻松,并且可以编译运行,就像执行相同操作的编译C代码一样快.

Answer 1

我用C++编写了一个解释器(经过多年的C语言编写),我认为C++是一种不错的语言.关于实现我只会及时回过头来改变我实现同时运行几个不同解释器(每个多线程)的可能性的选择,因为它使代码更复杂并且它从未使用过.多线程非常有用,但解释器的多个实例毫无意义......

然而,现在我非常遗憾的是我写的那个解释器的事实,因为现在它在生产中使用了相当数量的代码编写和人员训练,并且因为语言非常丑陋而且功能不如python ...但是切换到python现在会增加成本.它没有我知道的错误...但它比python更糟糕,这是一个错误(除了已经付出的代价,无缘无故地编写它的错误).

我最初应该使用python(或lua或任何其他现成的解释器,可以很容易地嵌入并且具有合理的许可)...我唯一的借口是我不知道python或lua在那时间.

虽然编写口译员作为一项编程练习是一件很有意思的事情,但我建议你不要自己编写自己的作品,特别是(如果低级别的复杂性要求的护理不在你的范围内) (我发现例如存在几个内存泄漏非常令人震惊).

C++仍然是一种低级语言,虽然你可以在内存处理方面获得一些帮助,但语言的主要假设是你的代码100%正确,因为没有运行时错误会帮助你(只有未定义的行为守护进程) ).

如果你错过了C的100%正确代码的假设(一种更简单的语言),那么我看不出你怎么能相信你会用C++编写正确的代码(比较复杂的怪物).我怀疑你最终会得到另一个你必须抛弃的错误翻译.

Answer 2

如果你写了当前的实现,并且你在评论中说 - 它有:

笨拙的符号处理和大量的内存泄漏

然后用c ++重写不会对你有所帮助.首先尝试理解当前实现出错的原因.另一方面,如果您不是原始开发人员,那么只需选择您最熟悉的语言和端口.

更新: 我认为某些评论正确解释了为什么许多语言都是用C而不是C++实现的.关于完全重写的话题,请注意Joel Spolsky的话.