On 12/16/11 3:28 PM, Steven Schveighoffer wrote:
On Fri, 16 Dec 2011 14:48:33 -0500, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
On 12/16/11 1:23 PM, Steven Schveighoffer wrote:
I disagree with this assessment. It's good to know the cause of the
problem, but let's look at the root issue -- reflection. The only reason
to include class information for classes not being referenced is to be
able to construct/use classes at runtime instead of at compile time. But
if you look at D's runtime reflection capabilities, they are quite poor.
You can only construct a class at runtime if it has a zero-arg
constructor.
So essentially, we are paying the penalty of having runtime reflection
in terms of bloat, but get very very little benefit.
I'd almost agree, but the code showed doesn't use Object.factory(). So
that shouldn't be linked in, and shouldn't pull vtables.
You cannot know until link time whether factory is used when compiling
individual files. By then it's probably too late to exclude them.
I'm not an expert in linkers, but my understanding is that linkers
naturally remove unused object files. That, coupled with dmd's ability
to break compilation output in many pseudo-object files, would take care
of the matter. Truth be told, once you link in Object.factory(), bam -
all classes are linked.
The point is that you can instantiate unreferenced classes simply by
calling them out by name.
Yah, but you must call a function to do that.
I'm not pushing for runtime reflection, all I'm saying is, I don't think
it's worth changing how the library is written to work around something
because the *compiler* is incorrectly implemented/designed.
So why don't we just leave the code size situation as-is? 500kb is not a
terribly significant amount, but dlls are on the horizon (Walter has
publicly said so). Then size becomes a moot point.
If we get reflection, then you will find that having excluded all the
runtime information when not used is going to hamper D's reflection
capability, and we'll probably have to start putting it back in anyway.
In short, dlls will solve the problem, let's work on that instead of
shuffling around code.
I think there are more issues with static this() than simply executable
size, as discussed. Also, adding dynamic linking capability does not
mean we give up on static linking. A lot of programs use static linking
by choice, and for good reasons.
Andrei
