您是否使用过任何 C++ 解释器（不是编译器）？

Have you used any of the C++ interpreters (not compilers)?

提问by Allan Wind

I am curious if anyone have used UnderC, Cint, Cling, Ch, or any other C++ interpreter and could share their experience.

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

回答by Shep

NOTE:what follows is rather CINT specific, but given that its probably the most widely usedC++ interpreter it may be valid for them all.

注意：下面的内容是 CINT 特定的，但鉴于它可能是使用最广泛的C++ 解释器，它可能对它们都有效。

As a graduate student in particle physics who's used CINT extensively, I should warn you away. While it does "work", it is in the process of being phased out, and those who spend more than a year in particle physics typically learn to avoid it for a few reasons:

作为一名广泛使用 CINT 的粒子物理学研究生，我应该警告你。虽然它确实“有效”，但它正在被逐步淘汰，而那些在粒子物理学中花费一年多时间的人通常会出于以下几个原因学会避免它：

1. Because of its roots as a C interpretor, it fails to interpret some of the most critical components of C++. Templates, for example, don't always work, so you'll be discouraged from using things which make C++ so flexible and usable.

2. It is slower (by at least a factor of 5) than minimally optimized C++.

3. Debugging messages are much more cryptic than those produced by g++.

4. Scoping is inconsistent with compiled C++: it's quite common to see code of the form

   if (energy > 30) { 
       float correction = 2.4;
   }
   else {
       float correction = 6.3;
   }
   
   somevalue += correction; 
   

   whereas any working C++ compiler would complain that correctonhas gone out of scope, CINT allows this. The result is that CINT code isn't really C++, just something that looks like it.

1. 由于它起源于 C 解释器，它无法解释 C++ 的一些最关键的组件。例如，模板并不总是有效，因此您会被劝阻不要使用使 C++ 如此灵活和可用的东西。

2. 它比最低限度优化的 C++ 慢（至少 5 倍）。

3. 调试消息比 g++ 产生的消息要神秘得多。

4. 作用域与编译后的 C++ 不一致：看到形式的代码很常见

   if (energy > 30) { 
       float correction = 2.4;
   }
   else {
       float correction = 6.3;
   }
   
   somevalue += correction; 
   

   虽然任何工作的 C++ 编译器都会抱怨correcton超出范围，但 CINT 允许这样做。结果是 CINT 代码并不是真正的 C++，只是看起来像它的东西。

In short, CINT has none of the advantages of C++, and all the disadvantages plus some.

简而言之，CINT 没有 C++ 的任何优点，所有的缺点加上一些。

The fact that CINT is still used at all is likely more of a historical accident owing to its inclusion in the ROOT framework. Back when it was written (20 years ago), there was a real need for an interpreted language for interactive plotting / fitting. Now there are many packages which fill that role, many which have hundreds of active developers.

由于 CINT 包含在 ROOT 框架中，CINT 仍在使用的事实可能更多地是历史事故。早在编写它的时候（20 年前），就真的需要一种用于交互式绘图/拟合的解释性语言。现在有许多包可以填补这个角色，其中许多包有数百名活跃的开发人员。

None of these are written in C++. Why? Quite simply, C++ is not meant to be interpreted. Static typing, for example, buys you great gains in optimization during compilation, but mostly serves to clutter and over-constrain your code if the computer is only allowed to see it at runtime. If you have the luxury of being able to use an interpreted language, learn Python or Ruby, the time it takes you to learn will be less than that you loose stumbling over CINT, even if you already know C++.

这些都不是用 C++ 编写的。为什么？很简单，C++ 不是用来解释的。例如，静态类型在编译期间为您带来了极大的优化收益，但如果只允许计算机在运行时查看它，则主要用于混乱和过度约束您的代码。如果您有幸能够使用解释型语言、学习 Python 或 Ruby，那么即使您已经了解 C++，您学习所需的时间也将少于您在 CINT 上的绊脚石。

