I found it somewhat surprising that a straightforward implementation via std library algorithm templates was able to keep up with VFP's builtin functions. I guess this reflects more on the chosen test data than on the issue VFP vs. C++, since the implementers of AT() and OCCURS() necessarily had to make some assumptions about what constitutes 'normal' usage and tailor their implementations accordingly.

If algorithms are chosen specifically to suit a particular class of problems then you can be dramatically faster; in the case of substring counting/searching likely candidates for largish input strings are Boyer-Moore, KMP and Shift-And-Search, just to name a few. But these algorithms incur a small setup penalty over more straightforward approaches and so they are a little slower if only small strings need to be searched in. Fastest would be a function that looks at the inputs and dispatches to an appropriate specialist for the given inputs, but of course this requires much more effort to implement than a straightforward solution and so it is not worth it unless analysis shows a need.

An example that might do the different strengths of VFP and C++ more justice is a simple EDI scanner class that I wrote a couple of years ago for use at $ORKPLACE. This did about 1K lines per second but performance was becoming a problem, with input files in the multi-megabyte range and whatnot. So I looked carefully at the problematic portion, which was the code that splits a segment (input line) into an array of data elements. By applying traditional Fox code optimization techniques (slimming *g*) I was able to speed the code up to about 7K lines/s; and using ALINES() to do the splitting for all lines that do not contain a release indicator pushed performance to 20K lines/s. But I just recompiled a fairly straightforward scanner that I wrote in C++ when I wrote the original Fox code five years ago, and I had trouble locating an input file that would cause it to take at least 0.1 seconds to scan and dissect. Result: over 4 million lines per second, even though the C++ code does quite a bit more than the Fox code (char set translation via lookup table while scanning, etc. pp.).

But I am still using the Fox code because at 20K lines/s the raw EDI parsing isn't the limiting factor anymore; the limiting factor is now processing the data - including database work - and for that Fox is still the best. *g*