我个人只知道 1 个 C++ 解释器，由 Root 使用（CINT，在 CERN 开发）。 这让我想知道为什么这么少，显而易见的答案是 C++ 是一种解析起来非常复杂的语言。 没有一个头脑正常的人会费心从头开始编写一个 C++ 解析器……
然而，C++ 解析器作为编译器的一部分存在，其中一些是开源的。 我突然想到，也许可以解释解析器实时发出的汇编代码。 这就像一个 JIT 编译器，它发出由虚拟机解释的字节码。 我想到的一个问题是使用不同的源文件，否则会导致需要链接多个目标文件。 这确实是一个限制，但如果你问我的话，这并不是一个非常严重的限制。
不过，似乎没有人这样做过，这通常意味着它并不像看起来那么容易（并不是说我的想法微不足道，但仍然如此）。 我想知道我的想法有什么问题……有人愿意发表评论吗？
解决方案1
请参阅 bling（关于 C++/CLI 的好主意）和我本人对这个问题的评论。
事实是：CINT 不是 C++ 解释器。 CINT 不是 C++ 解释器。 这里明确说明了这一点：
该语言是一些基于 C 和 C++ 的简化语言。
也可以看看： http://root.cern.ch/drupal/content/cling[^]。
上面引用的维基百科文章中提到的另一种选择“Ch”怎么样？ 这不完全是C++解释器，这是某种特殊语言的解释器：
http://en.wikipedia.org/wiki/Ch_%28computer_programming%29[^],
还要别的吗？ “Pike”，也仅基于 C 和 C++（维基百科甚至说“受到影响”）：
http://en.wikipedia.org/wiki/Pike_%28programming_language%29[^],
至于“真正的”C++语言，我有些人认为它不适合解释器； 这个话题太复杂，无法集中讨论我的想法 快的 问题和答案。 我不能在这里证明这一点，也不是100%确定，倾向于认为这是可能证明的。 如果有人证明我错了，我会感到非常惊讶。
解决方案3
引用：我个人只知道 1 个 C++ 解释器，由 Root 使用（CINT，在 CERN 开发）。 这让我想知道为什么这么少，显而易见的答案是 C++ 是一种解析起来非常复杂的语言。 没有一个头脑正常的人会费心从头开始编写一个 C++ 解析器……
这里有一些重要的问题：您的目标是什么？为什么 C/C++ 解释器是该问题的最佳（或至少是相当好的）解决方案？ “你的目标是什么？” 以及“为什么 X 是一个好的解决方案？” 在浪费宝贵的时间实施解决方案之前，通常是首先要问的非常好的问题。
由于多种原因，C/C++ 作为基于控制台的解释语言是不切实际的，人们通常不喜欢浪费时间来实现不切实际的工具（好吧，也许是那些有大量时间玩耍和学习的人和/或那些谁无法预见不切实际的方面）。
与 C/C++ 相比，使用动态类型变量和“动态链接函数”实现动态语言（如 python）的解释器要容易几个数量级，并且不易出错。 为简单的动态语言编写整个解析器、编译器、解释器非常容易和快速。 解释器本身不必具有很高的性能，因为它通常仅用于执行高级逻辑、粘合代码。 如果某些内容对性能至关重要，那么您可以将其实现为解释器的本机 C/C++ 模块，并将其绑定到动态解释语言。 在我看来，您还没有真正考虑过 C/C++ 解释器会出现的问题。 我可以写一本关于他们的小说。 以下是最有趣且足够大的问题：
C/C++ 需要前向声明。 在实用的解释语言中，没有前向声明，也没有单独的声明/定义。 但这只是一个更严重问题的一小部分：C/C++ 作为解释性语言使用起来过于冗长，不切实际。 这是一组既涉及语言设计问题又涉及解释语言实际可用性问题的问题。 在 python 中，我可以轻松定义一个 X 函数来调用一个不存在的 Y 函数，并且我可以稍后定义这个 Y 函数。 然后我可以执行 X。稍后，如果我愿意，我可以完全更改 Y 的定义（也许使用一些新的默认初始化参数以向后兼容以前的定义），并且 X 的另一次执行立即使用新的 Y 定义。 即使 X 调用尚未定义的 Z 函数，我也可以执行 X，并且如果使用实际输入参数执行 X 实际上并未运行到调用 Z 的分支，那么这不是问题。如果我更改由许多先前定义的函数（例如作为内联函数）使用的非常基本的模板（例如：动态数组）的定义，C++ 解释器会发生什么？ 如何找出解释器中哪些代码块需要重新编译才能使用新的内联函数？ 如果使用新定义重新编译其中一些函数失败，会发生什么情况？ 对于像 python 这样的动态语言，你不会遇到这样的严重问题。 在非动态解释器中处理这样的场景将是一个巨大的问题，而这只是两个“简单/基本”的问题，这只是冰山一角。 我从事 C/C++ 编程已有十多年了，但从未觉得需要 C/C++ 解释器。
引用：然而，C++ 解析器作为编译器的一部分存在，其中一些是开源的。 我突然想到，也许可以解释解析器实时发出的汇编代码。 这就像一个 JIT 编译器，它发出由虚拟机解释的字节码。 我想到的一个问题是使用不同的源文件，否则会导致需要链接多个目标文件。 这确实是一个限制，但如果你问我的话，这并不是一个非常严重的限制。
我开始写一个答案，但它变得太长且复杂，因为它沿着许多不同的横截面分析了您的问题。 相反，我在这里只写下我的一些结论。
您应该回答我在上一段中提出的问题。 从你的问题来看，我认为也许你的目标只是创造 A 投入最少工作量的 C++ 解释器 – 我认为这是因为您想重用现有编译器中的东西（编译单元、目标文件）。 我的问题是，当人们不得不做他们不喜欢的事情时，他们会做一些“投入最少的工作”的事情。 另一方面，如果他们做某事只是为了好玩、作为一种爱好或有特定的目的，那么他们通常不介意做很多工作。 对于 C/C++ 解释器，所有解决方案似乎都涉及大量工作。
根据编译器和编译器设置，目标文件可能包含您需要的其他内容。 它们没有标准化，甚至同一个编译器也可以通过某些设置（如 LTCG）将完全无用的垃圾放入其中。 IMO 编写一个后端来发出您需要的内容而不是尝试从对象文件中解析它会更实际。
解决方案4
我推测的原因是：似乎没有人有必要这样做。 也就是说，你也许能够在你的花园里建造一座埃菲尔铁塔，假设你有空间、材料、人员、足够好的地面等等，并且你可以为了自己的乐趣而这样做。 😉
C 与 C++ 的区别如 C++ 标准中所述：
除了 C 提供的功能之外，C++ 还提供其他数据类型、类、模板、异常、命名空间、运算符重载、函数名重载、引用、自由存储管理运算符和其他库功能。
如果使用 C++11，您可能会添加 lambda 表达式和其他几个部分，所有这些主要都是语法糖，因为它们抽象了主要与解析器相关的东西，并且也可以通过其他方式完成（如果不是乏味的话）。
解析上述功能的运行时项目的结果是
– 附加数据类型：一些更多的内置字符/数字类型
– 类：扩展实例函数 this 范围
– 类：以基类作为派生类的子对象的继承
– 类：特殊的隐式函数调用（ctor、dtor 等）
– 类：用于虚函数调用的vtable
– 类：定义的顺序（大部分）在类中并不重要 – 仅名称查找受到影响
– 模板：根据类型或常量整数值生成的类或函数
– 例外：额外的控制流程，特别是清理簿记代码
– 命名空间：“语法糖”（定义和调用独特的类型、对象、函数）
– 重载：“语法糖”（解析器创建对正确函数的调用）
– 引用：“语法糖”，导致指针或根本没有运行时代码
– 新建/删除：低级内存 malloc/free 以及 ctor/dtor 调用
– 库：基于语言特征的项目集合
– lambda 表达式：“语法糖”（隐式函子类）
– …
有一些令人讨厌的细节问题需要克服，但从技术上讲，它可以被视为一个大大扩展的 C。
因此，如果您有一个 C++ 前端能够成功地转换为功能上等效的 C，那么您就达到了 CINT 的级别。 多个文件以及引用库和目标文件等问题并非 C++ 所独有，而是所有 C* 语言的共同事实。 因此，您可以重新使用这些语言的解释器的这些概念（CINT？）。
但同样，证明努力的合理性很大程度上取决于预期的“收益”。
干杯
和我
解决方案5
因为C++是一种庞大的编程语言。 实在是太复杂了。 解释器是为 Python、JavaScript 等语言创建的，不仅它们很简单，而且它们是用来解释的，它们是动态的。 第一个 Python 实现是解释器； 不是编译器。 原因不仅于此。 众所周知，C++ 在“编译”时比解释语言更快。 但您不能总是对 C++ 解释器抱有同样的期望。 C++ 是上下文相关的； C++ 非常庞大； C++ 包含泛型。 因此，语言的复杂性导致源代码的处理速度缓慢。 例如，请参阅 C++ 的编译速度。 如果你解释来源会发生什么？ 话虽这么说，一个经典的“hello world”程序可能不需要一段时间。 但是想想一个大量使用通用技术的程序吗？
但仍然有一些解释器，例如 CINT、Ch. 请参阅以下页面：
解决方案2
很难真正“解决”这个问题 – 在论坛上可能会更好，但这是我的 2c。
语言定义并不真正排除创建解释器，但 C++ 确实被设计为一种低级语言，可用于极其高效的代码。 该语言非常复杂，但并非不可能解析（据我所知，它确实需要 GLR 解析器或手写解析器）。 也就是说，C++ 的大部分优点来自于它可以用于高效的代码，并且可以在机器附近运行。 解释器通常用于高级任务，其中开发过程中的快速迭代比执行速度更重要。
简而言之，这将是一项繁重的工作，而且会像狗一样奔跑。
コメント