>>Then I #defined it as a constant and replaced all six occurrences of the string with this constant. I compiled it, and found the string in the fxp six times, in pretty much the same places as in the first fxp.
>>
>>So there's no pool - the constants still remain scattered throughout the code.
>
>That's a nice step forward in this discussion.
>
>What do you think that means, performance-wise, at execution. Would it suggest to you that #DEFINEd constants are faster?

Only slightly - since there's no pool, the address of a constant is short, it's within the line in which it's used, so there's no jump to a faraway segment of memory. With today's machines, that doesn't mean much.

Also, with VFP's dynamic loading of code, having a global pool of constants would only mean they are static, i.e. the whole block of constants being loaded once and kept in memory for the life of the app. Now with them being local to the statement, they are loaded when needed, and discarded when the routine goes out of scope. So they take up spaces only in the lines of code where they are used - with no difference between the case when they are literally in the line, or when they are #defined.

So, IMO, #define is a convenience, to be used when it improves the readability of the code, or when a language-specific application can't use translation lookup table etc. Speedwise or memory consumption-wise, the difference is negligible.