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

Question

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

Sickler

@GeorgFritzsche This question is about C++, not C. – Sabellian

Voting to close as too broad. – Gassaway

Answer 1

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.

Egocentrism

Cling actually works by compiling interactively, it's more of a JIT compiler than an interpreter. Also, as a "CERN guy" I feel obliged to comment on "recommended by CERN guys": many of us would argue that the main lesson after 20 years of ROOT is that monolithic software (ROOT) based around a single language (C++) is a mistake. Cling is a good crutch for those who continue to warship C++ as the be-all-end-all of languages, but we aren't all hobbling away from CINT on another C++ interpreter: for interpenetrated code, you can do far better than C++, use Python or Ruby. – Wowser

Answer 2

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.

Wowser

While all your complaints about cint are perfectly valid (and you missed a few), you can take my word that the COMIS interpreter for PAW was much worse. Also that PAW provided a adequate environment of interactive plotting---it just had the scaling problems you would expect from a fortran 77 style of coding. – Stheno

@dmckee Believe me, I'm glad we're not working with PAW. My point isn't that CINT is worse than everything, only that there are many things which would be better. – Wowser

how can it be slower? – Ventricose

@Sergei I don't know if I understand you: interpreters are slower than compiled code – Wowser

@Shep, isn't just a wrapper around compiler? You probably may set optimization you want (I guess -O0 is default for better interactivity and incremental linking). root.cern.ch/download/R2002/Cint2002.pdf - optimization mentioned. – Ventricose

@Sergei, no, cint is a full-blown interpreter. As another answer points out, it's been replaced by a wrapper over a compiler, but the question was about interpreters. – Wowser

Answer 3

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.

Stheno

I know several graduate students in physics that do the majority of their coding in cint/root, and while they don't always have nice things to say it meets their needs for performance and flexibility. – Commutation

Well, it is c++ with an add layer of complexity from needing to build the interperter<-->binary-code dictionaries. Plus the root class tree is a pain. But cint works. It works a lot better than COMIS did in the cernlib days. – Stheno

@littlenag To say root "meets [our] needs" is a little generous. The framework is horribly flawed on several basic levels, and only continues to see widespread use because it's completely non-modular and thus nearly impossible to remove. CINT is a prime example of something you have to install when all you want to do is read in a data file. – Wowser

Answer 4

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

Showing

Answer 5

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

Mccord

Will you provide some links? That would be really helpful. – Whittaker

Answer 6

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.

Djerba

What would the interpreter do when it encountered a template instance? (or other preprocessing business). Was there some level of precompilation/preprocessing to handle templates or the preprocessor? – Mazer

Yes, all the CPP stuff and templates were all part of the language being interpreted. Pretty nice. – Djerba

Answer 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.

Asur

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

Landa