This C-REPL one seems to have the advantage of using gcc directly while cint is basically its own compiler.
If being able to "evaluate" C code like that gives you some ideas, you might want to have a look at "libtcc" -- which seems to be getting some development love again compared to last time I looked at it (finally an x86-64 target). (I have some higher level code that converts well to C that libtcc or a gcc/dlopen approach would be nice for)
The approach is surprisingly simple: for each line of code you enter, we compile a shared object in the background. If the compilation succeeds, the object is loaded into a child process via dlopen(). Parsing of C #includes uses gccxml. (Unfortunately, I can't figure out how to use gccxml to parse the user's input, and due to the complexity of parsing C the input parser is currently hacky and heuristic.)
While I agree that this may be an elegant (simple) way of doing things, how responsive is the compilation process for the RE portion of REPL? Even a one second wait time might seem tedious.
When I began using gdb heavily recently I was pleasantly surprised that it had this capability. It's really an amazing program, I wish I hadn't been so scared to use it before
This C-REPL one seems to have the advantage of using gcc directly while cint is basically its own compiler.
If being able to "evaluate" C code like that gives you some ideas, you might want to have a look at "libtcc" -- which seems to be getting some development love again compared to last time I looked at it (finally an x86-64 target). (I have some higher level code that converts well to C that libtcc or a gcc/dlopen approach would be nice for)