Re: [Boost-users] regex_search? Which subexpression smatch'ed?

From: Lynn Allan (l_d_allan_at_[hidden])
Date: 2006-04-07 17:59:59

Just seemed that at the point when the code sets mySmatch[curIndex].matched 
to true, then it could "tuck away" that index in an accessible variable .... 
but apparently not.

Any suggestions about alternative on how to best accomplish the search for 
Bible verse references? I'd have to think the participants in this thread 
would have some deep insights on the best way to proceed.

I've written different "flavors" of state-machines that recognize these kind 
of patterns, but a regex seems like the way to go unless performance has to 
be emphasized.

Thanks.

----- Original Message ----- 
From: "John Maddock" <john_at_[hidden]>
Newsgroups: gmane.comp.lib.boost.user
Sent: Friday, April 07, 2006 11:56 AM
Subject: Re: regex_search? Which subexpression smatch'ed?

>> Forgive me for jumping in late. This seems like a pretty silly
>> optimization to me. Matching a regex, especially a complicated one
>> like this, is going to take soooo much longer than a simple O(N)
>> traversal of the resulting sub-matches that it just doesn't make
>> sense to track this information during match time. In fact, it'll
>> probably run *slower*. Don't do during match time what you can do
>> before or after. You'll turn a simple O(N) operation into something
>> far worse, and you'll make everybody pay for it.
>>
>> If you don't want to muddy up user code with a bunch of
>> "if(results[n].matched)" checks, just write an iterator adaptor (using
>> boost::filter_iterator<>) that iterates over only those sub-matches
>> which matched, and also provides the index.
>>
>> My $.02,
>
> Good point: even enumerating 100 sub-expressions to find out which was
> matched is going to be pretty quick compared to the alternatives.  The
> balance only really changes if you have thousands of marked 
> sub-expressions,
> and I really hope we don't see regexes like that any time soon :-)
>
> John.