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;
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk