This has obvious disadvantages if one wants to implement lazy matching of regexes on a potentially large input stream.
Yes, it's a bug, or at least an unfortunate design choice.
My hypothesis about what is happening is:
I suggest that a cleaner conceptual way of doing this would be to ask how far we are from the start of the iterator.
That's basically what it does, but when the first potential match is found it "accidentally" ends up computing the length of the whole sequence, I'm testing the patch below now, all being well it should be in cvs shortly. John. Index: boost/regex/v4/match_results.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/regex/v4/match_results.hpp,v retrieving revision 1.18 diff -r1.18 match_results.hpp 303c303,304 < BidiIterator base = (*this)[-1].first; ---
BidiIterator base = this->prefix().first; BidiIterator end = this->suffix().second; 312a314,320 if((p1->first == end) && (p2->first != end)) { // don't compute distances if we don't have to: base1 = 1; base2 = 0; break; }