The non allocating D subset
Adam D. Ruppe
destructionator at gmail.com
Sat Jun 1 13:20:55 PDT 2013
So I'm still playing with this and just realized the TypeInfos
that are manually written in the real druntime could just as
easily be auto-generated.
mixin(makeTypeInfo!(char[], ... more types as needed ... )());
private string makeTypeInfo(T...)() {
if(__ctfe) { // this is here so we don't have runtime
requirements of array append, etc, but can still use them in ctfe
string code;
foreach(t; T) {
code ~= "class TypeInfo_" ~ t.mangleof ~ " :
TypeInfo {
override string toString() const { return
\""~t.stringof~"\"; }
}";
}
return code;
} else assert(0);
}
and so on for the other typeinfo methods. Or we could just
copy/paste the typeinfos Walter wrote in the real druntime but
meh.
What I'm actually doing with most these is this:
class TypeInfo_A : TypeInfo {}
class TypeInfo_i : TypeInfo {}
[etc...]
So they are pretty much useless at runtime, but the compiler
often outputs references to them, so if we don't have the
definition, it won't actually link.
But just thinking about runtime reflection, if we wanted to
expand it, I say this is the way to go. Literally build the
runtime code out of the compile time information.
Currently, you can't do something like typeid(int).isIntegral().
There is no isIntegral function, and adding it means doing a lot
of boring manual stuff to add.
But with the mixin, we can just throw it in with three lines and
be done with it.
I might actually do that here, just because I can. On a -version
switch, of course, so you can easily opt out of the fat
implementation.
More information about the Digitalmars-d
mailing list