>Hi Rick,
>
>I think I have an understanding of what's going on. Yes, I'm going to keep digging too, but in some other languages to see how they behave. My gut reactionn here is that if they're supposed to be compile time constants I'm going to treat them as such. It is tempting, however, to try to "trick" the system, butt I've leaarned over the years that it can get you into trouble. Thanks for the feedack.

Hi George,

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.

The Help file says that by using #DEFINE you can reduce memory consumption, increase performance, and simplify programs. 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.

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.

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

If you think about it as text substitution, then #DEFINE seems similar to macro expansion. Since we all know that macro expansion is very slow, I was curious how they would compare. In the following code...

#DEFINE dcDrivePath SYS(5)+SYS(2003)     && defined constant
lcDrivePath = "SYS(5)+SYS(2003)"         && for use with macro expansion

*  Defined constant
lcx = ""
lnStart = seconds()
for lni = 1 to 1000
    lcx = dcDrivePath
endfor
lnStop = seconds()
lnTime = lnStop - lnStart
?lnTime

*  Macro expansion
lcx = ""
lnStart = seconds()
for lni = 1 to 1000
    lcx = &lcDrivePath
endfor
lnStop = seconds()
lnTime = lnStop - lnStart
?lnTime

RETURN

...the loop which uses the defined constant is roughly twice as fast as the loop which uses macro expansion. The test result is the same regardless of which loop you put first in the program, and both give identical values for lcx (i.e, both are evaluated at runtime). The speed of both is also proportional to the length of the lcx string: I get numbers like 0.090 and 0.044 when running the program in "C:\TEMP", and numbers like 0.124 and 0.074 when running it in "C:\VFP_APPS\TEST".

---

#DEFINE dcWEEHOURS BETWEEN( TIME(), "01:00:00", "02:00:00")
if dcWEEHOURS
  oThisMessage.Post()
  oSelf.Sleep()
endif