Is the primary implementation of *any* popular programming language interpreter written in C++?

views:

478

answers:

+9 Q:

Is the primary implementation of any popular programming language interpreter written in C++?

+2 A:

Most popular programming languages started to be created before there were many good C++ compilers available. Therefore the primary interpreters of those languages did not start out in C++, and once you have put a lot of work into a working interpreter, you usually don't throw that away just because it could now also be written in C++.

And if you start a new project for a interpreter written in C++ it is has to go a long way to become the primary implementation.

sth 2010-07-06 11:25:13

Using LLVM might help (and that's c++).

Klaim 2010-07-06 11:31:33

@Klaim: Yeah, for example clang is a serious compiler for C/C++/Objective-C, based on LLVM and written in C++, but one can hardly claim that it is the *primary* compiler for those languages...

sth 2010-07-06 11:50:59

@sth:One can hardly claim that *any* compiler for those languages is "primary".

slacker 2010-07-06 12:48:02

And I was mor thinking about newer languages like D. In fact it's recommanded to start with LLVM for any new language compiler.

Klaim 2010-07-06 13:10:54

One fundamental difference between compilers and interpreters, however, is the latter's far greater need for speed and efficiency. Certainly, no one wants to be sitting around all day waiting for a program to compile, but if the result is well-optimised and runs quickly once it's been compiled, people aren't really going to complain. But an interpreter has to run a program from scratch every time is is executed, so speed is a real concern; the "compilation" step (whether the program is compiled into bytecode, an abstract syntax tree, or whatever) really effects the overall run-time speed.

Thomas Larsen 2010-07-07 02:51:09

+2 A:

The GNU foundation has just recently announced that all the new versions of gcc will be written in c++.

SF. 2010-07-06 11:29:13

SRSLY? That's interesting.

spong 2010-07-06 11:42:57

@spongL http://allanmcrae.com/2010/06/gcc-in-cxx/The adoption/conversion will be slow and not done in "c++ for c++ sake" but it will eventually happen.

SF. 2010-07-06 12:00:44

I believe <http://gcc.gnu.org/ml/gcc/2010-05/msg00705.html> is the thread that announced that they've decided to *allow* C++ in the GCC code, that does *not* mean it's going to be rewritten. That would be insane, IMO.

unwind 2010-07-06 12:01:26

It's too late now for GCC. In face of Clang, i guess they will slowly abandon GCC.

Johannes Schaub - litb 2010-07-06 12:15:27

@litb: Its going to be egcc all over again, though this time, GCC will most likely be retired permenently, I just hope some of the ego-farts from GCC don't make it into the clang ranks.

Hippicoder 2010-07-06 13:26:18

@litb "they" who? guys at fsf? @Hippicoder if the "ego-farts" from gcc are good programmers, why shouldn't they go to clang ranks? (they should respect the design, guidelines and whatever of clang anyway)

ShinTakezou 2010-07-07 07:06:37

+5 A:

If you wrote the current implementation and -as you say in your comment- it has:

clumsy symbol-handling and numerous memory leaks

Then rewriting in c++ is not going to help you. First try to understand why the current implementation goes wrong. On the other hand, if you are not the original developer then just choose whichever language you know best and port.

Update: I think sth's comment explains properly why many languages are implemented in C rather than C++. On the topic of complete rewrites, heed the words of Joel Spolsky.

jilles de wit 2010-07-06 11:33:30

That's the thing: I'm not the original developer. The interpreter, as it stands, represents about 10--15 years of evolution, hence why its code is so messy in places. I'm fairly convinced that the only practical way to address all of its flaws is to rewrite it from scratch in either C or C++; but I'm wondering why there are, or at least seem to be, no popular interpreters written in C++. But then, of course, there's always a first time. ;-)

Thomas Larsen 2010-07-07 00:33:09

I didn't think you had written the original. I updated my answer a bit.

jilles de wit 2010-07-07 12:10:07

+7 A:

I wrote an interpreter in C++ (after many in C over the years) and I think that C++ is a decent language for that. About the implementation I only would travel back in time and change my choice of implementing the possibility to have several different interpreters running at the same time (every one multithreaded) simply because it made the code more complex and it's something that was never used. Multithreading is quite useful, but multiple instances of the interpreter was pointless...

However now my big regret is indeed the very fact I wrote that interpreter because now it's used in production with a fairly amount of code written and persons trained for it, and because the language is quite uglier and less powerful that python... but switching to python now would add costs. It has no bugs known to me... but yet it's worse than python and this is a bug (in addition to the error already made of paying the cost of writing it for no reason).

I simply should have used python initially instead (or lua or any other ready made interpreter that can easily be embedded and that has a reasonable licensing)... my only excuse for this is that I didn't know about python or lua at that time.

While writing an interpreter is a funny thing to do as a programming exercise I'd suggest you to avoid writing your own for production, especially (please don't take it personally) if the care that low level complexity requires is out of your reach (I find for example the presence of several memory leaks quite shocking).

