Cling: Running C++ in an interpreter

http://blog.coldflake.com/posts/2012-08-09-On-the-fly-C%2B%2B.html

by coldgrnd • 14 years ago

113 48 14 years ago

blog.coldflake.com

shadyabhi• 14 years ago

So, what are it's limitations, if any?

coldgrnd4• 14 years ago

I'd say error recovery could be better. You often get kicked out of the session and than your environment is lost. Also: they claim the 'auto' keyword is implicit, does not seem to work for me. But it's pretty cool to use!

codedivine• 14 years ago

Well, for anyone interested in Cling, check out this Google tech talk: http://www.youtube.com/watch?v=f9Xfh8pv3Fs

This is a CERN project and it uses Clang from the LLVM project. The idea is simple: use the clang to generate LLVM and then use LLVM just-in-time compiler.

malkia• 14 years ago

Before that CINT was used (another C++ interpretter) - here is the page where they announce the future transition CINT -> CLING - http://root.cern.ch/drupal/content/cling

zenogaisis• 14 years ago

Why would I do that :S

jeremiep2• 14 years ago

Why not? It's great to quickly test C++, I have yet to find a developer who doesn't love a REPL for one.

C++ could also be used as an embedded extension language using something like this.

pmr_2• 14 years ago

I share your enthusiasm but there are limits. C++ compilation speed (and thus interpretation speed) will make it quite impossible to use it as an extension language. And while I like and use C++ a lot I don't think it is the right language for this purpose. It can do quite a lot of things, but working in a homogeneous language in your extensions as well as your core product doesn't have enough benefits compared to using a systems programming language and an extension language.

dbattaglia• 14 years ago

I can see it being helpful if you are working in C++ all day and need to try small things out. I use LinqPad for doing the same w/ C#, helps when you need to test out some smaller ideas w/o all the cruft of projects and references / includes / etc.

Mon_Ouie• 14 years ago

Although getting an interactive environment definitely is a nice thing, I'd argue you don't have to create a whole project directory, etc. to play with an idea; I usually write it in a single file.

deckiedan• 14 years ago

Could you not just use a project directory template? All you need really is a .c(xx|pp|whatever) file, a Makefile, and then the workflow for a new idea is:

cd ~/src;

cp -R c-idea-template foobar;

cd foobar;

$EDITOR test.c*

and in your editor (say vim) just run :make

or write a .sh file with all of the above in it so it's just one step. No complex install procedure, you get all your normal tools and stuff.

Alternaitvely, create a 'test projects' git(hub) project, with the files you want in it, and create a new branch for each idea. That way you get backups as well.

coldgrnd4• 14 years ago

@fferen, @jlarocco, @Mon_Ouie, @deckiedan: I know you can probably set up all you need within the blink of a second (using emacs or vim or a template setup). Actually I'm so hooked on this idea I even wrote my own rake based C/C++ Buildsystem (https://github.com/marcmo/cxxproject). But still sometimes I prefer not having to set up anything and not having to clean up anything after I end my experiments. ... Idea - drop into REPL and try out - exit - done.

fferen• 14 years ago

I just keep a fixed .cpp file with a bunch of common includes and directives, and alias the g++ command to link to common libraries, so my workflow goes:

> vim temp.cpp

> g++ temp.cpp

> ./a.out

Very similar to my process with Python, actually. Every time I use the REPL for some experimenting, the code ends up outgrowing it and I have to stuff it in a file anyway, so I may as well cut out the middleman to begin with. YMMV.

sanxiyn• 14 years ago

I too put the code in a file even in Python, but REPL is still valuable. I use "python -i" which runs your code (defines functions, classes, etc.) and then stop, and put you in that environment. This is very useful. It seems Cling could be used the same way: .x command.

voltagex_• 14 years ago

I must be reading the wrong Python tutorials. Thank you for this

rcfox• 14 years ago

If you don't need any special compiler flags, it's even simpler:

    make temp
    ./temp

jlarocco• 14 years ago

It's a cool idea, but his reason for creating it is kinda dumb.

Creating an entire "project" just to check a code snippet is just silly.

Just create a "testing" directory and throw your one off test files into it and compile/run them there.

I start mine with a comment explaining what I'm testing, why I'm testing it, and what special compilation flags are required, if any. I even have an Emacs macro that fills in the boilerplate includes and main function. The overhead involved is probably less than 15 seconds.

