>Hi, Peter.
>
>>When VFP compiles, it generates what is called 'pseudo-object code', also referred to as 'p-code'. One might say that VFP will interpret this p-code in runtime. For my own understanding, I imagine that it's half way to real compiled code. However, the thruth might be that it's only 10 percent of real compiled code.
>
>It is not near to compiled code. The runtime fully interprets the p-code. Maybe any of the regular VFP team members can give us more detail, but I'm sure there is no "real" compilation beyond p-code.
>
>See ya,
Yeah well, I guess we now might start a discussion on what 'to compile' means. One definition is 'to translate a program into machine language'. However, in VFP we have the command COMPILE and it will certainly not compile into machine language. Instead, it will generate 'object files', whatever these may be.
Perhaps object files are like highly efficient pieces of food (tokens) for the interpreter. The interpreter gets a piece of food and knows immediately what to do with it. There's no longer the need to first analyze the words of a string. What comes to my mind is a 'data driven' aplication written in C++/assembler. And the p-code is the data. If programmed well, then a 'data driven' or p-code driven application can be almost as fast as a real compiled app, don't you think?
Groet,
Peter de Valença
Constructive frustration is the breeding ground of genius.
If there’s no willingness to moderate for the sake of good debate, then I have no willingness to debate at all.
Let's develop superb standards that will end the holy wars.
"There are three types of people: Alphas and Betas", said the beta decisively.
If you find this message rude or offensive or stupid, please take a step away from the keyboard and try to think calmly about an eventual a possible alternative explanation of my message.
