RE: [boost] find the subexpression that matched

From: Reid Sweatman (drunkardswalk_at_[hidden])
Date: 2005-02-14 04:52:43

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of John Maddock
> Sent: Thursday, February 10, 2005 3:45 AM
> To: boost_at_[hidden]
> 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