>>>>And my suspicion is that execution speed would be little different between the two because I assume that any "constants" actually end up in (what we called in mainframe days) the "literal pool", resulting in similar execution as using a memvar.
>>>
>>>Not so. They are preprocessed by the compiler, replacing the constants in the code. They are not saved as memvars at all. It goes within the code space as it is just code.
>>>
>>>What you see in your code as "wdForward" is actually written internally in pre-compile time as "1073741823" in the example.
>>
>>Why are you so sure that "1073741823" is actually *IN* the generated code that is the code executed... have you seen VFP's internals to see how it actually does this?
>>
>>In mainframe assembler I might code ' MVC SomeArea, "Not in use" ' and just because the "Not in use" is coded *IN* the instruction itself doesn't mean that it was actually in-line *IN* the code. In fact the "Not in use" was moved by the compiler into the "literal pool" and the actual computer instruction referred to the location in the literal pool. Which effectively made it no different than using a variable, in terms of execution speed.
>>My **guess** is that VFP would be no different. Of course there's a fifty-fifty chance (at least) that I'm wrong.
>
>Jim a simple test, if you have refox or any other decompiler. create a program with:
>

>#define TestMe 1234
>? TestMe
><pre>
>compile it and then decompile FXP, The result program will be:
><pre>
>? 1234
>

I don't see what that proves...
How can you tell from that whether 1234 comes from a literal pool or directly from the 'instruction'?

The question I have is not if the 'constant' gets put into the source code, but rather if the 'constant' come directly from the code line at execution time.