On 8 January 2014 12:14, Iain Buclaw <[email protected]> wrote: > 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.
s/struct/structure/
