Lynn Allan wrote:
Whatever you could work out would be greatly appreciated.
----- Original Message ----- From: "John Maddock"
It's backtracking that gets you: each time the "lowest sub-expression set" gets updated you'd need to store a complete history of previous settings so you can backtrack out again. However, now I think about that some more, I actually think it might be possible after all :-)
Forgive me for jumping in late. This seems like a pretty silly optimization to me. Matching a regex, especially a complicated one like this, is going to take soooo much longer than a simple O(N) traversal of the resulting sub-matches that it just doesn't make sense to track this information during match time. In fact, it'll probably run *slower*. Don't do during match time what you can do before or after. You'll turn a simple O(N) operation into something far worse, and you'll make everybody pay for it. If you don't want to muddy up user code with a bunch of "if(results[n].matched)" checks, just write an iterator adaptor (using boost::filter_iterator<>) that iterates over only those sub-matches which matched, and also provides the index. My $.02, -- Eric Niebler Boost Consulting www.boost-consulting.com