[boost] Re: Regex ease-of-use ideas

From: David Abrahams (dave_at_[hidden])
Date: 2004-04-07 09:52:30

"John Maddock" <john_at_[hidden]> writes:

> BTW, just to be hyper critical, your alternative code:
>
>     std::string line;
>     boost::regex pat("^Subject: (Re: )?(.*)");
>
>     while (std::cin)
>     {
>         std::getline(std::cin, line);
>         if (boost::smatch m = boost::regex_match(line, pat))
>             std::cout << m[2];
>     }
>
> contains an assignment inside a while loop,

No, that's an initialization.  Note the leading declaration.

> which while "neat", I have often seen criticised for being
> potentially error prone, there are even some compilers that throw
> out a helpful(!) warning if you do that (along the lines of "didn't
> you want to use operator==).

I don't think that's true of initializations.

>> > One other thing - the current regex_match overload that doesn't take
>> > a match_results as a parameter currently returns bool - the intent
>> > is that if the user doesn't need the info generated in the
>> > match_results, then some time can be saved by not storing it.
>> > Boost.Regex doesn't currently take advantage of that, but I was
>> > planning to in the next revision (basically you can cut out memory
>> > allocation altogether, and that's an order or magnitude saving).
>>
>> But I do need the match results, when the match succeeds.
>
> I understand that, but there is a group of users who don't - one example is
> a (commercial) email spam-filter that uses Boost.Regex.  It only needs a
> true/false result "does this message have this pattern or not", and it wants
> the answer as fast as possible.  For uses like this even a small change in
> performance can make the difference between "coping" and "not coping" with
> the email traffic they're seeing these days.

Sure, I understand.  I'm just saying that there's not neccessarily
anything wrong with providing the *option* of some convenience at the
expense of speed.

>> I guess my original suggestion of making it implicitly convertible to
>> some safe_bool solves that problem.  I guess I prefer that idea,
>> though Allan probably has more experience with this than I do.
>
> OK, let me mull this over, maybe we can find a way to keep everyone happy,
> maybe not ...

We shall see, shan't we?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com