general impossibility
In pure standard C++11, you cannot really achieve that goal (calling a function from its name, given by some arbitrary string at runtime) easily, if you want to call any arbitrary possible function of your program (or of libraries used by it) from the function name. You could indeed embed an interpreter (e.g. Lua or GNU guile), as suggested by xtofl's answer.
keeping an association from name to functions
If you know the set of potentially callable functions, and if they share a common signature (e.g. typedef int signature_T(int[])
, you might use simply an association from names to functions, e.g. some std::map<std::string,std::function<signature_T>>
; BTW, the new features of C++11 (closures, std::function
, auto
, lambdas) should help a lot.
using dynamic linking facilities such as dlsym
on POSIX
If you restrict yourself to a POSIX system like Linux, you could consider some other trick: use dlsym(3) and dlopen(3) to get a function pointer from some unmangled name. So you would declare the functions you want to call thru their name as extern "C"
(to disable name mangling), you would link your program with -rdynamic
and with the -ldl
library. You would either dynamically load your plugins with dlopen
-or get the main program handle by dlopen
-ing NULL
- and fetch a function pointer from its name using dlsym
. Read C++ dlopen mini howto and Drepper's How To Write Shared Libraries paper.
(Windows also have nearly equivalent facilities to dlsym
since it also has a dynamic linker; but I never used Windows)
Some C++ framework libraries (Qt, POCO) are wrapping the dynamic loading of plugins in an OS-independent way.
calling arbitrary functions using libffi
There is an issue regarding calling functions of arbitrary signature. You absolutely need to know the signature (at least at runtime, and often at compile time) when calling any function in (or from) C or C++ (because the ABI dictates various calling conventions). You could use the libffi:
Some programs may not know at the time of compilation what arguments are to be passed to a function. For instance, an interpreter may be told at run-time about the number and types of arguments used to call a given function. Libffi can be used in such programs to provide a bridge from the interpreter program to compiled code.
Just-In-Time generation of machine code
At last, you could generate some machine code at runtime using some JIT library : simple JIT libraries like GNU lightning, libjit, asmjit are able to generate quickly some rather slow machine code, or complex compiler based JIT frameworks like libgccjit or LLVM, which are generating optimized and fast machine code (but need significant generation time, like a compiler).
generating C (or C++ code) at runtime, compiling it and dlopen
-ing it
A related trick would simply generate some C or C++ code in a temporary file /tmp/foobar.c
, fork a compilation of it into a plugin (so ask for position independent code) with gcc -fPIC -O -shared /tmp/foobar.c -o /tmp/foobar.so
, then dynamically load that temporary plugin using dlopen
. I am using such a trick in MELT (a Lispy domain specific language to extend and customize GCC, available free software GPLv3). In practice, compilers are fast enough today to even permit such use interactively: the user could type a simple expression in some DSL, the infrastructure is translating that DSL to C code then forking the compilation of that code into a plugin which is later dlopen
-ed. This is fast enough in practice for interactive use (since the generated C code would have a few hundred lines per interactive expression, and compiling that takes a fraction of a second).
other programming languages
Some programming languages are homoiconic and/or have some eval
facility, or enable multi-stage programming. Some implementations have even the ability to generate quite efficient machine code at runtime, in particular SBCL is always translating to machine code every expression, even in its read-eval-print loop.