In my experience, the older researchers who work with ROOT (the package you must install to run CINT) end up compiling the ROOT libraries into normal C++ executables to avoid CINT. Those in the younger generation either follow this lead or use Python for scripting.

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

Incidentally, ROOT (and thus CINT) takes roughly half an hour to compile on a fairly modern computer, and will occasionally fail with newer versions of gcc. It's a package that served an important purpose many years ago, but now it's clearly showing it's age. Looking into the source code, you'll find hundreds of deprecated c-style casts, huge holes in type-safety, and heavy use of global variables.

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

If you're going to write C++, write C++ as it's meant to be written. If you absolutely must have a C++ interpretor, CINT is probably a good bet.

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

回答by Grzegorz Wierzowiecki

There is clingCern's projectof C++ interpreter based on clang- it's new approachbased on 20 years of experience in ROOT cintand it's quite stable and recommended by Cern guys.

还有就是坚持CERN的项目基于C ++解释的铛-这是新的方法基于20年的经验ROOT CINT这是相当稳定的，由欧洲核子研究中心的家伙建议。

Here is nice Google Talk: Introducing cling, a C++ Interpreter Based on clang/LLVM.

这是不错的Google Talk：Introducing cling，一个基于 clang/LLVM 的 C++ 解释器。

回答by dmckee --- ex-moderator kitten

cint is the command processor for the particle physics analysis package ROOT. I use it regularly, and it works very well for me.

cint 是粒子物理分析包ROOT的命令处理器。我经常使用它，它对我来说效果很好。

It is fairly complete and gets on well with compiled code (you can load compiled modules for use in the interpreter...)

它相当完整并且可以很好地处理编译代码（您可以加载编译模块以在解释器中使用......）

late edit::Copied from a later duplicate because the poster on that questions didn't seem to want to post here: igcc. Never tried it personally, but the web page looks promising.

后期编辑::从后来的副本中复制，因为有关该问题的海报似乎不想在这里发布：igcc。从未亲自尝试过，但网页看起来很有希望。

回答by Alan

I have (about a year ago) played around with Chand found it to be pretty good.

我（大约一年前）和Ch一起玩过，发现它非常好。

回答by jfm3

Long ago, I used a C++ interpreter called CodeCenter. It was pretty nice, although it couldn't handle things like bitfields or fancy pointer mangling. The two cool things about it were that you could watch when variables changed, and that you could evaluate C/C++ code on the fly while debugging. These days, I think a debugger like GDB is basically just as good.

很久以前，我使用了一个名为 CodeCenter 的 C++ 解释器。它非常好，虽然它无法处理位域或花哨的指针重整之类的事情。关于它的两个很酷的事情是您可以观察变量何时发生变化，并且您可以在调试时即时评估 C/C++ 代码。现在，我认为像 GDB 这样的调试器基本上也一样好。

回答by user11269

Also long ago I used a product call Instant C but I don't know that it ever developed further

同样很久以前，我使用了一个名为 Instant C 的产品，但我不知道它有没有进一步发展

回答by Jon Trauntvein

I looked at using ch a while back to see if I could use it for black box testing DLLs for which I am responsible. Unfortunately, I couldn't quite figure out how to get it to load and execute functions from DLLs. Then again, I wasn't that motivated and there may well be a way.

不久前，我查看了使用 ch 以查看是否可以将它用于我负责的黑盒测试 DLL。不幸的是，我无法弄清楚如何让它从 DLL 加载和执行函数。再说一次，我没有那么积极，很可能有办法。

回答by Matthew Flaschen

There is a program called c-replwhich works by repeatedly compiling your code into shared libraries using GCC, then loading the resulting objects. It seems to be evolving rapidly, considering the versionin Ubuntu's repository is written in Ruby (not counting GCC of course), while the latest gitis in Haskell. :)

有一个名为c-repl的程序，它通过使用 GCC 将代码重复编译到共享库中，然后加载生成的对象来工作。它似乎发展迅速，考虑到Ubuntu 存储库中的版本是用 Ruby 编写的（当然不包括 GCC），而最新的 git是用 Haskell编写的。:)