On 5/10/2013 8:44 AM, Jonathan Wakely wrote:
On 10 May 2013 12:55, Neil Groves wrote:
On Fri, May 10, 2013 at 11:28 AM, Jonathan Wakely
It looks as though it's undefined behaviour to zip ranges of different lengths, because you'll walk off the end of the shorter ranges.
My variadic zip stops at the end of the shortest range, which seems to
be consistent with zip functions in most other languages I've looked at.
I like being able to avoid the cost of checking for the end of every item in the zip especially for non-random access iterators. In anything I put into Boost.Range I think it of paramount importance to obey the zero overhead principle. It seems that it would be simple to allow both end detection mechanisms.
The closest existing practice I see is the std::mismatch algorithm which requires the first of the two input sequences to be the longest, and only checks first1 != last1. boost::range::mismatch pays the overhead of checking both input sequence iterators against their corresponding end iterators. Perhaps the std::mismatch approach is appropriate for zip iterator as well. In accommodating std::mismatch requirements when I don't know that the first sequence is longest I've a wrapped mismatch that check's the sizes and swaps argument references, though this is limited in it's genericity. Jeff