>I think I've got a handle on it too. The VFP Help topic talks about it as compile time "text substitution", which is perhaps a better way to think about it than strictly as "constants". Even though we can #DEFINE things that are variable at runtime, I think the help topic was probably written with conventional constants in mind.
>

Hi Rick,

To clarify, CONSTANTS are not variable at run-time. You cannot change the value of a CONSTANT at run-time. This example will compile fine but will error at run-time:

#DEFINE LOCAL_DRIVE sys(5) 
LOCAL_DRIVE = 'SomeOtherValue'

The reason is, at run-time the code has been changed to:
sys(5) = 'SomeOtherValue'

You can only change the value by changing the #DEFINE statement and recompiling. I think this has been the source of much of the confusion regarding this issue.

Given the following constant:
#DEFINE LOCAL_DRIVE sys(5)
The value of LOCAL_DRIVE is sys(5) at compile-time and at run-time. However, at runtime when LOCAL_DRIVE's value is evaluated (not re-evaluated) it will return the same as evaluating sys(5).

>The Help file says that by using #DEFINE you can reduce memory consumption, increase performance, and simplify programs.

That is only true when replacing a variable with a constant. Replacing an in-line literal with a constant has no performance advantages. That was shown in Georges earlier test.

>Based on what I remember about compiler construction, memory consumption should be reduced because there will be only one copy of a defined constant in your compiled program even if you refer to it in many places in your code, whereas with in-line literals you may be creating a new copy of the constant each time you use it. So your program will be smaller if you use #DEFINE for things you refer to more than once. Text strings for common error messages comes to mind as a good example of this.
>

This is a SWAG but I'm not sure you will see any improvement in that instance either. If prior to compiling all the constants have been replaced with their values, how would the compiler know if a constant has been used in more than 1 place?

>Performance should increase because defined constants don't have to be re-evaluated at run time, as you showed with the code you posted elsewhere in this thread where you compared a defined constant to a memvar to an in-line literal.
>

IMO constants are never evaluated, simply because they only exist just prior to the code being comipled. Their value however, will be evaluated (for the first time) at run-time.

>And programs are simplified in the sense of improved readability (meaningful names instead of cryptic references or meaningless literals) and maintainability (change it in one place and it affects the entire program).
>

Exactly. Death to all Magic numbers < g >