Have You Used Any of the C++ Interpreters (Not Compilers)

C Interpreter (Not Compiler)?

CINT - http://root.cern.ch/drupal/content/cint
But it is not C99 AFAIK.

Any C/C++ to non-native bytecode compiler/interpreters?

Which interpreted language are you using? If it has a .NET based implementation (e.g. IronPython) you could possibly use it with the C++/CLI compiler to produce byte code for the .NET CLR and Mono.

This is only likely to be feasible if you have full control over your C++ libraries.

Is there an interpreter for C?

There are many - if you narrow down the scope of your question we might be able to suggest some specific to your needs.

A notable interpreter is "Ch: A C/C++ Interpreter for Script Computing" detailed in Dr. Dobbs:

Ch is a complete C interpreter that
supports all language features and
standard libraries of the ISO C90
Standard, but extends C with many
high-level features such as string
type and computational arrays as
first-class objects.

Ch standard is freeware but not open source. Only Ch professional has the plotting capabilities and other features one might want.

I've never looked at this before, but having a c interpreter on hand sounds very useful, and something I will likely add to my toolset. Thanks for the question!

---

Edit:

Just found out that one of my favorite compilers, TCC, will execute C scripts:

It also handles C script files (just
add the shebang line
"#!/usr/local/bin/tcc -run" to the
first line of your C source code file
on Linux to have it executed directly.

TCC can read C source code from
standard input when '-' is used in
place of 'infile'. Example:

echo 'main(){puts("hello");}' | tcc -run -

confusion between compiler and interpreter?

Compiler and interpreters are technically two different things, though the boundaries can be pretty fluid sometimes.

A compiler is basically nothing more than a language translator. It takes a source language as input and generates a destination language as output.

An interpreter takes a language (be it high-level or low-level) and executes the code described by the language.

The confusion is mostly because most modern script languages contains both a compiler and an interpreter, where the compiler takes the script language and creates a lower-level equivalent (similar to binary machine language) that the interpreter then reads and executes.

---

As for your problems with the compiler errors, it's most likely because the compiler can't continue parsing the scanf call due to the first error, and simply skips it (including the undeclared variable).

You should also know that in C some errors can actually cause more errors in code that is otherwise correct for example

int j
printf("Enter something: ");
scanf("%d", &j);

You will get an error because of the missing semicolon after the declaration of the variable j, but you will also get an error with the scanf line as the compiler can't find the variable j, even though the scanf call is otherwise correct.

Another typical example of errors that will give follow-up errors in unrelated code, is to forget the terminating semicolon of a structure in a header file. If it's the last structure you might not even get any error in the header file, just unrelated errors in the source file you include the header file in.

Do any languages have neither an interpreter nor a compiler?

  Compiler vs. Interpreter

An interpreter translates some form of source code into a target representation that it can immediately execute and evaluate. The structure of the interpreter is similar to that of a compiler, but the amount of time it takes to produce the executable representation will vary as will the amount of optimization. The following diagram shows one representation of the differences.
graphic
Compiler characteristics:

* spends a lot of time analyzing and processing the program
* the resulting executable is some form of machine- specific binary code
* the computer hardware interprets (executes) the resulting code
* program execution is fast

Interpreter characteristics:

* relatively little time is spent analyzing and processing the program
* the resulting code is some sort of intermediate code
* the resulting code is interpreted by another program
* program execution is relatively slow

_{(source: gpollice at web.cs.wpi.edu)}

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

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.

---

Related Topics