Program size, linking matter, and static this()

Andrei Alexandrescu SeeWebsiteForEmail at
Fri Dec 16 11:48:33 PST 2011

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.

> I think there are two things that need to be considered:
> 1. We eventually should have some reasonably complete runtime reflection
> capability
> 2. Runtime reflection and shared libraries go hand-in-hand. With shared
> library support, the bloat penalty isn't nearly as significant.
> I don't think the right answer is to avoid using features of the
> language because the compiler/runtime has some design deficiencies. At
> some point these deficiencies will be fixed, and then we are left with a
> library that has seemingly odd design choices that we can't change.

Runtime reflection is great, but I think it's a separate issue from 
what's discussed here.


More information about the Digitalmars-d mailing list