Walter,

I was only joking, but while we are on the subject.

>> Then again, you would lose the COMPILE and macro substitution options (Which
>> I think the majority don't want) or else the compiler itself should be
>> included in the C/C++ code or as add on library (And that's is not what MS
>> wants because of Copyrights, and not what you want, because you wanted to
>> get rid of that one).

I agree that runtime compilation and macro substitution are USP's for Visual FoxPro however other languages manage without these features.

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

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

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

Neil