-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: Thursday, February 10, 2005 3:45 AM To: boost@lists.boost.org Subject: Re: [boost] find the subexpression that matched
I'd like to tag a question onto the coattails of this one. I haven't given it much thought, so if there's a terribly obvious reason this wouldn't work from a theoretical standpoint (or it's already in the implementation), please let me down easy. <g> Okay, I know there's no reasonable way to parse arbitrarily-nested constructs with regexes, but it's always seemed to me that it might be almost as useful to be able to extract the number of times a captured submatch with one of the repetition operators following actually matched. I also can't think of a reason it couldn't be done, off the top of my head. Your take?
My take is it's already been done: see the section on repeated captures in http://www.boost.org/libs/regex/doc/captures.html
Does that answer your question?
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>); 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. Reid