On 9/16/05 11:44 AM, "Eric Niebler" <eric@boost-consulting.com> wrote:
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.
I wasn't considering back-references. Does the list have to be tied to back-references at this level?
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.
But we should strive for an optimal interface, and then go back for any "necessary" warts. Since the nature of the 0-element is different from the rest of the elements, I'm guessing that you generate that element in a different manner than the others. Is that correct? If so, then you're handling the elements differently anyway in your internal computations and just merging them together at the user level. You already did the work for what I asked for; you're just doing extra work in hiding it. Didn't the "old" way just use numeric indices, never going through the list via single-step iteration? So there was never a mixed-metaphor problem that we have now. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com