Just seemed that at the point when the code sets mySmatch[curIndex].matched
to true, then it could "tuck away" that index in an accessible variable ....
but apparently not.
Any suggestions about alternative on how to best accomplish the search for
Bible verse references? I'd have to think the participants in this thread
would have some deep insights on the best way to proceed.
I've written different "flavors" of state-machines that recognize these kind
of patterns, but a regex seems like the way to go unless performance has to
be emphasized.
Thanks.
----- Original Message -----
From: "John Maddock"
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,
Good point: even enumerating 100 sub-expressions to find out which was matched is going to be pretty quick compared to the alternatives. The balance only really changes if you have thousands of marked sub-expressions, and I really hope we don't see regexes like that any time soon :-)
John.