很久以前，我使用过一个名为 CodeCenter 的 C++ 解释器。它非常好，尽管它无法处理位域或花哨的指针损坏之类的事情。它的两个很酷的事情是，您可以观察变量何时发生变化，并且可以在调试时动态评估 C/C++ 代码。如今，我认为像 GDB 这样的调试器基本上也一样好。
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.
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.
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. :)
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.
顺便说一句，ROOT（以及 CINT）在相当现代的计算机上编译大约需要半个小时，并且在较新版本的 gcc 中偶尔会失败。这是一个多年前曾发挥过重要作用的包，但现在它清楚地显示出它的年龄。查看源代码，您会发现数百个已弃用的 c 风格转换、类型安全方面的巨大漏洞以及全局变量的大量使用。
如果您要编写 C++，请按照 C++ 的预期编写方式来编写。如果您绝对必须有一个 C++ 解释器，CINT 可能是一个不错的选择。
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.
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:
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.
It is slower (by at least a factor of 5) than minimally optimized C++.
Debugging messages are much more cryptic than those produced by g++.
Scoping is inconsistent with compiled C++: it's quite common to see code of the form
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.
In short, CINT has none of the advantages of C++, and all the disadvantages plus some.
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.
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++.
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.
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.
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.
cint is the command processor for the particle physics analysis package ROOT. I use it regularly, and it works very well for me.
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.
发布评论
评论（8）
我（大约一年前）玩过 Ch 并发现它非常好。
I have (about a year ago) played around with Ch and found it to be pretty good.
很久以前我使用过一个叫做 Instant C 的产品，但我不知道它有没有进一步发展
Also long ago I used a product call Instant C but I don't know that it ever developed further
很久以前，我使用过一个名为 CodeCenter 的 C++ 解释器。它非常好，尽管它无法处理位域或花哨的指针损坏之类的事情。它的两个很酷的事情是，您可以观察变量何时发生变化，并且可以在调试时动态评估 C/C++ 代码。如今，我认为像 GDB 这样的调试器基本上也一样好。
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.
我不久前研究过使用 cha，看看是否可以将它用于我负责的 DLL 的黑盒测试。不幸的是，我不太清楚如何让它加载并执行 DLL 中的函数。话又说回来，我没有那么积极性，但很可能有办法。
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.
有一个名为 c-repl 的程序，它的工作原理是使用以下命令重复将代码编译到共享库中GCC，然后加载生成的对象。考虑到 Ubuntu 存储库中的版本是用Ruby（当然不包括 GCC），而最新的 git 是在哈斯克尔。 :)
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. :)
有cling Cern的项目基于clang - 这是基于 ROOT cint 20 年经验的新方法，并且非常稳定并由 Cern 人员推荐。
这里有一个很好的 Google Talk：介绍 cling，一个基于 clang/LLVM 的 C++ 解释器。
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.
Here is nice Google Talk: Introducing cling, a C++ Interpreter Based on clang/LLVM.
注意：接下来的内容是 CINT 特定的，但考虑到它可能是最广泛使用的 C++ 解释器可能对它们都有效。
作为一名广泛使用 CINT 的粒子物理学研究生，我应该警告您不要这样做。虽然它确实“有效”，但它正在被已被淘汰，而那些在粒子物理学上花费了一年多时间的人通常会因为以下几个原因而学会避免它：
由于它的根源是 C 解释器，它无法解释一些最关键的组件C++ 的。例如，模板并不总是有效，因此您将不愿意使用使 C++ 如此灵活和可用的东西。
它比最低限度优化的 C++ 慢（至少慢 5 倍）。
调试消息比 g++ 生成的消息要神秘得多。
范围与已编译的 C++ 不一致：看到以下形式的代码很常见
尽管任何正在运行的 C++ 编译器都会抱怨
Correcton超出了范围，但 CINT 允许这样做。结果是 CINT 代码并不是真正的 C++，只是看起来像 C++。简而言之，CINT 没有 C++ 的优点，而且所有的缺点都加上了一些。
由于 CINT 被包含在 ROOT 框架中，因此它仍然被使用的事实可能更像是一个历史意外。当它被编写时（20 年前），确实需要一种用于交互式绘图/拟合的解释语言。现在有许多软件包可以填补这一角色，其中许多软件包拥有数百名活跃的开发人员。
这些都不是用 C++ 编写的。为什么？很简单，C++ 不应该被解释。例如，静态类型可以在编译期间为您带来巨大的优化收益，但如果只允许计算机在运行时查看代码，则主要会导致代码混乱和过度限制。如果您有幸能够使用解释性语言，学习 Python 或 Ruby，那么即使您已经了解 C++，您学习 CINT 所花费的时间也会少于您在 CINT 上遇到的困难。
根据我的经验，使用 ROOT（必须安装才能运行 CINT 的软件包）的老研究人员最终会将 ROOT 库编译成普通的 C++ 可执行文件以避免 CINT。年轻一代要么效仿这种做法，要么使用 Python 编写脚本。
顺便说一句，ROOT（以及 CINT）在相当现代的计算机上编译大约需要半个小时，并且在较新版本的 gcc 中偶尔会失败。这是一个多年前曾发挥过重要作用的包，但现在它清楚地显示出它的年龄。查看源代码，您会发现数百个已弃用的 c 风格转换、类型安全方面的巨大漏洞以及全局变量的大量使用。
如果您要编写 C++，请按照 C++ 的预期编写方式来编写。如果您绝对必须有一个 C++ 解释器，CINT 可能是一个不错的选择。
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.
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:
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.
It is slower (by at least a factor of 5) than minimally optimized C++.
Debugging messages are much more cryptic than those produced by g++.
Scoping is inconsistent with compiled C++: it's quite common to see code of the form
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.In short, CINT has none of the advantages of C++, and all the disadvantages plus some.
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.
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++.
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.
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.
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.
cint 是粒子物理分析包 ROOT 的命令处理器。我经常使用它，它对我来说非常有效。
它相当完整，并且与编译的代码相处得很好（您可以加载编译的模块以在解释器中使用...）
后期编辑::从后来的副本中复制，因为该问题的海报没有'似乎想在这里发帖：igcc。从未亲自尝试过，但网页看起来很有希望。
cint is the command processor for the particle physics analysis package ROOT. I use it regularly, and it works very well for me.
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.