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

[Bruno Medeiros]

Don Clugston wrote:
> 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.

Then that means a language construct would not be necessary, as the 
compiler or linker should be able themselves to know not to generate 
empty template sections. And that seems easy to implement, at least at 
first sight (if it requires changing optlink we might not be so lucky).

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D