Thanks for the feedback. Comments inline ... Fred wrote:
(I didn't profile it, but it looked as though it would be extremely slow as a regex.)
If you ever do profile it, please post the results. I've dome some very limitted tests which show xpressive to be faster than Spirit, but I'd be very interested in real-world data.
One thing that I'd like to see improved is the ability to organize complex regexes. I think one example that I hope is easy to implement would be an ability to name a set of characters. There are a number of literals (_d, _w, etc.) that already do this. I would have found it useful to be able to name my own character sets in static regexes.
Good idea. Shouldn't be too hard to implement.
The syntax cheat sheet should have a string literal added to it. I'd like to see it be complete, and this is the only thing I could find that wasn't there.
Noted.
I'd like the documentation to better describe the _w identifier.
You're right. _w == (alpha | digit | '_'). I'll add it to the docs.
On the page grammars_and_nested_matches.html, there is a discussion of how the library nicely handles all sorts different lifetime scenarios, but it does not discuss the lifetime of the regex refered to by a regex object that is refered to only through a “by_ref” clause in another regex. Does by_ref copy the object and manage the lifetime or not?
regex uses pimpl. by_ref() increments the impl's ref-count, so you never get dangling references. I'll make the docs more clear on this point.
One big advantage of static xpressive regexes is the potential of making a complex regex relatively readable. I'd like to see some discussion of this in the docs. (Something along the lines of http://www.boost.org/libs/spirit/doc/style_guide.html)
That would be useful.
The documentation of ~as_xpr( character_constant ) should be included. This is a useful construct.
Yup, an oversight. <snip>
(I also broke my personal record for long error messages. Even Spirit has never generated a 10MB error message for me before!)
I consider unreasonably long error messages to be bugs in xpressive. Anybody encountering such an error should send me a bug report, and I'll see about adding a static assertion to give a better error message.
* Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Yes.
Thanks for taking the time. -- Eric Niebler Boost Consulting www.boost-consulting.com