你有没有使用任何的C ++解释器（而不是编译器）？
我很好奇是否有人使用过UnderC，Cint，Cling，Ch或其他C ++解释器，并且可以分享他们的经验。
cint是粒子物理分析软件包ROOT的命令处理器。 我经常使用，对我来说效果很好。
这是相当完整的，并且与编译代码相处得很好（你可以加载编译模块以供在解释器中使用…）
后期编辑::复制后来重复，因为这个问题上的海报似乎并不想在这里发表： igcc 。 从来没有尝试过，但网页看起来很有希望。
注意：接下来的是CINT特有的，但是鉴于它可能是使用最广泛的 C ++解释器，它可能对它们都是有效的。
作为广泛使用CINT的粒子物理的研究生，我应该警告你。 虽然它“起作用”，但它正在逐渐被淘汰 ，那些在粒子物理领域待了一年多的人通常会学会避免这个问题，原因如下：
-
由于其作为C解释器的根源，它不能解释C ++的一些最关键的组件。 例如，模板并不总是能够工作，所以你会不愿意使用C ++如此灵活和可用的东西。
-
它比最低限度优化的C ++要慢（至less是5倍）。
-
debugging信息比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年前），真正需要用于交互式绘图/拟合的解释性语言。 现在有很多软件包可以填补这个angular色，其中很多软件包有数百个活跃的开发者。
这些都不是用C ++编写的。 为什么？ 很简单，C ++并不意味着被解释。 例如，静态types在编译过程中会为您带来巨大的优化收益，但是如果只允许计算机在运行时看到它，那么大多数情况下会导致混乱和过度限制您的代码。 如果你有能力使用解释型语言的好处，学习Python或Ruby，即使你已经了解C ++，学习所花费的时间也不会超过CINT的绊脚石。
根据我的经验，使用ROOT（必须安装运行CINT的软件包）的老研究人员最终将ROOT库编译为正常的C ++可执行文件，以避免CINT。 那些在年轻一代或者跟随这个领导或者使用Python来编写脚本。
顺便说一下，ROOT（因此CINT）花费大约半个小时才能在一台相当现代的计算机上进行编译，偶尔也会出现新版本的gcc失败的情况。 这是一个多年前就有重要用途的软件包，但现在已经清楚地显示出它的年龄。 研究源代码，你会发现数以百计的被弃用的c风格的转换，types安全的巨大漏洞，以及大量使用全局variables。
如果您要编写C ++，那么编写C ++就是为了编写它。 如果你绝对必须有一个C ++解释器，CINT可能是一个不错的select。
Cern基于铿锵的C ++解释器项目 ，是基于20年ROOT cint经验的新方法 ，相当稳定，由Cern推荐。
这里有个很棒的Google Talk：介绍clang，一个基于clang / LLVM的C ++解释器 。
我（大约一年前）和Ch一起玩，发现它很好。
很久以前，我使用了一个名为CodeCenter的C ++解释器。 这是相当不错的，虽然它不能处理像位字段或幻想指针混乱的东西。 关于它的两件很酷的事情是，你可以观察variables何时改变，并且可以在debugging的时候随时评估C / C ++代码。 现在，我认为像GDB这样的debugging器基本上是一样的。
不久之前，我用了一个叫做Instant C的产品，但是我不知道它有没有进一步发展
我回头看了一下，看看我是否可以将它用于我负责的黑盒testingDLL。 不幸的是，我不知道如何让它加载和执行DLL中的函数。 再说一次，我不是那么有动力，也许还有一个办法。
有一个叫做c-repl的程序，它通过使用GCC反复编译你的代码到共享库中，然后加载结果对象。 考虑到 Ubuntu 版本库中的版本是用Ruby编写的（当然不包括GCC），而最新的git是在Haskell中，它似乎在迅速发展。 🙂
