<story><title>Cling: Running C++ in an interpreter</title><url>http://blog.coldflake.com/posts/2012-08-09-On-the-fly-C%2B%2B.html</url></story><parent_chain></parent_chain><comment><author>sedachv</author><text>To provide more precedents and a little history:&lt;p&gt;The first C &quot;interpreters&quot; I know of were for Lisp machines: Symbolics&apos; C compiler (&lt;a href=&quot;http://www.bitsavers.org/pdf/symbolics/software/genera_8/User_s_Guide_to_Symbolics_C.pdf&quot; rel=&quot;nofollow&quot;&gt;http://www.bitsavers.org/pdf/symbolics/software/genera_8/Use...&lt;/a&gt;) and Scott Burson&apos;s (hn user ScottBurson) ZetaC for TI Explorers/LMIs and Symbolics 3600s (now available under the public domain: &lt;a href=&quot;http://www.bitsavers.org/bits/TI/Explorer/zeta-c/&quot; rel=&quot;nofollow&quot;&gt;http://www.bitsavers.org/bits/TI/Explorer/zeta-c/&lt;/a&gt;). Neither of them are interpreters, just &quot;interactive&quot; compilers like Lisp ones are.&lt;p&gt;I am writing a C to Common Lisp translator right now (&lt;a href=&quot;https://github.com/vsedach/Vacietis&quot; rel=&quot;nofollow&quot;&gt;https://github.com/vsedach/Vacietis&lt;/a&gt;). This is surprisingly easy because C is largely a small subset of Common Lisp. Pointers are trivial to implement with closures (Oleg explains how: &lt;a href=&quot;http://okmij.org/ftp/Scheme/pointer-as-closure.txt&quot; rel=&quot;nofollow&quot;&gt;http://okmij.org/ftp/Scheme/pointer-as-closure.txt&lt;/a&gt; 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&apos;s a problem for portable C software anyway. I think I&apos;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&apos;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.&lt;p&gt;This should also extend to &quot;compiling&quot; C to other languages like JavaScript, without having to go through the whole &quot;emulate LLVM or MIPS&quot; 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-&amp;#62;JS translator.&lt;p&gt;As to how to do this for C++, don&apos;t ask me. According to the CERN people, CINT has &quot;slightly less than 400,000 lines of code.&quot; (&lt;a href=&quot;http://root.cern.ch/drupal/content/cint&quot; rel=&quot;nofollow&quot;&gt;http://root.cern.ch/drupal/content/cint&lt;/a&gt;). What a joke.</text></comment>
<story><title>Cling: Running C++ in an interpreter</title><url>http://blog.coldflake.com/posts/2012-08-09-On-the-fly-C%2B%2B.html</url></story><parent_chain></parent_chain><comment><author>jlarocco</author><text>It&apos;s a cool idea, but his reason for creating it is kinda dumb.&lt;p&gt;Creating an entire &quot;project&quot; just to check a code snippet is just silly.&lt;p&gt;Just create a &quot;testing&quot; directory and throw your one off test files into it and compile/run them there.&lt;p&gt;I start mine with a comment explaining what I&apos;m testing, why I&apos;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.&lt;p&gt;It has the advantages that I can test multiple compilers and I keep a history of the things I&apos;ve tried.</text></comment>