Answers inline... Scott Woods wrote:
1. What is the benefit of providing the complete match in the first entry of the results? e.g. "what[0]". While this is consistent with a long tradition in RE, after some time with STL it's presence at position zero wasnt as comfortable as I expected.
I'm curious, what did your experience with STL lead you to expect? I did it this way because TR1 regex does it that way. Although xpressive is not a fully compliant TR1 regex implementation, minimizing gratuitous differences can only help.
2. Why the slash syntax in dynamic regex? The resulting requirement for a double is fairly ugly. It may be consistent with something (Perl/ECMA/..?) but on balance is it worth it?
I'm following the lead of every other regex package for C and C++ out there. Anything else, and there would be riots in the streets. I agree that the double-slashes are hard on the eyes, though. (So use static regexes insted. :-)
3. Why ">>" and not "," (comma). Did the "set" facillity take priority or does the low precedence of comma just result in a different ugliness (sorry, not really the word I want to use :-).
As Joel already said, operator precedence. Also, I completely stole Spirit's choice of operators, lock, stock and barrel. That's a conscious decision (made after much debate and hand-wringing) to ease any future unification, and so that Spirit users can be productive with xpressive with a minimum of fuss.
4. C++ operators and RE operators are not really comfortable bed-fellows. While the operator overloading technique has given something useful and concise was there no flirtation with "key words" (i.e. in the manner of "as_xpr"). "+" could have been "one_or_more( xpr )".
Joel already answered this one, too. Concise syntax is part of what makes regexes powerful. And don't underestimate the power of an infix notation to *greatly* reduce the syntactic burden. Imagine if the sequence operator were spelled "sequence()" instead of ">>". Instead of "a >> b >> c >> d" you would have "sequence(a, sequence(b, sequence(c, d)))". This quickly becomes unmanageable.
5. There didnt appear to be much specific thought given to file processing. Is this another "not yet implemented"? In particular elegant integration with any async I/O facillity arising from sockets and file I/O initiatives.
xpressive works generically with iterators. Spirit has a file iterator. That would be the way to go, IMO.
6. Very interested in the future of "semantic actions". Actions and file processing probably go together?
They're orthogonal, AFAICT.
Appeared to be some minor problems such as initially not knowing what "_w" and "_d" meant. Was this my failing or was there a missing definition. Was the later use of "+alpha" and others inconsistent?
The docs can certainly be more clear on this point. It's been brought to my attention that I never say anywhere exactly what _w means. I'll clean all this up. Thanks.
* What is your evaluation of the potential usefulness of the library? Huge. Some of that answer refers to the usefulness of RE but xpressive is obviously more. There has been some discussion about overlap with regex. It would be nice to clarify that.
I tried to clarify the issue of overlap in the following messages: http://article.gmane.org/gmane.comp.lib.boost.devel/131005 http://article.gmane.org/gmane.comp.lib.boost.devel/131072 Do you have a specific question or concern that hasn't been addressed in these messages? <snip>
* 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.
-- Eric Niebler Boost Consulting www.boost-consulting.com