Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!uunet!pilchuck!dataio!bright
From: bright@Data-IO.COM (Walter Bright)
Newsgroups: comp.std.c
Subject: Re: Significant name length list
Message-ID: <2070@dataio.Data-IO.COM>
Date: 24 Jul 89 18:53:18 GMT
References: <2146@dlvax2.datlog.co.uk> <12570020@hpclscu.HP.COM> <116@psitech.UUCP> <1989Jul23.021533.27429@utzoo.uucp>
Reply-To: bright@dataio.Data-IO.COM (Walter Bright)
Organization: Data I/O Corporation; Redmond, WA
Lines: 24

In article <1989Jul23.021533.27429@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
<In article <116@psitech.UUCP> david@psitech.UUCP (david Fridley) writes:
<<Requiring there to be a maximum name length is the sign of an inexperienced
<<programmer.  It is a simple process to tag each symbol with its length and
<<realloc() the block untill it is big enough for any symbol...
<Nobody with any sense is going to implement a fixed limit in a new compiler,

In the interminable quest for faster compilation, I've done a lot of profiling
of my parser (Zortech). One of the major time sinks is pulling in the
characters and stuffing them into the identifier array. The identifier array
is therefore static because it's faster to access a static array than one
that is accessed through a pointer.

I did, however, bump up the size of the array to 127. Nobody seems to have
run into that yet :-). If they do, I'll increase it to 256. The limit is
just a #define in a header file.

If you think I'm wrong about doing this to maximize performance, consider
that my compiler is within 10% of TurboC's compilation speed, and it's
a two pass compiler as opposed to TurboC's one pass. I've estimated that
the two pass design costs about 25% in compilation speed.

Real-world programming is always tradeoffs, no rule is absolute and no
feature comes for free.