Identifier (...) is too long by X characters

Don Clugston dac at nospam.com.au
Fri Jul 14 04:28:52 PDT 2006


Bruno Medeiros wrote:
> Don Clugston wrote:
>> Sean Kelly wrote:
>>> Chris Nicholson-Sauls wrote:
>>>> Tom S wrote:
>>>>> ...DMD eats many many rams...
>>>>
>>>> *Gasp!*  Those poor sheep/goats!
>>>>
>>>> I would be interested in seeing exactly what your 'Input' mixin 
>>>> does.  The use of self-referancing returns to initialize it is 
>>>> pretty nifty though.  Might be a way to get rid of the '.end' at the 
>>>> end, though?
>>>>
>>>> The error baffles me, though.
>>>
>>> Symbols are limited to ~255 chars on Win32.  I think it's a 
>>> limitation of the object file format.  "symbol too long" errors are 
>>> painfully common in C++, though they're typically truncated to the 
>>> max length to allow for debugging.
>>
>> I thought the OMF lib-imposed limit was about 4K. I've just made a 
>> template with a symbol name of 480 characters, and that was OK.
>> If Tuple!() works with a nesting level of 50, the limit would have to 
>> be pretty big.
>> Maybe in the future, we'll be able to add some kind of 'final' 
>> declaration to templates, which would indicate that they don't need to 
>> be stored in the object file or library, and can be discarded from the 
>> symbol table as soon as they are instantiated. This would be 
>> particularly useful for recursive templates, which can easily spew 
>> reams of garbage into the object file.
> 
> What are these templates that can be discarded from the object file? Is 
> it templates that only contain compile-time members? Do these even take 
> space in an object file (since they have no run-time members) ?

Yes, they take up a lot of space in the object file (can be megabytes).

eg, if the source file contains
int f = factorial!(7),

then the object file will also contain the useless intermediates 
factorial!(6), factorial!(5),...factorial!(1). The unused ones don't get 
discarded until link time. I'm not sure why they're in the obj file at 
all, but they certainly get in there.



More information about the Digitalmars-d-bugs mailing list