Michael Goldshteyn wrote:
empty() may not a good name for this function, but agree with me that encapsulating the functionality of testing whether an re object actually holds a regular-expression should be more intuitive than:
---------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
0 == rex.regex_id(); // Test if rex actually contains a regular expression
Actually, I don't agree. Conceptually, all regex objects hold a regular expression; that is, every regex object matches a subset of all possible character sequences. For default-constructed regexes, the subset happens to be empty. I'm having a hard time imagining why you want to know that a given regex was default-constructed (or was copied from such a regex). Is it to avoid the cost of calling a regex algorithm when you know it would fail? The first thing these algorithms do is check to see if the regex_id() is 0 and if so, immediately return, so there isn't really any overhead you'd be saving (aside from resetting the match_results, which is cheap). So, not only do you already have access to the information you want, it also doesn't seem to be particularly useful information. If the cost of resetting the match_results concerns you, I could see about reorganizing the code in the algorithms to avoid even this tiny cost. Might be a good change to make anyway.
Perhaps something like unfilled(), bare(), or as you suggested is_invalid() should be added to the actual implementation, instead of user code? I would further argue that something so trivial and tightly coupled to the implementation (i.e., regex_id() being zero) should be a member function and not stand alone.
What is it about checking the regex_id() that bothers you? Is it the constant 0? You could instead write it like ... if(rex.regex_id() == sregex().regex_id()) Default-constructing a regex is very cheap, FWIW. -- Eric Niebler BoostPro Computing http://www.boostpro.com