|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2004-04-07 02:37:46
Pavol Droba <droba_at_[hidden]> writes:
> On Tue, Apr 06, 2004 at 08:33:56PM -0400, David Abrahams wrote:
>> "Eric Niebler" <eric_at_[hidden]> writes:
>>
>> > David Abrahams wrote:
>> >> Pavol Droba <droba_at_[hidden]> writes:
>> >>>On Tue, Apr 06, 2004 at 02:43:20PM -0400, David Abrahams wrote:
>> >>>>> What would be the advantage? User can write iterator_range
>> >>>>> res=regex_maxch(...);
>> >>>>
>> >>>>Doesn't the match object get destroyed here, thereby invalidating the
>> >>>>iterators?
>> >>>>
>> >>>Not really as far as I know. Iterators are bound to the collection that is being searched,
>> >>>not to the match itself. Therfore, they validity should not be bound the lifetime
>> >>>of them match. They will be copied to the iterarator_range.
>> >> The match object *is* the collection (of submatches) being searched.
>> >>
>> >
>> >
>> > A sub-match is just a glorified pair of iterators. The iterators refer
>> > to the sequence being searched, which has a lifetime independent of
>> > the match object. There is no risk of iterator invalidation here.
>>
>> I'm not worried about submatch's iterators over the original input
>> sequence, but about the match_results's iterators over submatches.
>>
>
> These are destroyed and forgotten. That's the idea of the example.
> If you are interested only in the success/failure of the search operation, or
> you want to know which part of sequence has been matched, then you don't need
> full match_results. Those two iterators (contained in the iterator_range) are
> more then sufficient, and you don't need to pay an extra price implied by
> match_results.
>
> Maybe I got it wrong, but the discussion before seemed to deal with a problem
> like this.
Maybe I got it wrong; I want to be able to look at the 2nd
submatch when the match succeeded. If all I get is an iterator the
whole substring that matched, it's of no use to me.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk