From: John Maddock (john_at_[hidden])
Date: 2005-02-14 06:18:43
> It may, but not in the sense I meant it. You'd have to iterate the
> 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
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
> full existing option does? I don't know about others, but this is a
> I'd personally be making a lot of use of, so I'd hate to compile in a lot
> 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>.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk