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

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

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.

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:

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 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 http://root.cern.ch/">ROOT</a>;. 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.

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

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.

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

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. :)