c++ - 您是否使用过任何 C++ 解释器(不是编译器)？

Closed. This question does not meet Stack Overflow guidelines 。它目前不接受答案。












想改善这个问题吗？更新问题，使其成为 Stack Overflow 的 on-topic。

3年前关闭。



Improve this question




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

最佳答案

注意: 下面的内容是 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++ 不是用来解释的。例如，静态类型在编译期间为您带来了极大的优化 yield ，但如果只允许计算机在运行时查看它，则主要用于困惑和过度约束您的代码。如果您有幸能够使用解释型语言、学习 Python 或 Ruby，那么即使您已经了解 C++，您学习所需的时间也将少于您在 CINT 上的绊脚石。

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

顺便说一下，R​​OOT(以及 CINT)在相当现代的计算机上编译大约需要半个小时，并且偶尔会在更新版本的 gcc 上失败。这是一个多年前就发挥重要作用的包装，但现在它清楚地表明了它的年龄。查看源代码，您会发现数百个已弃用的 c 样式强制转换、类型安全方面的巨大漏洞以及大量使用全局变量。

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

关于c++ - 您是否使用过任何 C++ 解释器(不是编译器)？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/3383348/