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