It has the advantages that I can test multiple compilers and I keep a history of the things I've tried.

geofft• 14 years ago

The ROOT project has been using CINT for ages. Talk to your favorite physicist friend -- they'll be confused why the CS crowd _doesn't_ have this technology.

This is just an updating of what must be an awful hack to be built on LLVM infrastructure.

Create• 14 years ago

Because actually using ROOT is painful, and the CS crowd had lisp and now python/pypy.

http://www.insectnation.org/howto/living-without-root

https://linuxfr.org/nodes/18919/comments/632920

http://comments.gmane.org/gmane.comp.lang.c%2B%2B.root/5924

joebo• 14 years ago

I've used libtcc from tcc to do something similar on a prototype listening on a socket to do queries over a 2 gig memory mapped file. I'd pass over the query as a string of C that would be dynamically compiled and executed by libtcc. It worked really well but ultimately didn't go anywhere other than research. Here's an example from the distribution (first google result for the file): http://www.koders.com/c/fidC76C8B834DFF05F1D0BD61220AC19E246.... TCC can be found here: http://bellard.org/tcc/

sedachv6• 14 years ago

I am surprised more projects don't use TCC for that. It's an awesome little compiler and using it that way saves way more time over writing DSLs. Even projects that have to compile C all the time (like Lisp->C compilers such as ECL and Gambit Scheme) use GCC, which is stupid slow.

freepipi• 14 years ago

I think it is very useful if you want to know more about c++,especially some feature you 're not very sure about. interactive interpret make it very intuitive, and it will save you time,because you don't need to compile the code. but one limit is that now it doesn't support template , you still have to write a source file if you want to use template.

mgurlitz• 14 years ago

To be clear, those empty #include's are typos, not Cling inferring desired header files. Both are:

    #include <iostream>

coldgrnd4• 14 years ago

Uuhhh...damn! I messed that up. corrected now! thanks!

sedachv6• 14 years ago

To provide more precedents and a little history:

