"John Maddock" <john@johnmaddock.co.uk> 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