C++ is still a low level language and while you can get some help for example on the memory handling side still the main assumption of the language is that your code is 100% right as no runtime error is going to help you (only undefined behaviour daemons).

If you missed this assumption of 100% correct code for C (a much simpler language) then I don't see how can you be confident you'll write correct code in C++ (a complexity monster in comparison). I suspect you would just end up with another buggy interpreter that you'll have to throw away.

6502 2010-07-06 11:58:37

I disagree about writing buggy in C++. C++ is typesafe (no `void*` around) and allows idioms such as RAII to manage resources. These 2 features make it MUCH easier to write non-buggy code in my opinion. Truth to be told, I think the more error-prone features actually come from C...

Matthieu M. 2010-07-06 14:28:41

6502 2010-07-06 15:34:22

Well, I didn't write the interpreter originally; I "adopted" it from someone else, so many of the memory leaks and other problems were already present. I succeeded in removing some, but overall the whole implementation is still a big mess---not because the original author was a bad programmer, but because the interpreter represents over ten years of evolution.

Thomas Larsen 2010-07-07 00:11:37

@Thomas things are then different... I would try to compare X=(cost of rewrite and re-debug + future cost for scripts because of the poor language) withY=(cost of embedding python and converting scripts (or writing a converter) + training of programmers). C++ for writing an interpreter is in my opinion ok compared to C... for example C++ exceptions are in an interpreter nice to use for runtime errors because there is a clear logical "boundary" about state (being able to catch and swallow an exception in a general "sprinkled state" C++ program is IMO much harder to do correctly).

6502 2010-07-07 05:01:55

+1 A:

Tamarin - Adobe and Mozilla ECMAScript interpreter is written in C++. Being the one for which the original language author has responsibility, it might be considered the primary one (IIRC the ECMA reference implementation is written in OCaml, but that isn't actually used except as a reference)

Pete Kirkham 2010-07-06 12:11:54

+1 A:

Google Chrome V8 Javascript Engine Implements ECMA-262 and it's extremely fast. Maybe you could rewrite it in C++ but you shold think about other features like implement a bytecode specification instead rewriting your automates in C++. Rewrite it will just help to organize the code (which is a great thing for group working), but nothing in performance.

Cheapshot 2010-07-06 12:24:24

+7 A:

Yes, many are. IIRC the Hotspot Java VM is written in C++, Haskells ghc, ...

As many here have noted You should really have a look at LLVM, it is a toolkit for building compiler, interpreter and virtual machines. You basically do the frontend work, (i.e. parsing your language + semantic analysis + codegen in LLVM IR) and LLVM will immediately give you building for different platforms, jit, optimization, compiling to native code, ... It also has some tools for parsing and AST, and error handling and notification (but maybe that is part of the Clang subproject.)

Fabio Fracassi 2010-07-06 12:36:31

ghc is written in haskell

hiena 2010-07-07 12:23:44

Note: All this is second hand knowledge. AFAIK only a part, or the reference implementation is written in Haskell, to generate optimized programs you need either a gcc or a LLVM backend, which is then written in C or C++ respectively. See here: [Fast Haskell using LLVM](http://donsbot.wordpress.com/2010/02/21/smoking-fast-haskell-code-using-ghcs-new-llvm-codegen/)

Fabio Fracassi 2010-07-07 14:33:28

+1 A:

Sun's Java implementation seems to be written in C++ mostly.

JeremyP 2010-07-06 12:50:54

+1 A:

If memory leaks are your only problem with your current program then try valgrind on it. I've never had a memory leak in my software that valgrind could not track down for me. In fact it has saved my butt on so many occasions.

Here is a tutorial

http://www.cprogramming.com/debugging/valgrind.html

bradgonesurfing 2010-07-07 06:12:12

Valgrind is a very useful tool, but in the interpreter I adopted (1) the memory leaks would require far-reaching, "radical" fixes, fixes that would require me to rewrite parts of the code anyway and risk messing up parts of the program (potentially causing dangling pointers, etc.), and (2) memory leaks aren't the only problem; there are a pile of changes to symbol handling that I want to make and the existing system is too complicated to change safely, if that makes sense.

Thomas Larsen 2010-07-07 07:41:29

ansaurus

tags:

views:

answers:

Is the primary implementation of any popular programming language interpreter written in C++?

related questions