[fpc-devel] dominant short strings in compiler source
Michael Van Canneyt
michael at freepascal.org
Tue May 16 20:32:10 CEST 2006
On Tue, 16 May 2006, L505 wrote:
> I'm really surprised about the amount of short strings used on the FPC compiler source,
> such as short strings being used even to pass to Exec() when the linker is called on
> windows. This is obviously why for the past few years I've had all sorts of chopped off
> issues with FPC and got weird linker messages when using long directory paths. Especially
> when I am using the -o option in combination with a bunch of other linker options
> (since -o is passed to the linker, along with -K options and other stuff, such
> as --include, AFAIK). I'm wondering why short strings were used so dominantly - was it
> because FPC 2.0.x is based on old source code base which didn't have ansistrings available
> yet? Was it for speed? I don't see how using short strings could significantly improve the
> speed on for example an Exec call - I could see it greatly improving speed in some cases -
> but when it introduces hard to find bugs, not worth a few milliseconds IMO. And the Pascal
> language is supposed to have less bugs in it because of strong typing, but in fact strong
> short string typing has really caused me a lot of bizarre bug headache :-)
>
> I've made some efforts to change some stuff to ansistrings to try and solve my bug with -k
> option that I mentioned recently - and although I am making progress, I realize that I am
> changing TONS of code since tons of the code uses short strings - is there any plan to get
> rid of the short string reliance in lots of the code? It will require a HUGE patch on
> multiple units. I'm just trying to find out some of your plans on the future FPC versions.
> The short string reliance kind of scares me, actually.
There is no problem with short strings, except for external paths.
What IS a problem is that changing it to ansistrings will significantly slow down the compiler.
For 2 reasons:
1. It's heap based. There is a lot of memory manager overhead.
2. The implicit try...finally in each procedure that uses them introduces a memory penalty
and a speed penalty.
So I would really advise against this change. There is no gain, except maybe for some
external path settings. identifiers etc: there short strings are more than enough.
Michael.
More information about the fpc-devel
mailing list