Robert Ramey wrote:
I have sort of a dumb question about this. What would be the motivation for using Xpressive if its not faster than regex? Putting it another way, I would have thought that Xpressive would be faster with the cost of more code being instantiated every time it's invoked. What else is going on here? Another question: How would using expressive be different than using spirit with a regular expression grammar?
I have no purpose for asking other than idle curiosity.
When there is an optimization opportunity that reduces the search problem to "find the end of this buffer", as in this case, then its true that boost.regex can do it as fast as anybody. That shouldn't be surprising. In other cases, you can find examples of patterns and search strings which make either boost.regex or xpressive appear faster, but not algorithmically so. That's because they both solve the same problem in roughly the same way, algorithmically speaking. In my tests, I find xpressive to better handle shorter matches (search string < 1K) and boost.regex to better handle longer matches. YMMV. The key advantage of xpressive's static syntax is that it makes it simple to refer to data and code elsewhere in your program. In xpressive's docs, see the sections "Grammars and Nested Matches", "Semantic Actions and User-Defined Assertions" and "Symbol Tables and Attributes" for examples of things that boost.regex cannot do. Xpressive differs from Spirit in two major respects: 1) In xpressive, a regex can be specified as a string at runtime. In Spirit, a grammar rule cannot be specified that way. Only with xpressive can an entire grammar be entirely specified in a config file read at program start-up, for example. 2) Xpressive regexes have exhaustive backtracking semantics, even when they are assembled into grammars. Spirit grammars do not do exhaustive backtracking. That can make it harder to author some types of patterns. Hope that helps, -- Eric Niebler Boost Consulting www.boost-consulting.com