Proposal for custom time string formatting in std.datetime

[Michel Fortin]

On 2011-12-22 08:14:21 +0000, Jonathan M Davis <jmdavisProg at gmx.com> said:

> On Thursday, December 22, 2011 00:05:58 Walter Bright wrote:
>> We must deal with our imperfect tools as they are. For example, I am not
>> going to rewrite the Linux ld linker, and the OSX linker, and the FreeBSD
>> linker, etc.
> 
> If the compiler and/or linker don't strip unused symbols, then how on earth is
> importing the module _not_ going to pull in everything in it save for
> uninitialized templates?

I'm pretty sure, even though it's been a long time I've looked at those 
details, that the problem is caused by classes. Basically, the typeinfo 
for all classes in a module are referenced by the generated module info 
structure. The class's typeinfo points to many things including the 
default constructor and vtable, the vtable points to all virtual 
functions, which finally points to everything used by those functions. 
You can thus easily have all the code in the module referenced 
indirectly by the module info, so the linker can't strip it. That might 
be why std.datetime has a heavy footprint, even when you use only a 
small part of it. But still, you should look at the generated code to 
test this hypothesis.

The benefit of referencing classes within module info: you can 
instantiate them using Object.factory, if they have a default 
constructor. We pay a heavy price compared to what we get with this 
very limited runtime reflection.

Things you can do if this hypothesis proves to be correct: make it so 
that any virtual function in your classes are short and do not depend 
on heavy functions, as all the code referenced by those functions will 
be dragged along. Don't forget that final functions are still virtual 
if they override a function in a base class or defined in an interface. 
Also, don't use a class if you don't need one, or if you need one put 
it in a separate module that you only import when you need it.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/