>>1
EVAL can be replaced by a call to COMPILE, which is what a lot of Lisp implementations which only have compilers do.
C and C++ haven't it.
They do, but it's implementation specific: you can call your compiler and then dynamically load the code at runtime. This won't take more than a few pages of code, unless you go all
[b][b][u][i][o]ENTEPRISE
[o][/i][/u][/b] about it. You can also make a slow C interpreter or use one already available, but I'm not sure there's much of a point in it.
What about C#?
C# does it the same way as you would do it in C, except it's portably supported. You can compile a new module and load it at runtime. I'm sure interpreting is also possible, but I haven't seen a C# interpreter, but I've seen plenty of cases of compiling and loading new code at runtime.
Note that shit like manually invoking the compiler doesn't count.
Now you tell me... That's how most smart languages do it, especially when implementing an interpreter is more work (doesn't apply to Lisp, where metacircular interpreters can be done in very little space), and the resulting interpreter is much slower than compiled code (the only exception to this is when compiling is slower for small pieces of code, which would be faster to interpret).