>>>I'd appreciate (and I'm sure a whole bunch of lurkers would also appreciate) a piece of code that demonstrates the 'evaluate differently at run-time'.
>>
>>I haven't read all of this thread and maybe I'm confused what the problem is. But this is my understanding of #DEFINE:
>>
>>If you (in header file or methods, prgs, etc etc) have #DEFINE in your code, such as:
>>
#DEFINE Now DATE()
>>
>>And then use it like this:
>>
REPLACE mytable.updated with Now
>>and
>>
ldTomorrow = Now + 1
>>
>>And then it being compiled, then compile just replace all the
Now with
DATE(), so it actually sees the code (before compiling!) as:
>>
REPLACE mytable.updated with DATE()
>>and
>>
ldTomorrow = DATE() + 1
>>
>>#DEFINE doesn't "Evaluate" at compile-time nor run-time. There is no "DEFINE"'s in a compiled program. The code is just dublicated. Of cause "Evaulate" could be a play on words of what the compiler is doing.
>>
>Erik,
>
>A good explanation. What's happening is that the function calls are actually inserted into the tokenized code. In short, using a #DEFINE to declare the carriage return/line feed pair via CHR(13) + CHR(10) only causes these functions to be inserted wherever the referenced constant appears. This can cause unnecessary additional processing overhead if the constant is referenced multiple times (such as in an iteration structure). In such a case, it's better to use a variable, initialized beforehand, and referenced thereafter.
Thanks, George. I now have to check all my code and change #define CR and #define TAB to something else.
BTW, what about:
local lcCR, lcTab
lcCR=chr(13)
lcTab=chr(9)
#define CR lcCr
#define TAB lcTab
Thanks in advance.
If it's not broken, fix it until it is.
My Blog