Cling – An interactive C++ interpreter built on top of LLVM and Clang | Hacker News Reader

Cling – An interactive C++ interpreter built on top of LLVM and Clang

root.cern.ch

91 pointsphilonoist21 comments

Having had to deal with the insanity of its predecessor, CINT, a lot, I'm just really happy for all the particle physicists out there who depend on this (and ROOT)!

In fact, those of you that are into slightly bizarre code archaeology, have a look at the CINT and pre ROOT code prior to ROOT 6. We used to joke that ROOT was the then primary developer's learning project for migrating from FORTRAN to C++... Despite that, virtually every major contemporary particle physics experiment/analysis relies on ROOT!

I've never heard this before. Why? What is it they need from it?

The development was heavily influenced by what particle physics experiments required (developed at CERN and Fermilab so that makes sense), so the field naturally uses it essentially exclusively. It makes it easy to store C++ classes on disk, so after C++ was adopted as the language of the field post-Fortran, it became the natural tool. The event processing, fitting, and plotting tools were part of that “what particle physics experiments required” line too.

ROOT is very old (older than the first C++ specification) and being able to analyse data interactively and then compile the same for very performance sensitive applications was wonderful.

Unfortunately the previous interpreter (CINT) was a unpredictable mess of hacks with vast code bases dependent upon it. Cling has now taken over for most experiments and is much better.

For interactive work more and more people are using alternatives like python, but C++ and ROOT are deeply ingrained. Almost all data is stored in the ROOT file format and can only be read using ROOT. The library itself supports many common tasks which don’t have mature alternatives. Both of these points are slowly improving and benefiting from the wider data science community but ROOT will continue to be used for decades to come (the LHC experiments will run until at least mid 2030 with data being analysed for many years after).

>The library itself supports many common tasks which don’t have mature alternatives.

I'd be interested to hear what tasks don't have good alternatives. ROOT can plot histograms, but matplotlib does it much better. ROOT files are a halfway decent file format, but HDF5 is much better. ROOT has a cross-platform socket library, but boost::asio is much better.

The main reason I see for ROOT's continued usage is to compensate for the difficulty in adding new dependencies to a C++ project. With ROOT already being used in physics experiments, starting to use another of its submodules is simpler to do than pulling in a better-designed library.

Why ROOT file format is not just a halfway decent file format and why HDF5 is not much better:

https://indico.cern.ch/event/567550/contributions/2628878/at...

My biggest problem with ROOT files is the dependency on ROOT, which is tricky to distribute. Though projects like uproot[1] look promising and I think ROOT 7 might improve things.

[1] https://github.com/scikit-hep/uproot

AFAIK the ROOT file format was designed to be completely self descriptive. It can be read without ROOT. For instance: https://ep-dep-sft.web.cern.ch/contributed-event/149099

> ROOT can plot histograms, but matplotlib does it much better.

As much as I prefer matplotlib, quickly combining histograms with uncertainties and no regard for formatting is quicker with ROOT. 2D/3D/Profile histograms are also easier to quickly make.

> ROOT files are a halfway decent file format, but HDF5 is much better.

I believe the ROOT format is more generic and also does a good job of serialising generic objects, but this isn't really my area of expertise.

I also find that for all its many (many) faults, RooFit/RooStats doesn't have a generic alternative.

> ROOT files are a halfway decent file format, but HDF5 is much better.

I understand your point, but HDF5 isn't better. For one, HDF5 files tend to be considerably larger.

Oh gosh yeah. CINT wasn't a C++ interpreter. It was an interpreter for a language that sort of kind of looked like C++ if you squint heavily. The way it would hoist variables up to function scope was particularly annoying, because it breaks every instance of RAII.

Last I checked, it still leaks memory anytime a statement is evaluated [1], which isn't exactly desired behavior for an interpreter. It is much better than its predecessor, CINT, but I still wouldn't use it for anything in production.

[1] https://root-forum.cern.ch/t/memory-leak-using-interpreter/2...

One easy way to see it in action is to try it in your browser via the xeus-cling project. [1]

The live demo is here: https://mybinder.org/v2/gh/QuantStack/xeus-cling/0.0.7?filep...

[1]: https://github.com/QuantStack/xeus-cling

There's also ccons: https://github.com/asvitkine/ccons which as far as I can tell is C only, but I find the codebase much easier to follow.

I once started a prototype to integrate cling into a compiled project (like pry in ruby or import pdb; pdb.set_trace() in python). I currently work on different projects, but I would love to see, if somebody else could pick up the idea: https://github.com/inspector-repl/inspector

How does it differ from using a debugger and evaluating statements on the fly?

You can load in new code interactively, it has a JIT compiler, and physicists can use it.

It's the same kind of technology, though here they actually always load the interpreter into the process even when not used interactively, to allow things like dynamically loading additional code. They also use it to automatically compute file format layouts from C++ struct definitions, and it provides a C++ equivalent of eval().

One thing that I think is under-appreciated in this kind of thing is that a proper C++ repl is significantly less frustrating than a debugger. GDB's C++ mode is at best a poor emulation of the C++ language. LLDB does better because it reconstructs an actual C++ AST and runs it through clang but there's still a ton of limitation (e.g. you can't call any templates or inline functions from header files).

Interactive C++ is pretty fun, especially for prototyping. The biggest problem I generally run into is that APIs in C++ are not really designed to be used in that way (esp in libraries whose user's don't use these kinds of tools). Libraries in languages with interactive prompts tend to have APIs designed in such a way that you can get the simple thing done with very little code (one call, only the arguments you need, etc), while in C++ it's a lot more common to expect user's to copy/paste a snippet from the doc and adjust all the options they want to change. That works fine in an editor, but is pretty annoying in a prompt. The other thing I often run into is error handling. A lot of C++ libraries' error handling is to just call abort() (at best) or segfault, which again is mostly fine for a compiled problem, but is annoying in an interactive setting. You can work around that of course by catching the error/resetting state, but even then you often leave libraries in the wrong state.

It provides a similar environment to a Jupyter notebook. Building a program as you go and playing around in data. In fact cling provides a Jupyter kernel so you can write C++ in a Jupyter notebook as well.

I wish they wouldn't use the word interpreter, because as far as I'm aware this is not an interpreter. REPL would be the correct term, to my knowledge.

Agreed. As far as I can tell, it compiles each statement into machine code, then executes it. Not at all interpreting. This leads to some interesting bugs, such as a period when it was incompatible with gcc 5 or higher, because the clang backend couldn't yet output code compatible with gcc's new ABI.

Reply on news.ycombinator.com