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.
