我很好奇是否有人使用过UnderC，Cint，Cling，Ch或任何其他C ++解释器，并且可以分享他们的经验。
我很好奇是否有人使用过UnderC，Cint，Cling，Ch或任何其他C ++解释器，并且可以分享他们的经验。
Answers:
注意：以下内容是特定于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 ++的优点，而是所有缺点加上一些缺点。
由于将CINT完全包含在ROOT框架中，因此实际上仍然使用CINT的事实很可能是历史性的事故。早在它写出来时（20年前），就真正需要一种交互式绘图/拟合的解释语言。现在有许多软件包可以满足这一角色，其中有数百个活跃的开发人员。
这些都不是用C ++编写的。为什么？很简单，C ++并不意味着要被解释。例如，静态类型可以在编译过程中为您带来优化方面的巨大收益，但是如果只允许计算机在运行时查看代码，则静态类型通常会使代码混乱和过度约束。如果您能够使用解释性语言，学习Python或Ruby，那么即使您已经了解C ++，学习所需的时间也比花在CINT上的时间少了很多。
以我的经验，使用ROOT（必须安装该软件包才能运行CINT）的年长研究人员最终将ROOT库编译为普通的C ++可执行文件，以避免CINT。年轻一代的人要么遵循这一指导，要么使用Python编写脚本。
顺便说一句，在相当现代的计算机上编译，ROOT（以及CINT）大约需要半小时，并且偶尔会因较新版本的gcc而失败。这个软件包在很多年前就已经发挥了重要作用，但是现在它清楚地表明了它的年龄。查看源代码，您会发现数百个不推荐使用的c样式强制转换，类型安全性方面的巨大漏洞以及对全局变量的大量使用。
如果您要编写C ++，请按照要编写的方式编写C ++。如果您绝对必须具有C ++解释器，那么CINT可能是一个不错的选择。