On Friday, 1 September 2017 at 20:27:45 UTC, Jonathan Marler
wrote:
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.
Yes, export table. It seems that right now, 'export' is
equivalent to __declspec(export) on windows. On linux, it likely
has no effect to due all symbols being exported by default on
those platforms. I forget how exactly, but I think DIP22 changes
this situation.
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
True..didn't think of that =/
And this would be problematic, because my intentions were to use
this for deserialization, where all you have is a string that's
supposed to be a fully qualified type.
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.
Basically, the problem is deserializing a scene-graph from a json
text file. The architecture of my scene-graph enforces that some
template-function will be instantiated for every symbol that is
reflected. So what I'm trying to avoid is having to store all of
the instantiated type information in a central repository.
Imagine I gave you a static library, and a json file, and I told
you that all the necessary symbols to deserialize that json file
were in that static lib. If we both had the same serialization
library that was used, you would be able to deserialize the json
file without me giving you any source, or having you register all
the needed types yourself in some centralized type library.
That's the dream.
