On 8 January 2014 12:13, Iain Buclaw <[email protected]> wrote: > On 8 January 2014 11:13, Mike <[email protected]> wrote: >> On Wednesday, 8 January 2014 at 01:15:45 UTC, Iain Buclaw wrote: >>>> >>>> Anyway, once you add the word "class" or "struct" you release an >>>> avalanche >>>> of snowballing required runtime stuff that you are likely not even using, >>>> directly or indirectly, in your program. And if using --gc-sections in >>>> your >>>> linker, it all just gets stripped out in the end. I was trying to >>>> articulate >>>> that here >>>> (http://forum.dlang.org/post/[email protected]) >>>> >>> >>> If you use a struct, it generates typeinfo and initialiser symbols >>> that go on the comdat on the basis that you *may* access the typeinfo >>> at runtime. >>> >>> These are weak decls so the linker merges/removes duplicates. There's >>> currently no solution in which the compiler decides whether to omit >>> sending the symbols to object file, but this can be worked upon. >>> >> >> Thanks Iain, things are starting to make sense. >> >> Can't the compiler just emit whatever the runtime provides for the TypeInfo >> stuff, right or wrong? So, if the runtime does not provide a TypeInfo_x >> implementation, it doesn't emit one. If the runtime does provide a >> TypeInfo_x, it emits exactly what the runtime provided, right or wrong. >> >> If the program provides a faulty TypeInfo_x implementation, the program >> behaves in a faulty manner, just as the programmer specified. >> >> If the program references a missing TypeInfo_x (or one of it's properties) >> implicitly/indirectly, the linker will emit and undefined reference error, >> won't it? >> >> Is this implementation possible? >> >> > > Half and half. The TypeInfo support code is a separation layer between > runtime and compiler and the compiler is not fully aware of what is > implemented by runtime. > > On the one hand, there's the internal TypeInfo you see in object.d, > these are required to be known at compile time for certain operations. > If those aren't present then you'll get mismatch errors from the > compiler, and in the case of GDC, a handy little ICE to end the > compilation immediately. > > On the other hand there's the TypeInfo support under rt.typeinfo (eg: > TypeInfo_AC). For these, only the symbol is generated by the compiler > on the fly and referenced as 'extern'. So you get linker errors if > they aren't implemented. > > This is why I suggested the 'all or nothing' approach.
Note, the struct of the internal TypeInfo symbols are known at compile time because object.d is implicitly imported.
