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 runtime only provides some TypeInfo_x implementations and
not others, the compiler only emits the ones that it finds.
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?