The first C "interpreters" I know of were for Lisp machines: Symbolics' C compiler (http://www.bitsavers.org/pdf/symbolics/software/genera_8/Use...) and Scott Burson's (hn user ScottBurson) ZetaC for TI Explorers/LMIs and Symbolics 3600s (now available under the public domain: http://www.bitsavers.org/bits/TI/Explorer/zeta-c/). Neither of them are interpreters, just "interactive" compilers like Lisp ones are.

I am writing a C to Common Lisp translator right now (https://github.com/vsedach/Vacietis). This is surprisingly easy because C is largely a small subset of Common Lisp. Pointers are trivial to implement with closures (Oleg explains how: http://okmij.org/ftp/Scheme/pointer-as-closure.txt but I discovered the technique independently around 2004). The only problem is how to deal with casting arrays of integers (or whatever) to arrays of bytes. But that's a problem for portable C software anyway. I think I'll also need a little source fudging magic for setjmp/longjmp. Otherwise the project is now where you can compile-file/load a C file just like you do a Lisp file by setting the readtable. There's a few things I need to finish with #includes, enums, stdlib and the variable-length struct hack, but that should be done in the next few weeks.

This should also extend to "compiling" C to other languages like JavaScript, without having to go through the whole "emulate LLVM or MIPS" garbage that other projects like that do. I think I figured out how to do gotos in JavaScript by using a trampoline with local CPS-rewriting, which is IMO the largest challenge for an interoperable C->JS translator.

As to how to do this for C++, don't ask me. According to the CERN people, CINT has "slightly less than 400,000 lines of code." (http://root.cern.ch/drupal/content/cint). What a joke.

gsnedders• 14 years ago

Emscripten in no way emulates LLVM (as far as I know it's the only C-to-JS compiler that uses LLVM, and hence must be what you're referring to!) — it compiles LLVM to JS, with no emulation, and there's currently work going on to re-implement it as a LLVM backend (it currently is an entirely separate codebase that takes LLVM bitcode in and spits JS out).

sedachv6• 14 years ago

My mistake, I thought Emscripten was an LLVM VM in JS. I'll take a look at it to see what the output actually does.

mahmud2• 14 years ago

That Oleg link has me nerd-snipped.

What I can't wrap my head around is how one would implement pointer-arithmetic with these closures? C pointers are not just references to cells, but those cells are guaranteed to be contiguous (up to a certain limit, be it an VM allocation unit, say "page", or all available system unit in VM-less systems)

That is to say, C pointers are not like ML references. Along with SET and REF they also allow addition, subtraction, scaling, etc.

For closures to model C pointers, wouldn't they need to order the allocation of cells in some manner? say, big array? And if so, this could get expensive very quickly (worst-case being "modeling" of entire memory, i.e. emulation) without certifying compiler or at least some exhaustive pointer analysis.

Hope I'm wrong on this.

cwzwarich• 14 years ago

The C standard basically only guarantees that pointer arithmetic works when the pointers involved all point to the same array object (it also allows for a pointer just off the end of an array object). Other pointer arithmetic or comparison is undefined behavior and an implementation can do whatever it pleases.

sedachv6• 14 years ago

> What I can't wrap my head around is how one would implement pointer-arithmetic with these closures?

  (defstruct memptr
    mem
    (ptr 0))

  (defun allocate-memory (size) ;; shared by malloc and static allocation
    (make-memptr :mem (make-array size :adjustable t :initial-element 0)))

  (defstruct place-ptr
    closure)

  (defmacro vacietis.c:mkptr& (place) ;; need to deal w/function pointers
    (let ((new-value (gensym)))
      `(make-place-ptr :closure (lambda (&optional ,new-value)
                                  (if ,new-value
                                      (setf ,place ,new-value)
                                      ,place)))))

  (defun vacietis.c:deref* (ptr)
    (etypecase ptr
      (memptr (aref (memptr-mem ptr) (memptr-ptr ptr)))
      (place-ptr (funcall (place-ptr-closure ptr)))))

  (defun (setf vacietis.c:deref*) (new-value ptr)
    (etypecase ptr
      (memptr (setf (aref (memptr-mem ptr) (memptr-ptr ptr)) new-value))
      (plate-ptr (funcall (place-ptr-closure ptr) new-value))))

  (defmethod vacietis.c:+ ((x number) (y number))
    (+ x y))

  (defmethod vacietis.c:+ ((ptr memptr) (x integer))
    (make-memptr :mem (memptr-mem ptr) :ptr (+ x (memptr-ptr ptr))))

  (defmethod vacietis.c:- ((ptr1 memptr) (ptr2 memptr))
    (assert (eq (memptr-mem ptr1) (memptr-mem ptr2)) ()
            "Trying to subtract pointers from two different memory segments")
    (make-memptr :mem (memptr-mem ptr1) :ptr (- (memptr-ptr ptr1) (memptr-ptr ptr2))))

As you can see I don't do anything with type declarations, so arithmetic performance is going to be terrible. Multiple levels of pointer indirection work correctly with pointer arithmetic, since all pointers which can be legally added/subtracted are first-class objects.

cygx2• 14 years ago

The only problem is how to deal with casting arrays of integers (or whatever) to arrays of bytes. But that's a problem for portable C software anyway.

Byte-wise access to objects is legal and completely portable between conforming implementations. What isn't portable are arbitrary type conversions through pointer casts as these violate the effective typing rules. Such casts may break in practice due to mis-alignment or because of aliasing behind the optimizers back.

In a way, C is a strongly typed language - the type system is just really unsound.

sedachv6• 14 years ago

> Byte-wise access to objects is legal and completely portable between conforming implementations.

That makes absolutely no sense. Just think about endianness for example. Type conversions in C are extremely tricky, and in many cases are not guaranteed to be portable across different compilers even on the same architecture. There is a good explanation of what you can and cannot count on in chapter 6 of Harbison and Steele's C A Reference Manual.

tree_of_item• 14 years ago

The LLVM infrastructure gets more amazing every day; Emscripten and Cling are very exciting projects. C++ gets a lot of flak but it's still got a huge amount of life in it.

clobber• 14 years ago

For small programs, something like CodeRunner is nice too: http://krillapps.com/coderunner/

mlvljr• 14 years ago

Has anyone mentioned CH already (http://www.softintegration.com/)?

Kind of an interesting (hi-level) tool, too.

solenskiner• 14 years ago

Could this be used to make a c/c++ plugin for lightroom, once it is out and stable?

Cling: Running C++ in an interpreter

Related Stories