On Fri, May 10, 2013 at 3:31 PM, Jeff Flinn
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.
It does indeed pay the price under all circumstances with no option to opt-out. This is my design error. I have a renewed effort on obeying the zero-overhead principle in the last year or so. I've found design decisions in libraries that I have used to not provide zero-overhead options extremely limiting. I shall go back and review all of the Boost.Range code and provide zero-overhead options wherever I have failed to do so. For a zip iterator, of course, the overhead could be considerably greater depending on how many ranges were zipped together. I don't believe there is a need for me to choose the right solution for my clients. It's trivial to allow both.
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.
Ah yes this comes back to the boost::size modifications I also have to do! I could utilise an optimised boost::size() that provides O(1) for containers such as list to provide optimised implementations under more scenarios. It looks like I've got some work to do!
Jeff
Thank you for pointing this out since I had honestly forgotten that I'd made this design decision for mismatch. Regards, Neil Groves