It's the same kind of technology, though here they actually always load the interpreter into the process even when not used interactively, to allow things like

It's the same kind of technology, though here they actually always load the interpreter into the process even when not used interactively, to allow things like dynamically loading additional code. They also use it to automatically compute file format layouts from C++ struct definitions, and it provides a C++ equivalent of eval(). One thing that I think is under-appreciated in this kind of thing is that a proper C++ repl is significantly less frustrating than a debugger. GDB's C++ mode is at best a poor emulation of the C++ language. LLDB does better because it reconstructs an actual C++ AST and runs it through clang but there's still a ton of limitation (e.g. you can't call any templates or inline functions from header files). Interactive C++ is pretty fun, especially for prototyping. The biggest problem I generally run into is that APIs in C++ are not really designed to be used in that way (esp in libraries whose user's don't use these kinds of tools). Libraries in languages with interactive prompts tend to have APIs designed in such a way that you can get the simple thing done with very little code (one call, only the arguments you need, etc), while in C++ it's a lot more common to expect user's to copy/paste a snippet from the doc and adjust all the options they want to change. That works fine in an editor, but is pretty annoying in a prompt. The other thing I often run into is error handling. A lot of C++ libraries' error handling is to just call abort() (at best) or segfault, which again is mostly fine for a compiled problem, but is annoying in an interactive setting. You can work around that of course by catching the error/resetting state, but even then you often leave libraries in the wrong state.