I am curious if anyone have used UnderC, Cint, Cling, Ch, or any other C++ interpreter and could share their experience.
8 回答
注意:下面的内容是 CINT 特有的,但考虑到它可能是使用最广泛的C++ 解释器,它可能对所有人都有效。
作为一个广泛使用 CINT 的粒子物理学研究生,我应该警告你远离。虽然它确实“起作用”,但它正处于被淘汰的过程中,而那些在粒子物理学中花了一年多时间的人通常会因为以下几个原因学会避免它:
由于其作为 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 可能是一个不错的选择。
我(大约一年前)玩过Ch并发现它非常好。
很久以前,我使用了一个名为 CodeCenter 的 C++ 解释器。它非常好,尽管它无法处理位域或花哨的指针修饰之类的事情。关于它的两个很酷的事情是您可以观察变量何时发生变化,并且您可以在调试时动态评估 C/C++ 代码。这些天来,我认为像 GDB 这样的调试器基本上也一样好。
很久以前,我使用了一个名为 Instant C 的产品,但我不知道它是否进一步发展
不久前,我查看了使用 ch 是否可以将其用于我负责的黑盒测试 DLL。不幸的是,我无法弄清楚如何让它从 DLL 加载和执行函数。再说一次,我没有那么积极,可能有办法。