Have you used any of the C++ interpreters (not compilers)?我很好奇是否有人使用UnderC，Cint，Cling，Ch或任何其他C ++解释器并可以分享他们的经验。 注意：以下内容是特定于CINT的，但是鉴于它可能是使用最广泛的C ++解释器，因此可能对所有这些都有效。 作为广泛使用CINT的粒子物理学研究生，我应该警告您。尽管它确实"有效"，但它正在逐步被淘汰，并且那些在粒子物理学上花费超过一年的人通常会由于以下几个原因而学会避免使用它： 由于它起源于C解释器，因此它无法解释C ++的某些最关键的组件。例如，模板并不总是有效，因此不鼓励您使用使C ++如此灵活和可用的东西。 它比最小优化的C ++慢(至少5倍)。 调试消息比g ++产生的消息更加隐秘。 作用域与已编译的C ++不一致：看到以下形式的代码是很常见的
而任何可用的C ++编译器都会抱怨 简而言之，CINT没有C ++的优点，也有所有缺点。 由于将CINT完全包含在ROOT框架中，因此实际上仍然使用CINT的事实很可能是历史性事故。早在它写出来时(20年前)，就真正需要一种用于交互式绘图/拟合的解释语言。现在有许多软件包可以满足这一角色，其中有数百个活跃的开发人员。 这些都不是用C ++编写的。为什么？很简单，C ++并不意味着要被解释。例如，静态类型为您在编译期间的优化工作中带来了巨大的收获，但是如果只允许计算机在运行时查看代码，则大多数情况会使代码混乱和过度约束。如果您能够使用解释性语言，学习Python或Ruby，那么即使您已经了解C ++，学习所需的时间也比花在绊脚石上的时间要少。 以我的经验，使用ROOT(必须安装该软件包才能运行CINT)的年长研究人员最终将ROOT库编译为普通的C ++可执行文件，以避免CINT。年轻一代的人要么遵循这种领导，要么使用Python编写脚本。 顺便说一句，在相当现代的计算机上编译，ROOT(以及CINT)大约需要半小时，并且有时会因较新版本的gcc而失败。这个软件包在很多年前就已经发挥了重要作用，但是现在它清楚地表明了它的年龄。查看源代码，您会发现数百个不赞成使用的c样式强制转换，类型安全性方面的巨大漏洞以及对全局变量的大量使用。 如果您要编写C ++，请按照要编写的方式编写C ++。如果您绝对必须具有C ++解释器，那么CINT可能是一个不错的选择。 Cern基于clang的C ++解释器项目非常有帮助-这是一种基于20年ROOT cint经验的新方法，它相当稳定，并由Cern专家推荐。 这是一个不错的Google Talk：介绍cling，这是一种基于clang / LLVM的C ++解释器。 cint是粒子物理分析程序包ROOT的命令处理器。我经常使用它，对我来说效果很好。 它相当完整，并且可以很好地与已编译的代码配合使用(您可以加载已编译的模块以在解释器中使用...) 后期编辑：：从后来的副本中复制，因为有关该问题的发帖者似乎不想在此处发布：igcc。从未亲自尝试过，但是该网页看起来很有希望。 我(大约一年前)与Ch一起玩耍，发现它相当不错。 也是很久以前，我使用了一个名为Instant C的产品，但我不知道它是否会进一步发展 很久以前，我使用了一个名为CodeCenter的C ++解释器。这很不错，尽管它不能处理位域或奇特的指针修饰之类的事情。关于它的两个很酷的事情是，您可以观察变量何时更改，并且可以在调试时动态评估C / C ++代码。这些天来，我认为像GDB这样的调试器基本上一样好。 有一个名为c-repl的程序，该程序通过使用GCC将代码重复编译到共享库中，然后加载生成的对象来工作。考虑到Ubuntu仓库中的版本是用Ruby编写的(当然不包括GCC)，而最新的git是在Haskell中，它的发展似乎很快。 :) 我看了一会儿使用ch，看看是否可以将它用于我负责的黑盒测试DLL。不幸的是，我不太清楚如何从DLL加载和执行它。再说一次，我不是那么有动力，很可能有办法。 |
