What can be done to reduce executable size?
Sean Kelly
sean at invisibleduck.org
Fri Dec 16 15:05:43 PST 2011
On Dec 16, 2011, at 2:54 PM, Andrei Alexandrescu wrote:
> On 12/16/11 4:21 PM, Sean Kelly wrote:
>> On Dec 16, 2011, at 12:26 PM, Andrei Alexandrescu wrote:
>>
>>> On 12/16/11 1:07 PM, Sean Kelly wrote:
>>>> This is fine, but the whole point of static ctors in D is to
>>>> eliminate all the stupid workarounds required to use statics in
>>>> C++. I'd much rather we find a way to make the use of static
>>>> ctors more efficient than give up on the feature.
>>>
>>> I agree, but then I think we have a design that's already there.
>>> This discusses working some kinks out of the implementation. Also,
>>> the context of the runtime/standard library is an appropriate place
>>> to take less usual measures for the benefit of many.
>>
>> But at the same time, the standard library should be an example of
>> how to do things "the right way."
>
> More often, APIs and examples given in the docs are examples of how to do things the right way; the standard library's implementation has a bit of a different charter than most application code, and this is triply true for systems languages. This is emphatically true for e.g. C, C++, and Perl. I also remember I was surprised when I peeked inside a functional language's library implementation. ("That's not how they teach them to write sort!")
Perhaps it's just that I come from a systems programming background and have books like "Large Scale C++ Software Design" sitting on the shelf next to me. I think the important distinction to be made is between sample code and real world code. Or perhaps between code where performance is and is not an issue. You've historically derided the quicksort example for functional programs as useless because, while it's a very clean example of the algorithm, it's ridiculously inefficient. So anyone who really cares about the efficiency of their code is going to end up writing stuff that looks nothing like what you'd find in a textbook. In short, they're going to write code that looks like standard library code to whatever extent the skill of their programmers can achieve. I really don't want the line between whether or not to use really useful language features like static ctors to be whether I'm writing sample code or professional code.
That said, I will grant that library code in general can't make any assumptions about how the code will be used, so this is the one case where premature optimization really is prudent. Even performance-minded application code typically can't make the same claim because there is generally some idea of how that code will be run, and thus tuning can be done based on profiler data. So I suppose I'll somewhat concede your point.
More information about the Digitalmars-d
mailing list