>>I think that we see it more because foxpro uses the FPU more than other languages because all numerics are doubles, therefore the fpu is always used. The performance hit for resetting the state of the FPU before every FPU operation would be too great in this case. This is also why Intel Pentiums run foxpro faster than non Intel equivalents, they tend to have faster integer performance and slower FPU performance.
>
>Hi Albert,
>
>I'd have to disagree here. Most other applications, spreadsheets for example, handle division by zero better internally than VFP. For example, type =0/0 into an Excel cell, and you'll see "ERR". Do a ? 0/0 and you see a series of asterisks in VFP. No error message or warning. I think that's the culprit here.

My point is that when these other programs use the FPU it is a rare (relative to the total number of operations) occurance that they wrap with special exception handlers. With FoxPro, it is much more common and more interspersed with non FPU operation. It is this that makes it harder to trap. It would require a huge restructuring of the underlying code to efficiently trap the exception. The only way around this would be a change to VC++ so that it prevented the problem. Then it would just be a recompile, but the performance loss would still occur.