>>When I know I'm going to have a long message, especially from home, I usually compose it in Notepad and paste.
>
>I used to do it like that. But this is the 1st time it happens since I installed Netscape4.
>
>>Helps avoid this problem, and keeps my CompuServe bill down.
>
>Why don't you take an Internet account for Internet access? (There is also the Universal Thread Navigator for off-line access, but it's only for Premier membership, AFAIK.)

Hopefully, Santa's bringing me a Premier membership.

One of the reasons that I joined Compuserve was that I wanted to try to write a couple of articles for FoxPro Advisor. At the time, it was next to impossible to successfully get attachments in or out without it getting "squished". They've improved that and it's no longer an issue. They also have unlimited Internet access now, but it's around $25.00 (US) a month. Since I try (sometimes without success) to maintain a somewhat normal life, and I get free access through the company, there's been little motivation for me to switch.
>
>>Sorry about the crash, I think I would've enjoyed what you had to say.
>
>I've put the same info in less words in the message that didn't crash. No need for 1000 words when you really need 10. :)
>

>>When I say "function", I'm referring to a routine like the above in the runtime library. I think we're saying the same thing, but expressing it in different ways. The above would be handled by the math coprocessor section of the chip. But would logical AND?
>
>A simple "+" operation shouldn't go to a routine into the runtime library.
>

Well don't forget that this is threaded pcode. How's the runtime interpreter to know when it's a token and when it's an instruction? Further, it would have to flag every operation as to its nature. That would lead to a lot of excess code and processing. Frankly, I can't see either a reason or a way for the math routines not to be a part of the runtime library.

>Here is the assembler code for a bit OR:
>
>10: a = 1;
>0040102D mov dword ptr [a],1
>11: b = 2;
>00401034 mov dword ptr [b],2
>12: c = (a | b);
>0040103B mov eax,dword ptr [a]
>0040103E or eax,dword ptr [b]
>00401041 mov dword ptr [c],eax
>
>The bit AND it's similar, only that the "or" is changed with an "and". All these are CPU instructions. If VFP goes to an internal routine... it is much slower.

I've never seen 80x86 assembler before, but I assume that the operation is being carried out in one of the registers. Much the same as 6502 would. How would the result come back to the caller? Via the stack?

>
>>I'm sure that all of these facts contribute to the slowness of VFP in certain operations. But what contributes most? I think that it's problematical at best. It may even vary depend on things like what's going on in the loop.
>
>I can't say what contributes most. The fact that VFP rearranges variables contributes (obviously) depending on how many variables are out there. I have no idea how VFP handles a loop. I know only that a FOR is much faster than a DO WHILE and a SCAN is faster than a DO WHILE also.
>
Absolutely! You won't get the slightest disagreement from me on this. However, I wouldn't necessarily use a FOR instead of a DO WHILE if the situation called for the latter. One exception, if speed's an issue. However, even at a couple of hundred iterations, I haven't found that it's noticable to the user. If that's the case, then I stick with the correct iteration structure (BTW, I really wish FoxPro had a post test loop). Makes maintenance easier. Further, if I had to search a list, say 100,000 or more items with no index, I wouldn't use FOR, I wouldn't necessarily force it into a cursor and index it either. I'd use a DO WHILE to write a binary search. It isn't terribly complex and works regardless of the data source.

>>Comparing VFP to VC++ is comparing "apples and basketballs" for obvious reasons. However, VFP to VB isn't despite the differences in variable typing etc. Neither produce native code and require a runtime library. Since the fundamental language design between the two should be comparable, there might be some valid conclusions that could be drawn, but then again...who knows?
>
>AFAIK, VB has now a native compiler. But it still uses the runtime DLL(s). But this is done by almost all programs out there. Ie: almost any program uses the Win32 API DLLs.

Well we sure know that VFP does.
>
>>One last note: I've really enjoyed this exchange. It isn't too often that I get to deal with sort of thing. When I first started in this business I wanted to do systems work, not applications. Then again, my wife thinks I'm a glutton for punishment ;-)
>
>:) I enjoy this type of discussions too.
>
>Vlad

As sort of an after thought, yesterday I noticed that a fellow from Microsoft was here for a while. I hope he read this thread and will enlighten us in ths area.

Have happy holidays, my friend.

George