>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'

Thanks for your reply, Roi, you shed some good light on the subject.

I think it's a just case of semantics, though. I was using the word "constants" as a shorthand for compile-time constants, i.e. things we define with #DEFINE. So let me call them defined constants, or DC's, from here on.

Anyway the point wasn't the difference between a constant and a variable, but the difference between things we can #DEFINE whose value is truly constant at runtime (like #DEFINE dcSomeString "ABC", or #DEFINE dcSomeNumber 10) versus other things we can #DEFINE whose value may be different at runtime than it was at compile-time (like SYS(5), SYS(2003), DATE(), etc.).

I never gave it a lot of thought before reading this thread, but now I think it's misleading to describe what #DEFINE does as creating "compile-time constants". You have to think about it as "compile-time text substitution" or it doesn't make sense that #DEFINE SYS(5)+SYS(2003) would refer to the runtime values for SYS(5) and SYS(2003) rather than to the compile-time values.

>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).

I suppose it depends on what your definition of the word "value" is (OK, no Clinton jokes!). If you take value to mean the text that gets substituted for LOCAL_DRIVE, then yes, the only way to change it is to recompile. But if you take value to mean the value that LOCAL_DRIVE evalutates to at runtime, then clearly it can change from run to run without recompiling.

>>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.

I agree here, although George seemed to indicate that DC's were faster than literals (Message #268676). I ran George's code and found no significant performance difference between a compile-time constant and the equivalent in-line literal, but a memvar was slower. [ George: if I'm misunderstanding or misreprenting your post, please jump in here].

>>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?

Well, you're right, Roi. This does seem to be true in VFP, which makes me wonder what MS means by reduced memory consumption. The only way to do what I'm talking about in VFP appears to be to use a memvar. IMHO, compile-time constants should work this way too, with the difference being that using a DC should protect you from any possiblity of changing the value at runtime, whereas with a memvar the only thing that protects you from a change in value at runtime is your intention never to do so.

>>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 >