Boost logo

Boost :

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
> 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at