您使用过c++解释器(不是编译器)吗?

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

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

8 个解决方案

#1

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

注意:下面的内容比较简单，但是考虑到它可能是最广泛使用的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，我应该警告你。虽然它确实“有用”，但它正在逐步淘汰，那些花了一年多时间研究粒子物理学的人通常会因为以下几个原因而避免使用它:

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.

由于它的根是一个C解释器，它不能解释c++的一些最重要的组件。例如，模板并不总是起作用的，因此不鼓励您使用使c++变得如此灵活和可用的东西。
It is slower (by at least a factor of 5) than minimally optimized C++.

它比最小优化的c++慢(至少慢5倍)。
Debugging messages are much more cryptic than those produced by g++.

调试消息比g++产生的消息要复杂得多。
Scoping is inconsistent with compiled C++: it's quite common to see code of the form

作用域与编译后的c++不一致:常见的情况是看到表单的代码
```
if (energy > 30) { 
    float correction = 2.4;
}
else {
    float correction = 6.3;
}

somevalue += correction; 
```
whereas any working C++ compiler would complain that correcton has gone out of scope, CINT allows this. The result is that CINT code isn't really C++, just something that looks like it.

尽管任何正在使用的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仍然被使用的事实很可能是一个历史的意外，因为它包含在根框架中。早在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，那么学习它所花费的时间将比您在CINT上所花费的时间要少，即使您已经了解c++。

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)的年长的研究人员最终将根库编译成普通的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.

顺便说一句，ROOT(以及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++解释器，CINT可能是一个不错的选择。

#2

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

cint是粒子物理分析包根的命令处理器。我经常使用它，它对我来说非常有用。

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。从来没有亲自尝试过，但是这个网页看起来很有前途。

#3

There is cling Cern's project of C++ interpreter based on clang - it's new approach based on 20 years of experience in ROOT cint and it's quite stable and recommended by Cern guys.

欧洲核子研究中心有一个基于clang的c++解释器项目——它是基于根cint 20年的经验的新方法，它是相当稳定的，并且被Cern的人推荐。

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

这里有一个很棒的谷歌演讲:介绍依附，一个基于clang/LLVM的c++解释器。

#4

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

我(大约一年前)和Ch一起玩，发现它很不错。

#5

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这样的调试器基本上也一样好。

#6

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

同样在很久以前，我使用了一个叫做Instant C的产品，但我不知道它是否会进一步发展

#7

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中加载和执行函数。再说一遍，我没有那么有动力，也许有办法。

#8

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

有一个叫做c-repl的程序，它通过使用GCC将代码反复编译到共享库中，然后加载结果对象来工作。考虑到Ubuntu存储库中的版本是用Ruby编写的(当然不包括GCC)，而最新的git是在Haskell中编写的，它似乎正在快速发展。:)

#1