Program size, linking matter, and static this()

Steven Schveighoffer schveiguy at yahoo.com
Fri Dec 16 13:28:03 PST 2011


On Fri, 16 Dec 2011 14:48:33 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at 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.  The  
point is that you can instantiate unreferenced classes simply by calling  
them out by name.

>
>> 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.

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.

-Steve


More information about the Digitalmars-d mailing list