您是否使用过任何 C++ 解释器（不是编译器）？ [关闭]答案

【问题标题】：Have you used any of the C++ interpreters (not compilers)? [closed]您是否使用过任何 C++ 解释器（不是编译器）？ [关闭]
【发布时间】：2010-09-09 07:57:37
【问题描述】：

我很好奇是否有人使用过 UnderC、Cint、Cling、Ch 或任何其他 C++ 解释器并可以分享他们的经验。

【问题讨论】：

@GeorgFritzsche 这个问题是关于 C++，而不是 C。
投票结束，因为范围太广。

标签： c++ interpreter read-eval-print-loop

【解决方案1】：

clingCern 的项目是基于clang 的 C++ 解释器 - 这是基于 20 年的ROOT cint经验的新方法 em> 而且它相当稳定，受到 Cern 人员的推荐。

这里很好Google Talk: Introducing cling, a C++ Interpreter Based on clang/LLVM。

【讨论】：

Cling 实际上是通过交互编译来工作的，它更像是一个 JIT 编译器而不是解释器。另外，作为一个“CERN 人”，我觉得有必要对“CERN 人推荐”发表评论：我们中的许多人会争辩说，在 ROOT 20 年后的主要教训是基于单一语言 (C++) 的单体软件 (ROOT)是一个错误。对于那些继续将 C++ 作为万能语言的人来说，Cling 是一个很好的拐杖，但我们并不是都在另一个 C++ 解释器上蹒跚地远离 CINT：对于相互渗透的代码，你可以做得比 C++ 好得多, 使用 Python 或 Ruby。

【解决方案2】：

注意：以下内容是特定于 CINT 的，但考虑到它可能是最多的 widely used C++ 解释器，它可能对所有人都有效。

作为一名广泛使用 CINT 的粒子物理学研究生，我应该警告你远离。虽然它确实“有效”，但它is in the process of being phased out，而那些在粒子物理学中花了一年多的时间的人通常会出于以下几个原因学会避免它：

由于它作为 C 解释器的根源，它无法解释 C++ 的一些最关键的组件。例如，模板并不总是有效，因此您将不鼓励使用使 C++ 如此灵活和可用的东西。
它比最低优化的 C++ 慢（至少 5 倍）。
调试消息比 g++ 生成的消息要神秘得多。
作用域与编译后的 C++ 不一致：这种形式的代码很常见
```
if (energy > 30) { 
    float correction = 2.4;
}
else {
    float correction = 6.3;
}

somevalue += correction; 
```
虽然任何工作的 C++ 编译器都会抱怨 correcton 超出范围，但 CINT 允许这样做。结果是 CINT 代码不是真正的 C++，只是看起来像它的东西。

简而言之，CINT 没有 C++ 的所有优点，但除了所有缺点外，还有一些缺点。

由于包含在 ROOT 框架中，CINT 仍然被使用的事实可能更像是一个历史事故。回到它写成的时候（20 年前），确实需要一种用于交互式绘图/拟合的解释语言。现在有许多软件包可以充当这个角色，其中许多软件包拥有数百名活跃的开发人员。

这些都不是用 C++ 编写的。为什么？很简单，C++ 不是用来解释的。例如，静态类型在编译期间为您带来了极大的优化收益，但如果只允许计算机在运行时查看代码，则主要是为了使您的代码变得混乱和过度约束。如果您能够使用解释语言，学习 Python 或 Ruby，那么即使您已经了解 C++，您学习所花费的时间也将少于您在 CINT 上的绊脚石。

根据我的经验，使用 ROOT（运行 CINT 必须安装的软件包）的老研究人员最终会将 ROOT 库编译成普通的 C++ 可执行文件以避免 CINT。年轻一代的人要么效仿这一做法，要么使用 Python 编写脚本。

顺便说一句，ROOT（以及 CINT）在相当现代的计算机上编译大约需要半小时，并且偶尔会因 gcc 的较新版本而失败。这是一个在多年前起到重要作用的包裹，但现在它清楚地表明了它的时代。查看源代码，您会发现数百个已弃用的 c 样式转换、类型安全方面的巨大漏洞以及大量使用全局变量。

如果您要编写 C++，请按照应编写的方式编写 C++。如果您绝对必须拥有 C++ 解释器，那么 CINT 可能是一个不错的选择。

【讨论】：

虽然您对 cint 的所有抱怨都是完全正确的（并且您错过了一些），但您可以相信 PAW 的 COMIS 解释器要糟糕得多。此外，PAW 提供了一个足够的交互式绘图环境——它只是存在您对 fortran 77 编码风格所期望的缩放问题。
@dmckee 相信我，我很高兴我们没有与 PAW 合作。我的意思不是说 CINT 比 所有事情 都差，只是有很多事情会更好。
怎么会慢？
@Sergei 我不知道我是否理解你：解释器比编译代码慢
@Shep，不只是编译器的包装吗？您可能可以设置您想要的优化（我猜 -O0 是默认设置，以获得更好的交互性和增量链接）。 root.cern.ch/download/R2002/Cint2002.pdf - 提到了优化。

【解决方案3】：

cint 是粒子物理分析包ROOT 的命令处理器。我经常使用它，对我来说效果很好。

它相当完整，与编译后的代码配合得很好（您可以加载编译后的模块以在解释器中使用......）

后期编辑:: 复制自后来的副本，因为有关该问题的海报似乎不想在此处发布：igcc。从未亲自尝试过，但网页看起来很有希望。

【讨论】：

我认识几个物理专业的研究生，他们的大部分编码都是在 cint/root 中完成的，虽然他们并不总是有好的说法，但它满足了他们对性能和灵活性的需求。跨度>
嗯，它是 c++，由于需要构建 interperter二进制代码字典而增加了一层复杂性。加上根类树很痛苦。但是 cint 有效。它比 COMIS 在 cernlib 时代的表现要好得多。
@littlenag 说root“满足[我们的]需要”有点大方。该框架在几个基本级别上存在严重缺陷，并且只会继续广泛使用，因为它完全是非模块化的，因此几乎不可能删除。当您只想读取数据文件时，CINT 是您必须安装的主要示例。

【解决方案4】：

我（大约一年前）玩过Ch，发现它非常好。

【讨论】：

【解决方案5】：

很久以前，我使用了一个名为 CodeCenter 的 C++ 解释器。它非常好，尽管它无法处理位域或花哨的指针修饰之类的事情。关于它的两个很酷的事情是您可以观察变量何时发生变化，以及您可以在调试时动态评估 C/C++ 代码。这些天来，我认为像 GDB 这样的调试器基本上一样好。

【讨论】：

解释器遇到模板实例会怎么做？（或其他预处理业务）。是否有某种程度的预编译/预处理来处理模板或预处理器？
是的，所有 CPP 内容和模板都是被解释语言的一部分。很不错。

【解决方案6】：

很久以前我也使用过名为 Instant C 的产品，但我不知道它是否进一步发展

【讨论】：

【解决方案7】：

前段时间我研究了使用 ch 是否可以将其用于我负责的 DLL 的黑盒测试。不幸的是，我无法弄清楚如何让它从 DLL 加载和执行函数。话又说回来，我没有那么积极，很可能有办法。

【讨论】：

【解决方案8】：

有一个名为c-repl 的程序，它通过使用 GCC 将代码重复编译到共享库中，然后加载生成的对象来工作。考虑到 Ubuntu 存储库中的 the version 是用 Ruby 编写的（当然不包括 GCC），而 latest git 是在 Haskell 中，它似乎正在迅速发展。 :)

【讨论】：