Function pointer from mangled name at runtime?

[Jonathan Marler via Digitalmars-d]

On Friday, 1 September 2017 at 19:49:46 UTC, bitwise wrote:
> If I have the mangled name of a module-scoped D template 
> function as a string, is there a way to check for it's presence 
> in the symbol table, and retrieve the function pointer at 
> runtime?
>
>
> Example:
>
> `
> module mine;
> class Test { }
> `
>
>
> `
> module reflection;
> class RuntimeInfo {
>     string name();
> }
>
> class RuntimeInfoImpl(T) {
>     string name() { return T.stringof; }
> }
>
> RuntimeInfo getRTInfo(T)() {
>     static const(RuntimeInfo) info = new RuntimeInfoImpl!T();
>     return info;
> }
>
> RuntimeInfo getRTInfo(string qualifiedName) {
>     // determine mangle of `getRTInfo` with template parameter 
> 'qualifiedName'
>     // retrieve function pointer from symbol table and call it 
> to retrive the `RuntimeInfo`
> }
> `
>
> So for every symbol on which `getRTInfo(T)()` is used, there 
> should be an entry in the symbol table, right? (I will have a 
> method in place to enforce it's instantiation)

Symbol table is usually used to mean the compiler symbol table, 
so I'm assuming you mean the "export table" in your binary that 
contains all the exported symbols.  The executable will have an 
entry for those manged getRTInfo functions so long as they are 
exported.  I don't think I've ever used the "export" keyword in a 
D program but it appears it exists and could be used to put 
symbols in your export table so they could be looked up at 
runtime.

>
> And if I was provided with the fully qualified name of a class 
> like `mine.Test`, I should be able to determine how that 
> function was manged, right?

You would also need to know type information, not just the name 
itself.  If you had a name like mine.A.B.Test, then you would 
need to know what A, B, and Test are, are they modules, classes, 
structs, enums, etc

>
> So can I then look that symbol/string up at runtime and somehow 
> retrieve the function pointer so I can call it?

A reasonable solution to this would require operating system 
support.  Windows has LoadProcAddress, I've used it to load 
functions from dlls, but not from my own currently running 
executable, not sure if this would work or not.  Linux has dlsym, 
which does the same thing but again I've never tried to use it to 
look up function addresses of functions in my own executable.

I don't know what problem you're trying to solve here, but I will 
say that it appears you may be going about it in the wrong way. 
If you would like to share the real problem you are trying to 
solve I could take a stab at recommending a possibly simpler 
solution.