RE: [boost] find the subexpression that matched

From: Reid Sweatman (drunkardswalk_at_[hidden])
Date: 2005-02-15 08:29:54

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of John Maddock
> Sent: Monday, February 14, 2005 4:19 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] find the subexpression that matched
> 
> 
> > 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 :-)

Looking more closely, yeah, I think it does.  I believe I was misreading
what the size() member returned; I was thinking it was the length of the
matched string.  I've spent a lot more time looking through PCRE source than
Boost's Regex Library (my last gig used PCRE heavily); that's something I'm
just starting to correct. <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.
> 
> 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>.

Yeah, well my tuner burned out years ago <g>.  Likely not.  What are you
referring to by the term "scope?"  Sections of matched structure delimited
by non-possessive capture braces?  If that's not it, then I think I've gone
through "The Scary Door." <g>  But you're right that I hadn't thought about
backtracking issues.

Reid