>>Turnaround time in the same ballpark compared to vfp interpreter ? C++ compilation has speeded
up, but there also must be the step to compile vfp to C++ code.

Most testing is done via your IDE or a standard interpreted exe; C++ compilation is a final process once it's ready to release. Here it's an unsupervised scripted process with a small prg with a browse to identify apps for compilation then it chugs away in the background on an Atom build pc.

>> I HATED working through bug lists in (non-Turbo) Pascal and C, as due to compilation times I had to "fix" a couple of issues first in code, then compile, then check all. Working on one bug with immediate testing in interpreters was much better.

You don't need to look at the C++. VFP Compiler creates it, MAKEs it, then compresses or does whatever other options you set, delivering an exe and dll to be signed and tested. IOW there's an extra unsurpervised final step in your distribution plan.

>>If I was still working full time in vfp, sheling out for such fixes might make sense.

'Tis free.

>>But unless a new header type for .dbf local munching is introduced, which offers > 2GB files I think 64bit will not be a game changer for giving more speed via less disk usage.

Chen indicated interest in this- but these days there's free versions of SQL Server and SQLLite out there. Too many reasons NOT to use a dbf if your table is that big...