Why are there so few C++ interpreters

Quote:

I personally know of only 1 C++ interpreter, which is used by Root (CINT, developed at CERN). It made me wonder why there are so few, and the obvious answer is that C++ is a very complex language to parse. No one in their right mind would bother writing a C++ parser from scratch...

There are some important questions here: What is your goal and why would a C/C++ interpreter be the best (or at least a reasonably good) solution to that problem? "What is your goal?" and "Why is X a good solution?" are generally very good first questions to ask before wasting valuable time on implementing a solution.

C/C++ is impractical as a console based interpreted language for many reasons and people usually don't like wasting time on implementing tools that are not practical (well, maybe those who have a lot of time to have fun and learn and/or those who can't foresee the impractical aspects).

Implementing an interpreter for a dynamic language (like python) with dynamically typed variables and "dynamically linked functions" is orders of magnitude easier and less error prone than doing the same with C/C++. Writing the whole parser, compiler, interpreter for a simple dynamic language is quite easy and quick. The interpreter itself doesn't have to be very performant because it's usually used only to execute high level logic, glue code. If something is performance critical then you can implement it as a native C/C++ module for your interpreter and bind it to the dynamically interpreted language. In my opinion you haven't really thought over the problems that would arise with C/C++ interpreters. I could write a novel about them. Here are the most interesting problems that are big enough:

C/C++ requires forward declarations. In a practical interpreted language there are no forward declarations and there are no separated declarations/definitions. But this is just a tiny part of a more serious problem: C/C++ is impractically verbose to be used as an interpreted language. This is a set of problems that involve both language design problems and practical usability problems as an interpreted language. In python I can easily define an X function that calls a nonexistent Y function and I am allowed to define this Y function later. Then I can execute X. Later if I want I can completely change the definition of Y (maybe with some new default-initialized parameters to be backward compatible with the previous definition) and another execution of X immediately uses the new Y definition. I can execute X even if it calls a Z function that haven't yet been defined and this isn't a problem if the execution of X with the actual input parameters doesn't actually run into the branch that would call Z. In a C++ interpreter what happens if I change the definition of a very basic template (eg: dynamic array) that is used by a lot of previously defined functions (for example as inlined functions)? How do you find out which codeblocks need recompilation inside your interpreter in order to use the new inline functions? What happens if the recompilation of some of these functions fail with the new definition? You don't have serious problems like this with dynamic languages like python. Dealing with such scenarios in a non-dynamic interpreter would be a huge problem, and these were just two "simple/basic" problems, this is only the tip of the iceberg. I've been programming C/C++ for more than a decade and never felt the need for a C/C++ interpreter.

Quote:

However, there are C++ parsers are out there as part of compilers, some of which are open source. It occurred to me that it might be possible to interpret the assembly code that is emitted by the parser on the go. This would be like a JIT compiler that emits bytecode to be interpreted by a virtual machine. One problem that comes to mind is the use of different source-files which would otherwise lead to several object files that need to be linked. This is indeed a limitation, but not a very serious one if you ask me.

I started to write an answer but it became too long and complex as it analyzed your problem along many different cross-sections. Instead I write here just some of my conclusions.

You should answer the questions I've posted in the previous paragraph. From your question I think maybe your goal is simply creating A C++ interpreter with the least amount of work invested - I assume this because you want to reuse stuff (compilation units, object files) from existing compilers. My problem with this is that people do something with "least work invested" when they have to do something they don't like. On the other hand if they do something just for fun as a hobby or with a specific purpose then they usually don't mind doing a lot of work. In case of a C/C++ interpreter all solutions seem to involve a lot of work.

Depending on the compiler and the compiler settings the object files might contain something else than what you need. They are not standardized and even the same compiler can put completely useless garbage into them with some settings (like LTCG). IMO it would be more practical to write a backend to emit what you need instead of trying to parse it from object files.

My speculative reason: There seems no one have had the need compared to the efford to do it. I.e. you might be able to build an Eiffel Tower in your garden, assuming you have the space, the material, the people, the good enough ground, etc. and you can do it for your own pleasure. ;-)

The difference from C to C++ is as stated in the C++ standard:

In addition to the facilities provided by C, C++ provides additional data types, classes, templates, exceptions, namespaces, operator overloading, function name overloading, references, free store management operators, and additional library facilities.

If going to C++11, you might add lambda expressions and several other parts, all mainly syntactic sugar in the sense that they abstract something that is mainly parser related and could also be done (if not tedious) by other means.

What results as runtime items from parsing the above features are
- additional data types: some more built-in char/numeric types
- class: extended instance functions with this parameter
- class: inheritance with base class as sub object of a derived class
- class: special implicit function calls (ctor, dtor, etc.)
- class: vtable for virtual function calls
- class: ordering of definitions (mostly) do not matter in classes - only name lookup is affected
- templates: generated classes or functions based on type or constant integral values
- exceptions: additional control flow and especially cleanup-bookkeeping code
- namespaces: "syntactic sugar" (the unuique types, objects, fucntions get defined and called)
- overloading: "syntactic sugar" (the parser creates calls to the correct functions)
- references: "syntactic sugar", results in pointers or no runtime code at all
- new/delete: low level memory malloc/free plus ctor/dtor calls
- libraries: collection of items that base on language features
- lambda expression: "syntactic sugar" (implicit functor class)
- ...

There are nasty detail problems to overcome, but technically it can be regarded as a much extended C.

So, if you have a C++ frontend that manages to translate into functionally equivalent C, then you arrived at the level of CINT. Problems like multiple files and referencing libraries and object files is not unique to C++ but is a common fact with all C* languages. So, you can re-use these concepts of the interpreter of those languages (CINT?).

But again, justifying the effort depends very much on the prospective "gain".

Cheers
Andi

Because C++ is a massive programming language. It is just too complicated. Interpreters are created for languages like Python, JavaScript not only that they are simple, but they are meant to be interpreted, they are dynamic. The first Python implementation was an interpreter; not a compiler. Not only is this the reason. It is already known that C++ is faster than interpreted languages when "compiled". But you can't always expect the same from a C++ interpreter. C++ is context sensitive; C++ is huge; C++ contains generics. Thus, the language complexity contributes to the slow processing of the source code. For example, See the compilation speeds of C++. What will happen if you interpret the source? That being said, a classic "hello world" program may not take a while. But think of a program with heavy usage of generic techniques?

But still there some interpreters like CINT, Ch. See the following page:
http://stackoverflow.com/questions/69539/have-you-used-any-of-the-c-interpreters-not-compilers[^]

It's hard to really "solve" this question - may have been better in a forum, but here's my 2c.

The language definition does not really preclude making an interpreter, but C++ was really designed as a low-level language that can be used for extremely efficient code. The language is extremely complex, but not impossible to parse (AFAIK it really requires a GLR parser or hand-written parser). That said, most of the goodness of C++ comes from the fact that it can be used to efficient code, that runs close to the machine. Interpreters are typically used for high-level tasks, where quick iteration during development is more important than speed of execution.

In short, it would be a hell of a lot of work, and would run like a dog.