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