Hi Neil,

>> The question is: Why do you want to have VFP compiling native code ????
>
>I never said I did, if I want native code for whatever reason I will create a DLL/FLL/OCX with Visual C++.

I agree 100%

>>> Speed ? I think that most DML operations won't be any faster. Besides this I
>>> doubt that the overall performance of a native compiled application would be
>>> make a big difference in terms of speed.

>Visual FoxPro unlike the CLR generates P-Code not Native code, as such the P-Code has to be interpreted unlike Native code which is executed. The interpreting of the P-Code adds overhead no matter how clever you code the execution back end. I am not saying that this is bad, Microsoft thought this was good and introduced a compiler option (C/C++) to generate P-Code that (from memory) added a 9k assembly language object module to your executable.

>Bottom line - In terms of speed VFP could benifit from the interpreter to code generator move.

Performance DML actions such as SQL SELECT, REPLACE, INSERT etc, heavely rely on I/O etc. Since interpreting a single DML command would take a fraction of the time to execute the underlying C/C++ code I won't expect any benefit if the P-CODE was translated into native code.

As for commands that don't rely that much on I/O, they could be faster if compiled native code, but I doubt if that would be that much. Remember we've got very fast string manipulation which is comparable to native compiled code.

The speed of my application are mostly determined by I/O, so I won't expect very much speed enhancement with a native compiler.

>>> Compactness ? I think that there are several other ways than native code
>>> compiling that would compact our VFP applications (Clean up the garbage in
>>> our exes please !!).
>
>The mere act of converting an ASCII input stream into a binary P-Code representation compacts and optimises the source code for the backend executor. How do you know that there is garbage in the exe's or fxp's without an understanding of the tokens/symbol tables generated?

You don't have to. When reading the ASCII and comparing this with a FPW 2.6 app, you come to this conclusion real fast.

>Granted they may not be as efficient as they could be but wouldn't you rather have the VFP team develop new features rather than saving bytes in the P-Code by re-writing the code generator/backend?

Well, I read some story about one exe containing several megs of debuging info because of commenting you're code. Developers should not be punished for commenting code. Well it is not up to me to decided how the VFP team would spend its time. Everyone has other priorities. Personally I like to see that the VFP team expands its compiling options....

Walter,

>Neil