Why C++ compiles slowly

Steven Schveighoffer schveiguy at yahoo.com
Wed Aug 25 05:36:04 PDT 2010


On Tue, 24 Aug 2010 18:00:30 -0400, Simen kjaeraas  
<simen.kjaras at gmail.com> wrote:

> On Tue, 24 Aug 2010 23:53:44 +0200, Jonathan M Davis  
> <jmdavisprog at gmail.com> wrote:
>
>> On Tuesday, August 24, 2010 14:37:09 bearophile wrote:
>>> Steven Schveighoffer:
>>> > For example, foo(HashSet!int hs) inside the module testme becomes:
>>> > _D6testme3fooFC12dcollections7HashSet14__T7HashSetTiZ7HashSetZv
>>>
>>> And I think some more things needs to be added to that string, like a
>>> representation for the pure attribute, etc.
>>>
>>> Bye,
>>> bearophile
>>
>> They probably aren't there because
>>
>> 1. They have nothing to do with overrideability.
>>
>> 2. They have nothing to do with C linking.
>>
>> Presumably, dmd deals with those attributes at the appropriate time and  
>> then
>> doesn't bother putting them in the symbol table because they're not  
>> relevant any
>> more (or if they are relevant, it has other ways of getting at them).  
>> If they
>> were actually necessary in the symbol name, they'd be there. If they  
>> aren't
>> necessary, why bother putting them in there, making the symbol names  
>> even
>> longer?
>
> Pure might be worth stuffing in the symbol name, as the compiler may
> optimize things differently for pure vs. non-pure(dirty?) code.
> E.g. the result of a large, pure function that takes a while to compute
> might be cached to prevent calling it twice.

These are decisions made at the compilation stage, not the linking stage.   
LDC I think does some link optimization, so it might make sense there, but  
I'm not sure.

-Steve


More information about the Digitalmars-d mailing list