Re: [boost] Boost range - Add variadic join/zip

Subject: Re: [boost] Boost range - Add variadic join/zip
From: Neil Groves (neil_at_[hidden])
Date: 2013-05-10 15:39:23

On Fri, May 10, 2013 at 3:31 PM, Jeff Flinn <Jeffrey.Flinn_at_[hidden]> wrote:

> 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