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.