
Cling – An interactive C++ interpreter built on top of LLVM and Clang - philonoist
https://root.cern.ch/cling
======
smueller1234
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!

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

~~~
tempay
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).

~~~
MereInterest
>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.

~~~
random_nick_xyz
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...](https://indico.cern.ch/event/567550/contributions/2628878/attachments/1511966/2358123/hep-
file-formats.pdf)

~~~
tempay
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](https://github.com/scikit-
hep/uproot)

~~~
random_nick_xyz
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](https://ep-dep-
sft.web.cern.ch/contributed-event/149099)

------
MereInterest
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...](https://root-forum.cern.ch/t/memory-leak-using-
interpreter/23616)

------
superbatfish
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...](https://mybinder.org/v2/gh/QuantStack/xeus-
cling/0.0.7?filepath=notebooks%2Fxcpp.ipynb)

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

------
ChickeNES
There's also ccons:
[https://github.com/asvitkine/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.

------
Mic92
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](https://github.com/inspector-repl/inspector)

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

~~~
KenoFischer
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.

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

~~~
MereInterest
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.

