Daryle Walker wrote:
On 9/15/05 1:10 PM, "Eric Niebler" <eric_at_[hidden]> wrote:
In practice, the only reason why you might iterator over
all sub-matches is to print them out. Otherwise, the sub-matches are
accessed
randomly, because (for example) the 1st sub-match is a date and the 3rd sub-match is an email address, and I'm not interested in the 2nd. See?
<snip>
It looks like the current setup is not STL-friendly. Most of the "what" list is one type of thing, the in-order pieces of the regex parse. The first item of the list doesn't match that pattern (since it's the whole parse). I'm guessing that this "old" way wasn't a problem because people expected 1-based arrays, so the 0-index could be special. That doesn't work in a 0-based array culture, like C++ (or C). C++ people would expect the 0-index element to match the general rule of the list. This mixing of element types mixes concerns (violating "keep it simple, silly"). A STL-friendly alternative would to have separate member functions for the whole-parse and the list-of-parse-pieces, then have a special function (member or non-member) that generates a regex-culture combined list.
I agree, if we we're only concerned about satisfying people familiar with C++ culture. But we are also trying to satisfy people familiar with regex culture. Every regex package out there I know of that supports back-references begins numbering captures at 1. I don't know why. But I do know that to break with that tradition now would cause massive confusion. Besides, I'm trying to minimize the differences between xpressive's interface and TR1 regex. Is it a wart? OK, I agree. But frankly, I don't feel that this is an ugly enough wart for me to break with established practice. -- Eric Niebler Boost Consulting www.boost-consulting.com