Question

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

Answer 1

注意：后面的内容是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 ++的优点，而且还有一些缺点。

由于CINT包含在ROOT框架中，因此CINT仍在使用的事实可能更具历史意外。回到它写的时候（20年前），真正需要一种用于交互式绘图/拟合的解释语言。现在有很多软件包可以填充这个角色，其中很多都有数百个活跃的开发人员。

这些都不是用C ++编写的。为什么？很简单，C ++并不意味着被解释。例如，静态类型可以在编译期间为优化带来巨大的收益，但如果只允许计算机在运行时看到它，则主要是为了使代码混乱和过度约束。如果您能够使用解释性语言，学习Python或Ruby，那么即使您已经了解C ++，您学习的时间也会比您在CINT上失败的要少。

根据我的经验，使用ROOT（您必须安装以运行CINT的软件包）的老研究人员最终将ROOT库编译为普通的C ++可执行文件以避免CINT。年轻一代的人要么遵循这个主导，要么使用Python来编写脚本。

顺便说一句，ROOT（以及CINT）大约需要半个小时才能在相当现代的计算机上进行编译，并且偶尔会因为新版本的gcc而失败。它是多年前一个重要目的的包装，但现在它显然已经显示出它的年龄。查看源代码，你会发现数百个不赞成的c风格的演员表，类型安全的巨大漏洞，以及大量使用全局变量。

如果您要编写C ++，请编写C ++，因为它是要编写的。如果你绝对必须拥有C ++解释器，那么CINT可能是一个不错的选择。

Answer 2

cling Cern的项目基于clang的C ++解释器 - 基于20年的经验，它是新方法 ROOT cint ，它非常稳定，并由Cern家伙推荐。

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

Answer 3

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

它相当完整并且可以很好地使用已编译的代码（您可以加载已编译的模块以便在解释器中使用...）

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

Answer 4

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

Answer 5

很久以前，我使用了一个名为CodeCenter的C ++解释器。这很不错，虽然它无法处理像bitfields或花式指针修改这样的东西。关于它的两个很酷的事情是，你可以观察变量何时发生变化，以及你可以在调试时动态评估C / C ++代码。这些天，我认为像GDB这样的调试器基本上也一样好。

Answer 6

很久以前我使用的产品叫Instant C，但我不知道它是否曾经进一步发展

Answer 7

我看了一会儿使用ch，看看我是否可以用它来测试我负责的黑盒测试DLL。不幸的是，我无法弄清楚如何从DLL加载和执行函数。然后，我没有那么积极，可能有办法。

Answer 8

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

你使用过任何C ++解释器（不是编译器）吗？

8 个答案: