Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cling: Running C++ in an interpreter

blog.coldflake.com

Post reply on HN
Print view View original

31–40 of 49 posts

Re: Cling: Running C++ in an interpreter

#31

Post by cwzwarich »

mahmud wrote: post #30
sedachv wrote: post #23

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…

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…

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.

Re: Cling: Running C++ in an interpreter

#33

Post by coldgrnd »

deckiedan wrote: post #9

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. Alternaitve…

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

Re: Cling: Running C++ in an interpreter

#34

Post by Create »

geofft wrote: post #16
jlarocco wrote: post #13

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…

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.

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

Re: Cling: Running C++ in an interpreter

#35

Post by cygx »

sedachv wrote: post #23

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…

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.

Re: Cling: Running C++ in an interpreter

#36

Post by pmr_ »

Arelius wrote: post #19
pmr_ wrote: post #10

Earlier quoted context omitted.

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 us…

> C++ compilation speed (and thus interpretation speed) will make it quite impossible to use it as an extension language. I think you vastly underestimate the speed of the clang C++ compiler (or any modern C++ compiler at that). I can't imagine that the compilation time for anything that could be classified as an "extension" would be significant in any meaningful way.

clang doesn't outperform gcc on most projects I work on or that speed increase is not significant. I run quite a lot of test-suites - maybe I should try to measure them and provide some real numbers for reference instead of hand-wave myself through this argument.

If I where to provide extensions points to my C++ project they would certainly contain templates and that would also mean that they would require significant compilation time (compared to what you would expect). Even if I didn't, a single header that pulls in a huge preprocessor library could ruin speed. I'm inclined to believe you if we are talking about a Qt-style C++, but that is only a subset of possible code. I would be happy to be proven wrong, too.

Re: Cling: Running C++ in an interpreter

#37

Post by mahmud »

cwzwarich wrote: post #31
mahmud wrote: post #30

Earlier quoted context omitted.

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…

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.

So I implemented this stricter definition of C pointers and it's neither interesting, nor representative of Real World uses that I know of. Need to investigate a bit more.

Re: Cling: Running C++ in an interpreter

#40

Post by dkersten »

mahmud wrote: post #37
cwzwarich wrote: post #31

Earlier quoted context omitted.

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.

So I implemented this stricter definition of C pointers and it's neither interesting, nor representative of Real World uses that I know of. Need to investigate a bit more.

stricter definition of C pointers - this made me laugh, as the less-strict definition of C pointers is called undefined behavior.

This leads me to this statement based on what you said: interesting Real World C programs make use of undefined behavior

Post reply on HN