The non allocating D subset
dam
anhttp
Sun Jun 9 03:41:15 PDT 2013
On Saturday, 1 June 2013 at 20:20:56 UTC, Adam D. Ruppe wrote:
> 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