Signals and Slots in D
Walter Bright
newshound at digitalmars.com
Fri Sep 29 10:23:34 PDT 2006
Don Clugston wrote:
> The most basic introspection would simply be, for each class and struct
> Typeinfo, add a pointer to a string that's just a concatenation of names
> and mangled types.
> [name]\0[mangleof]\0[name]\0[mangleof]\0...[name]\0[mangleof]\0\0.
> Since we have .alignof and .sizeof, this would allow all data members to
> be identified; and would allow code to be developed that could do
> serialization stuff. It would also be reasonably compact.
> And an identical treatment for the functions in the vtable (just need to
> maintain the same order of functions). Given a string XXX, you could
> search for a function named "slotXXX" in the manglelist, and call the
> corresponding entry in the vtable.
I think generating an array of TypeInfo's would be better, because
they're easier to manipulate. TypeInfo instances are also singletons,
which potentially could make it smaller than the mangle strings.
3 pieces of info are needed for each member:
name
typeinfo
offset
> It wouldn't deal with static functions (where you need the address as
> well as the name and type info)
> I guess the challenging issue is to make sure that functions that aren't
> referenced don't get type info stored? I imagine those dynamic
> languages have trouble discarding unused functions at link time. I think
> you'd need to tell the compiler "don't discard this function even if you
> think it's not used, it's only referenced in a text string".
The bloat might be bad enough that the full introspection info would
only be generated for specified classes, say, ones that inherit from a
special
interface class.
More information about the Digitalmars-d
mailing list