It may, but not in the sense I meant it. You'd have to iterate the returned captures(i) sequence and parse its contents to get a count (unless I've badly misunderstood what you meant, which is entirely possible, given the hour <g>);
Well then I'm not sure I understand what it is you want, you get a count of how many times a sub-expression was (repeatedly) matched from match_results_object.capture(n).size(); Is that what you wanted or not? If not you've lost me :-)
that's likely to be considerable overhead on top of an already slow option (and one that must be compiled in). All I wanted was a low-overhead count of each captured submatch, say, a count() member on the plain return container. Am I wrong in thinking that maintaining a count wouldn't adversely affect the performance of the algorithm to the extent the full existing option does? I don't know about others, but this is a feature I'd personally be making a lot of use of, so I'd hate to compile in a lot of overhead for the entire app.
It adds more overhead than you think: the problem is keeping the "count" correctly scoped as you backtrack etc. If we can agree on what we're actually talking about here, then something might be possible, but I'm not sure we're on the same wavelength yet <g>. John.